Chapter 8. Using SpamAssassin

Once SpamAssassin is installed, the next step is to configure your email system to use it. There are a number of ways to do this, often several for each Mail Transport Agent (MTA). Procmail can be used to invoke SpamAssassin on a site-wide basis, and it can also be used for configuring specific users to use SpamAssassin. An alternative approach that will increase performance is to integrate SpamAssassin more tightly into the MTA. The method used depends on the requirements of the site:

• If performance is an issue due to the volume of emails handled by the site, inadequacy of hardware resources, or use of the email server for other tasks, then integrating SpamAssassin into the MTA will provide the best performance.

• If email usage is low (the number of emails received per day is in the low thousands, with few email peaks) and there are no performance concerns, Procmail is a flexible and simple option.

• If only certain accounts need to be filtered, Procmail is simple...

SpamAssassin as a Daemon

SpamAssassin is implemented as the /usr/bin/spamassasin script, which is a Perl script. There is some performance overhead involved in running a Perl script for each email. For sites with low volumes of email, this may not be an issue, but performance is a high priority for high volume sites. In these cases, the SpamAssassin daemon can be used to improve performance.

When SpamAssassin is used as a daemon, /usr/bin/spamd is run at system startup, and /usr/bin/spamc is used as a client. When used in Procmail recipes, /usr/bin/spamc and /usr/bin/spamassassin are often interchangeable, although they support different flags.

Note

For SpamAssassin to be used as a daemon, spamd must be started at system boot time.

The spamc and spamd programs are installed with SpamAssassin. The SpamAssassin distribution directory includes sample initialization scripts for starting the daemon. They are located in the spamd directory of the SpamAssassin build directory.

The spamd daemon supports...

SpamAssassin and Procmail

Procmail is a Mail Delivery Agent (MDA), sometimes called a Local Delivery Agent (LDA). It is not a Mail Transport Agent (MTA) such as sendmail, Postfix, Exim, or qmail. Procmail relies on another application (normally the MTA) to run it and to pass each email message. Procmail can run other programs (generally called email filters), make decisions, and take specific actions depending on the content of the email it is processing. Procmail may also be invoked from .forward files, which are part of the sendmail local delivery system.

Testing for Procmail

First, check if Procmail is installed. The following command will locate Procmail if it is installed in the system path:

$ which procmail

If the response indicates that Procmail cannot be found, it will have to be obtained and installed.

which: no procmail in (/bin:/usr/bin:/usr/local/bin:/opt/bin)

If the response lists an absolute path, then Procmail is installed:

/usr/bin/procmail

Obtaining and Installing Procmail

Procmail...

Integrating SpamAssassin into the MTA

The following instructions describe how to integrate SpamAssassin into a number of popular MTAs. Once SpamAssassin has been integrated into the MTA, basic MTA configuration should be tested and the user should confirm that SpamAssassin headers are being added to emails.

Sendmail

There are several methods of integrating SpamAssassin into sendmail. Sendmail has a plug-in architecture known as milter. There are several milters available for use with SpamAssassin. Here we will discuss only MIMEDefang.

Sendmail Milter Support

To use MIMEDefang, milter support must be built into sendmail. For sendmail versions 8.13 onwards, this is the default. If sendmail was supplied in a package, for example RPM, then the distributor may or may not have included this.

To test for milter support, issue the following command and examine the results:

# /usr/sbin/sendmail -bt -d0.1 </dev/null
Version 8.12.10
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8MIME8TO7NAMED_BIND...

Testing and Troubleshooting

To test if SpamAssassin is working properly, send an email to a user who is configured to receive spam-filtered email. Once the email has been received, examine the headers. There should be lines similar to the following:

X-Spam-Checker-Version: SpamAssassin 3.00 (2004-07-20) on mta.domain.com
X-Spam-Level:
X-Spam-Status: No, hits=0.9 required=4.0 tests=BAYES_00,DATE_IN_PAST_96_XX,
NO_REAL_NAME,RCVD_IN_SORBS autolearn=no version=2.63

If headers like these are present, then SpamAssassin has run correctly. If the email is not received or the extra headers are not present, then SpamAssassin has failed to work.

Several tests can be performed to analyze the problem. Some were covered in Chapter 6 in Verifying the Installation. The following sections also discuss SpamAssassin troubleshooting.

Check the MTA

If the mail has not been delivered at all, confirm that the MTA is running. The ps -ef command should be used for this. Piping the results through the grep utility will...

Rejecting Spam

MTAs can reject email. They do this when unauthorized relaying is attempted or if the recipient is invalid. When an email is addressed to a valid user, processed by SpamAssassin, and tagged as spam, there are several actions that can be taken:

• The message can be delivered to the local user, who will filter it with Procmail or an email client. This takes processing time and storage space, and possibly an occasional review of the spam folder by users. It does allow a false-positive message to be retrieved at a later date.

• The message can be silently deleted; the target user will not receive it and the sender (if valid) will not know that it was not delivered. This takes less processing time and requires no storage space or user intervention, but the email is not recoverable.

• The message can be refused as it is delivered. This will send a bounce message to the sender. This takes less processing time than delivering the email to the user and uses no storage space. Additionally,...

Summary

There are different ways of running SpamAssassin. The method chosen depends on the requirements of the site. Each method has different performance implications and offers different levels of flexibility.

For low-volume sites, Procmail is an ideal choice. It can be used to filter email site-wide, or can be used selectively for users with local accounts. For higher performance, SpamAssassin can be integrated into the MTA.

If desired, email can be rejected upon delivery. This warns a legitimate sender that their email has been filtered. However, if the spam email uses a fake identity or a stolen identity (as is usually the case) the message is bounced back to an innocent user and so this method should be avoided.