Gallery

Stop spam the expert way: Build an anti-spam email server

Posted on 23 May 2005 at 16:20

SHELL=/bin/sh

PATH=$HOME/bin:/usr/bin:/bin:/usr/local/bin

MAILDIR=$HOME/Mail

LOGFILE=$MAILDIR/from

# Send incoming mail to the

# SpamAssassin client, spamc

:0fw: spamassassin.lock

* < 256000

| spamc

# Mail with a spam score of 15 or

# more is almost certainly spam

# and will be moved to the almost-

# certainly-spam file.

# Note that \* appears 15 times

:0:

* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*

# almost-certainly-spam

# Any other mail tagged as being spam

# is probably spam.

# It gets moved to a folder called

# probably-spam.

:0:

* ^X-Spam-Status: Yes

probably-spam

# This works around a bug in Procmail.

# Without it the F in the From field

# of the emails disappears.

:0

* ^^rom[ ]

{

LOG="*** Dropped F off From_ header! Fixing up. "

:0 fhw

| sed -e '1s/^/F/'

}

Tuning the anti-spam engine

You now have a basic anti-spam email server. Incoming mail is examined by SpamAssassin and messages that are spam, or likely to be spam, are removed from the main mail file. When a user checks his mail, either using a local mail client like mutt or a remote POP3 program like Outlook, he will mainly see real mail. Some spam will still get through, but there are plenty of ways to tune the system and improve its detection rates. Users should be encouraged to check the probably-spam file just in case some real messages have been misclassified.

This problem can be reduced by using a whitelist. If a user creates a directory called .spamassassin in his home directory and creates a file inside that directory called user_prefs he can add sender addresses that SpamAssassin should always allow mail from. The format is:

whitelist_from fred@isp.com

whitelist_from *@fasthosts.co.uk

whitelist_from wilma@*.domain.edu

Note the use of wildcards in the second two examples. Any account at Fasthosts is allowed, because we do not want to miss important mail from our domain registrar. Domain-related mail is frequently classified as spam, so whitelisting these services is crucial. Wilma sometimes sends email from www.domain.edu and sometimes from mail.domain.edu. Our wildcard takes care of this variance in sub-domains.

User preferences only work if SpamAssassin has been configured to allow them. Check that yours are by looking at the contents of the main configuration file. This is called local.cf and is found in /etc/mail/spamassassin/ on SuSE distributions. Yours might be in /usr/share/spamassassin. There should be a line that reads:

allow_user_rules 1

If it is missing or has a zero instead of a one at the end, SpamAssassin will ignore user preferences. While you have this file open, you should also check for the following lines and enter them if they are missing:

auto_learn 1

use_bayes 1

use_auto_whitelist 0

bayes_auto_learn 1

skip_rbl_checks 0

You could enable the auto-whitelist, but we prefer to remain in control of whitelists. The automatic whitelist keeps track of senders' email addresses, and reliable addresses are viewed with less suspicion by the system as they prove themselves over time.

Realtime Blackhole Lists are useful, but sometimes SpamAssassin does not seem to want to use them. To force these checks, you need to make a rather strange, roundabout setting. Add the skip_rbl_checks line and disable it with a zero. Odd, but it works.

You might also want to add a blacklist that is not supported by SpamAssassin by default. You can add your own by creating a rule in the local.cf file. The Spamhaus project runs a combined list of its Spamhaus Block List (SBL) and Exploits Block List (XBL). It contains details of spam sources and other threats such as network worms. Here's the rule you need to make SpamAssassin run checks against the list.