Articles.DirectoryM
Anti-spam Email Server

It is relatively easy to retro-fit a working mail server with some highly accurate anti-spam measures. Some measures will work with any system, while there are also some specific changes you can make to particular mail server programs. We will concentrate on the general methods that can be applied to any regular email server, be it Sendmail, Postfix or Qmail.

Anti-spam Email Server
It is relatively easy to retro-fit a working mail server with some highly accurate anti-spam measures. Some measures will work with any system, while there are also some specific changes you can make to particular mail server programs. We will concentrate on the general methods that can be applied to any regular email server, be it Sendmail, Postfix or Qmail.

Of course, we are presuming you already have an email server: building one from scratch is beyond the scope of this article. Even if you do not intend to build your own, these two pages will illustrate exactly why so many individuals and small businesses dedicate one machine to handle email.

Is it safe?

Now would be a good time to test your email server to ensure it is not an open relay. If it is, it could be abused by a spammer and ordered to send spam to other systems without your permission. One easy way to find out is to log in to the email server and run the following command from the command line:

telnet relay-test.mail-abuse.org

This will initiate a series of tests where the mail-abuse.org server tries to discover ways in which your email server could be abused. The results will look similar to this:




:Relay test: #Quote test






: Relay access denied

If any of the tests show that relaying is possible, you need to reconfigure your email server before continuing.

What have you got?

We are assuming that your email server runs a popular mail server. In our example, we have used Postfix running on SuSE Linux 9, but these instructions should apply to other setups too. We are going to use SpamAssassin to detect incoming spam and Procmail to help filter it. You will need to install both of these programs, although Procmail is probably already available on your system. You can check for both programs by typing the following at the command line:

rpm -q procmail

rpm -q spamassassin

This should list the versions of Procmail and SpamAssasin you have installed.

We will assume you already have Procmail but do not have SpamAssassin available. If you do not have Procmail, you can download it from ftp.procmail.net. You will also need Perl.

Setting up SpamAssasin

The first step is to install SpamAssassin. There are a number of ways you can implement this anti-spam system, and we are going to use one of the fastest and most efficient methods. Instead of loading the entire SpamAssassin program each time it is required, a smaller client program called spamc is used. This talks to the SpamAssassin daemon called spamd, which runs on the system all the time.

Downoad and install SpamAssassin. The source code is available from spamassassin.apache.org and is less than 1MB. Once saved to your hard disk, extract the files into a directory that will be called something like Mail-SpamAssassin-3.0.2, depending on the exact release. In our case, we downloaded Mail-SpamAssassin-3.0.0-3.tar.gz and extracted the files by typing:

gunzip Mail-SpamAssassin-3.0.0-3.tar.gz

tar -xvf Mail-SpamAssassin-3.0.0-3.tar

This created a directory called Mail-SpamAssassin-3.0.0-3 containing the source code. We compiled the program and installed it by typing the following:

cd Mail-SpamAssassin-3.0.0-3

perl Makefile.PL

(press Return when you are asked a question)

make (if you have any errors here, check for missing Perl modules and download them using cpan. For example, if you are missing the Digest::SHA1 module, as we were, run 'cpan install Digest::SHA1')

make install

You will have to type a different directory name, depending on the version of SpamAssassin that's available when you try this. Since we are going to use the spamd daemon, we need to start it whenever the system boots up. As with most daemons, you should add a startup script to /etc/init.d. There are a few sample ones contained in the spamd directory, and you should move the one appropriate to your Linux distribution to /etc/init.d and run it by typing:

/etc/init.d/spamd start

If you use SuSE Linux like us, you will need to download the script from kmail.kde.org/unsupported/spamd, because it is not included with the SpamAssassin source code due to licensing reasons.

SpamAssassin is now running on your server, but it is not integrated with your email system yet. For that we need to use a bit of software to glue SpamAssassin and your mail server program together. That glue is called Procmail.

Enabling Procmail

Procmail is a mail processing program, or Mail Delivery Agent (MDA), and we will be using it to move spam messages to a separate file, leaving your mailbox unmolested and populated with real email. For Procmail to work, your email server needs to be able to invoke it when a message arrives. As the final stage in the mail delivery process, the mail server passes messages to Procmail, which takes over and does various things such as saving the file to a mail file called Spam, or saving it in the real mail inbox. With Postfix, you need to edit the main configuration file called /etc/postfix/main.cf and add the line:

mailbox_command = /usr/bin/procmail

Sendmail users will need to add FEATURE('local_procmail') to their configuration program.

A less efficient method, which is easier for Qmail administrators, is to place a special file in each local user's home directory. Create a file called .forward if you use Sendmail or Postfix, or .qmail if you use Qmail. This file needs to contain the path to the Procmail program, which in SuSE Linux's case is /usr/bin/procmail, although other distributions tend to use /usr/local/bin/procmail. It should be written with a pipe character in front:

| /usr/bin/procmail

At this stage, we can forget about specific mail servers and just deal with Procmail. We can configure Procmail by editing two files. The global configuration file is called /etc/procmailrc, but users can have their own customisable ones in their home directory called .procmailrc. These files contain Procmail 'recipes', which are detailed instructions on how to filter email.

For our purposes, we want Procmail to run mail through SpamAssassin, which will add some tags showing how spam-like the message is, and then have Procmail move any tagged messages to a Spam archive file. We will move mails that are almost certainly spam into a folder called almost-certainly-spam, and mail that's probably spam into a folder called probably-spam.

All of the following lines should be entered into either /etc/procmailrc or an individual user's _1_/.procmailrc file. We have added comments to show what each recipe does.

# This is the procmailrc file, saved

# in the /etc directory

# The lines below are some standard

# set up parameters used by Procmail.

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


| 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:


# almost-certainly-spam

# Any other mail tagged as being spam

# is probably spam.

# It gets moved to a folder called

# probably-spam.

:0:


probably-spam

# This works around a bug in Procmail.

# Without it the F in the From field

# of the emails disappears.

:0


{

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

:0 fhw

| sed -e '1s/_2_/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.

# Listed in sbl-xbl.spamhaus.org

# http://www.spamhaus.org/

header RCVD_IN_SBL eval:check_rbl( arelay', 'sbl-xbl.spamhaus.org.')

describe RCVD_IN_SBL Received via a relay in sbl-xbl.spamhaus.org

tflags RCVD_IN_SBLnet

score RCVD_IN_SBL5.0

Note that we have used a score of 5.0 here. It could be any number you like, and you can also change the general aggression settings of SpamAssassin. If too much spam is arriving in your mailbox, check the headers of these messages and see what score SpamAssassin is giving it. It will look something like this:

X-Spam-Status: No, score=3.6 required=5.0

Open your user_prefs file and find the line that reads required_score 5.0. Change this to read required_score 3, and make an effort to check the probably-spam file for the next few days, just in case any real mail gets junked.

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



Local Articles
Internet
Home