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.

This is a variation of the bat book‘s subject header checking trick. Assuming that you want to block messages based on the content of the Subject: header of an incoming message, you can place the following rules into your .mc file:

LOCAL_CONFIG
HSubject: $>BlockSubject

The above basically instructs sendmail to call ruleset BlockSubject with the value of the subject. On with the ruleset now:

LOCAL_RULESETS
SBlockSubject
# The next rule is broken in two for readability!
R$* test - block this message $*
        $#error $: "553 message blocked due to Subject: " $&{currHeader}
R$* Your new password $*        $#discard $: discard
R$* Casinoo $*        $#discard $: discard
R$*        $#OK

(You may want to change the $> operator with $>+. Read paragraph 25.5.1 of the fourth edition of the bat book for a discussion on the matter.)

The bat book prefers to put all the unacceptable subjects in an external database file (which is maintained much like aliases and virtusertable). I prefer keeping the list of the unacceptable subjects inside the .mc file for two reasons:

First, keeping them in a file outside the .mc makes the list grow faster. Editing the .mc to add yet another unacceptable subject makes one think whether to do so or not.

Second, although a subject that contains a certain phrase may be considered unacceptable, you might want to make an exception. For example one may decide to block all the Your new password messages except ISP name – Your new password message that your MIS sends to your users when they reset their password. This can easily be maintained in one place in the .mc file and is also self documented modem noise code:

R$* ISP - Your new password $*        $#OK
R$* Your new password $*        $#discard $: discard

Remember, do not copy-paste sendmail.mc code. The LHS and the RHS are tab separated. Copy-pasting converts tabs to spaces and your ruleset will not work.