SpamAssassin and Amavisd: Go Ninja On Your UBE Woes

Building an Anti-Virus/Anti-Spam Gateway (Part 1): With SpamAssassin, Amavisd-new, and ClamAV, you've got all you need to build a Linux-based SMTP gateway that stops spam and viruses cold.

By Carla Schroder | Posted Aug 25, 2004
Page 1 of 2
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

The bad news is, it's SpamAssassin, not SpammerAssassin. The good news is it kills spam quite effectively, and fits nicely into an anti-spam, anti-virus gateway. This article, which shows how to use SpamAssassin with Postfix, is the first in a series on building an anti-spam and anti-virus gateway. This gateway works equally well for a single PC, or for a large network, and it's built of four components:

  • Postfix
  • SpamAssassin
  • Amavisd-new
  • ClamAV

Prerequisite: An existing Postfix server, that is running well and happily. The other bits are add-ons to Postfix. They work just fine with other mail transfer agents (MTAs) (define) like qmail, Exim, and Sendmail, but this series will center around Postfix.

You should also save yourself a batch of spams for testing.

But I Don't Run Windows

That's all right, you will still benefit from this. You can probably omit Clam Anti-Virus, and just use SpamAssassin.

I Confess, I Run Windows

If you run any Windows hosts, then by gosh you absolutely need this, every bit of it. Before investing time and energy in building this anti-spam/anti-virus gateway, do take some elementary precautions:

Remove:

  • Outlook
  • Outlook Express
  • Internet Explorer

Replace them with any of the following fine free email clients and Web browsers:

  • Eudora Mail
  • Pegasus Mail
  • Mozilla/Netscape Mail
  • Opera Mail
  • Opera Web Browser
  • Mozilla/Netscape Web Browser

You have now closed off the major malware ports of entry, and can move on to the next steps.

Amavisd-new and SpamAssassin

Install Amavisd-new and SpamAssassin. Then all configuration will take place in /etc/amavis/amavisd.conf, you won't use SpamAssassin's configuration file at all.

Amavisd-new is a SMTP (define) proxy that will take over all the content filtering for Postfix. If you already have some unsolicited bulk email (UBE) controls in place in Postfix, Amavisd-new will supersede them. Amavisd-new mediates between SpamAssassin and Postfix. Postfix hands off incoming messages to Amavisd-new, which processes them via SpamAssassin, then hands over whatever remains to Postfix for delivery to users' inboxes. On a typical day, 90% of incoming mail may be rejected at the server. Isn't that special?

You also have the option of simply tagging spam as ***SPAM***, and delivering it to users to dispose of in their own fashion.

After installing Amavisd-new, there is much configuring to do. Create /var/log/amavis.log, and assign ownership to the "amavis" user and group, which should have been created by the package manager. If they weren't, create them now.

/etc/amavis/amavisd.conf is the master configuration file, and it is huge. Take the time to study it, as it is well-commented. Start in Section 1. Find $mydomain and $myhostname and give them values appropriate for your system. Then find and uncomment these lines:

$forward_method = 'smtp:127.0.0.1:10025'; # where to forward checked mail

$notify_method = $forward_method; # where to submit notification

That tells Amavisd-new to forward messages back to Postfix for final delivery.

Now start the SpamAssassin configuration. SpamAssassin will be configured here, you will not use SpamAssassin's configuration file. In Section 1 comment out

@bypass_spam_checks_acl  = qw( . );

Section IV tell Amavisd-new what to do with messages marked as spam. This setting delivers them to the recipients, who can easily filter them to a junk mail folder, because the subject line will says ***SPAM***:

$final_spam_destiny = D_PASS; # (defaults to D_REJECT)

This setting drops them at the server, with no notice to the sender:

$final_spam_destiny = D_DISCARD; # (defaults to D_REJECT)

Pick one. A third option is to reject the spam, and also send a 5xx non-delivery message:

$final_spam_destiny = D_REJECT

This is the correct behavior for a MTA. But I don't see any point in wasting bandwidth on SMTP messages to fake addresses just to adhere to protocol.

Section VII configures SpamAssassin:

$sa_tag_level_deflt  = -999; # add spam info headers if at, or above that level

$sa_tag2_level_deflt = 5.0; # add 'spam detected' headers at that level

$sa_kill_level_deflt = -999; # triggers spam evasive actions

# string to prepend to Subject header field when message exceeds tag2 level

$sa_spam_subject_tag = '***SPAM*** ';

And finally, the "amavis" user must own SpamAssassin files:

# chown -R amavis:amavis /usr/share/spamassassin

Now make sure Amavisd-new is stopped, and check the configuration with the built-in debugger:

# /etc/init.d/amavis stop
# amavis debug

This spits out a configuration summary; all you need to worry about are error messages. If it reports any errors, they must be fixed before proceeding.

Next, start Amavisd-new back up and connect with telnet to confirm that Amavisd-new is running:

# /etc/init.d/amavis start
$ telnet 127.0.0.1 10024
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
220 [127.0.0.1] ESMTP amavisd-new service ready

Amvisd-new is running, so quit telnet:

^]
telnet> quit
Connection closed.

Continued on page 2: Configuring Postfix To Use Amavisd-new

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter