You may find yourself in a situation where you may need to implement a “catch all” email address, i.e. every email that is directed to your domain regardless whether the user exits or not, not to be rejected but instead directed to a single mailbox. There are various approaches to the problem, and we will see some here:

First, the easy way:

Using FEATURE(`virtusertable’) one can do that in a single line:

@example.com          catch-all@delivery.host.name

You can even exclude some addresses and have email delivered to their own mailbox instead of catch-all:

user1@example.com          user1@delivery.host.name
user2@example.com          user2@delivery.host.name
@example.com                 catch-all@delivery.host.name

The sendmail.mc way:

Normally the above trick which is adequately described in cf/README and the bat book, should be enough. But there may be cases that it is not the solution that you want, or simply because it-is-not-invented-here. For example you may want to redirect to catch-all all email directed to existing users of the system, as opposed to the virtusertable trick which does this unconditionally:

LOCAL_CONFIG
Kuser user -m -a.FOUND

LOCAL_RULE_0
R$- < @ $=w . > $*        $: $(user $1 $) < @ $2 . > $3
R$- . FOUND < @ $=w . > $*          $@ catch-all < @ $2 . > $3

Or, you may want to redirect to the catch-all address all email directed to non-existing users of the system:

MODIFY_MAILER_FLAGS(`LOCAL', `-w')dnl
FEATURE(`local_procmail')dnl
MAILER(`smtp')dnl

LOCAL_CONFIG
Kuser user -m -a.FOUND

LOCAL_RULE_0
R$- < @ $=w . > $*        $(user $1 $)
R$- . FOUND          $#local $: $1
R$-                    $#local $: bit-bucket

In fact (with bit-bucket aliased to /dev/null) the above example silently discards every email not directed to an existing user.

Continuing from the previous post in this series, let’s see how one can deal with incoming email that must be delivered both to physical users of the system and users not visible via /etc/passwd:

LOCAL_CONFIG
Kuser user -m -a.FOUND

LOCAL_RULE_0
# Unconditionally redirect email to abuse and Postmaster
RPostmaster  < @ $=w . > $*        $: Postmaster  < @example.com. > $3
Rabuse  < @ $=w . > $*        $: abuse  < @example.com. > $3

# Deliver email to yiorgos locally
Ryiorgos  < @ $=w . > $*        $# local $: $1

# Delete email directed to all other users in /etc/passwd
R$-  < @ $=w . > $*        $(user $1 $)
R$- . FOUND        $#local $: bit-bucket

# The following is valid only if sendmail is instructed to not check /etc/passwd.
# This is achieved with MODIFY_MAILER_FLAGS(`LOCAL', `-w')dnl
R$- < @ $=w . > $*        $#custom.local $: $1

What does the above snippet do? The first set of rules accepts all incoming email addressed to Postmaster and abuse and redirects it to Postmaster@example.com and abuse@example.com.

The second set of rules accepts and delivers locally all incoming email addressed to user yiorgos.

The third set deletes all incoming email for all other users listed in /etc/passwd. One may refine that using a (sendmail) class definition and decide to do so for incoming email addressed to users like man, daemon, lp etc. Remember that in Ruleset 0 you cannot call $#discard.

Assuming that you have written a special delivery agent (to save email in a database for example) for “local” users not found in /etc/passwd, the last rule calls that delivery agent for the given username.

Of course if you are in a certain mood of BOFHiness, you can add similar rules that return random error codes to the sender. The expressiveness of sendmail’s modem-noise is unlimited…

(part 1)

Suppose that you are running a sendmail server which is the final delivery server and that the users of the mail system are not physical users on the server (ie. they do not exist in /etc/passwd). What choices do you have in order to accept valid local email?

1. Use LDAP.
2. Edit mbdb.c and add a map. You can add your custom map and the relevant hooks to support the external directory of your choice. Read the source on how to do that.
3. Edit mbdb.c and wrap getpwnam(3). Similar to the above but it may seem easier in some cases, especially if the users are kept in /etc/passwd like file. The first time I saw such a trick was when I was reading TACACS+ code.
4. Use MAILER(`local’) without the w flag, which means that /etc/passwd is not consulted prior to forking the mail delivery agent. This is accomplished by:

   MODIFY_MAILER_FLAGS(`LOCAL’, `-w’)dnl

   That way the local mailer and not sendmail decides whether the user exists or not. You have to write your own delivery agent.

Of the above choices I rely heavily on #3 (although I am not using flat files) and lately I used #4. LDAP is always my last choice. I am sure there are other choices though.

(part 2)

Due to a spam burst last night, I was forced to write a ruleset in the spirit of my previous post:

LOCAL_CONFIG:
HFrom: $>BlockFrom

LOCAL_RULESETS
R$* "NEWS Sensation" $*        $#discard $: discard
R$*        $#OK

Again since this is going straight into your .mc file, it is not advised to use this method frequently. Nice five-liner to stop a spam burst, right?

No! As I was applying this filter I thought that although most people think that sendmail‘s most serious trouble is its bug / security track record, its most serious problem is that decision rules on routing and filtering messages come from all over the place: text files like mailertable, virtusertable, genericstable, relay-domains, access, the sendmail.cf rulesets themselves like the example above and more importantly the milters, their defaults and their configuration files (if any).

Say for example that you do not want email directed to abuse@ to be filtered at all. Depending on your rules and how they are written, you may have to upgrade your rulesets, edit access and probably write an exception for every single milter that you are applying. One exception might need to be declared in five different places. Talk about complication and management nightmare! That is why I like running MIMEDefang: It gives me a Perl interpreter and the ability to implement most of the functionality of any other milter I wish to apply. Have I reached that point of being able to run only one milter? No, but I have set this as a goal. MIMEDefang is not my only choice to this path, j-chkmail seems like a good alternative.

However, I am not the only one who manages our global filters, and I want to make it easier for the other admins to add their own global filters in my absence. Oh how much easier it could have been if the libmilter API offered as a return value a variant of SMFIS_ACCEPT that would instruct sendmail to accept the message with no more milters applied to it. Currently SMFIS_ACCEPT instructs the current milter to accept the message. Which is why if you want to write a global whitelist exception, you may have to write it for all milters that are enabled.

Oh well, I think all I want and wish for is to minimize the number of files I have to edit in order to implement a certain policy (or have a tool that can read the policy from one place and edit n-files for me) and a change to the libmilter API (which I do not know whether it is trivial or not). Suggestions to switch to alternatives like Postfix, Qmail or even Exim are outside the scope of this rant. I prefer to take the “Sendmail Theory and Practice” route and write the whole .mc file by hand instead.