5.1 Spam-Checking at Delivery

The easiest way to add SpamAssassin to a sendmail system is to configure sendmail to use procmail as its local delivery agent, and to add a procmail recipe for spam-tagging to /etc/procmailrc . The advantages of this approach are

• It's very easy to set up.

• You can run spamd , and the procmail recipe can use spamc for faster spam-checking.

• User preference files, autowhitelists, and Bayesian databases can be used.

There are also some disadvantages:

• sendmail must complete the SMTP transaction and accept an email message for local delivery before spam-checking takes place. Accordingly, you can't save bandwidth or mailbox space by rejecting spam during the SMTP transaction.

• sendmail only runs the local delivery agent for email destined for a local recipient. You cannot create a spam-checking gateway with this approach.

To configure sendmail to use procmail as its local delivery agent, add the following line to your sendmail.mc file (before the MAILER(`local') line) and regenerate sendmail.cf from it:

 FEATURE(`local_procmail',`   /path/to/procmail   ')dnl 

When you restart sendmail, it will use procmail instead of the system's default local MDA (e.g., /bin/mail ) for mail delivery.

Next, configure procmail to invoke SpamAssassin. If you want to invoke SpamAssassin on behalf of every user, do so by editing the /etc/procmailrc file. Example 5-1 shows an /etc/procmailrc that invokes SpamAssassin.

Example 5-1. A complete /etc/procmailrc

 DROPPRIVS=yes PATH=/bin:/usr/bin:/usr/local/bin SHELL=/bin/sh # Spamassassin :0fw * <300 000 /usr/bin/spamassassin 

If you run spamd , replace the call to spamassassin in procmailrc with a call to spamc instead. Using spamc/spamd will significantly improve performance on most systems, but makes it more difficult to allow users to write their own rules.