Tuneups and Tweaks for the Better Spam-Trap

Building an Anti-Virus/Anti-Spam Gateway Part 3: When you build a strong anti-spam solution, you have to count on a few false positives. Here's how to tune your Linux anti-spam gateway to let the good guys through without opening the doors to spammers.

 By Carla Schroder
Page 1 of 2
Print Article

In parts 1 and 2 of our thrilling "Building an Anti-Virus/Anti-Spam Gateway" series, we covered the basic steps for setting up SpamAssassin and Clam Anti-virus with Postfix. This installment is devoted to testing and tweaking, and creating whitelists in Amavisd-new. Whitelists are essential when you set up any kind of spam filtering: It's the best way to make sure your wanted mail gets through.

Postfix Soft Bounces

The first thing to do is configure Postfix for soft bounces. Add this line to /etc/postfix/main.cf:
soft_bounce = yes

"When you're running a server for other users ... filter messages tagged as spam into a special folder, for human eyeball review."
This converts 5xx response codes to 4xx. 4xx codes are temporary failures, and the sending server is told to keep trying. 5xx response codes are permanent failures, so messages are rejected and the sending server is told to go away, and to not try again. Then you must watch your Postfix and Amavisd-new logs like the proverbial hawk to see what is happening. (See "Logging Fun", below.)

For a complete list of SMTP response codes, see RFC 2821.

Setting Up Whitelists In Amavisd-new

There are a couple of ways to do this. One is to enter your list directly into amavisd.conf, like the example in amavisd.conf in Section V:
map { $whitelist_sender{lc($_)}=1 } (qw(

Or you can create a separate file, like /etc/amavisd/whitelist.txt, using the same one-address-per-line format, and call it from amavisd.conf like this:

read_hash(\%whitelist_sender, '/etc/amavisd/whitelist.txt');

If you're a Perl guru, you can also set up ACLs using typical mystical Perl syntax. Read Section V of amavisd.conf for examples.

Tweaking SpamAssassin
Remember, when using Amavisd-new with SpamAssassin, don't bother with SpamAssassin's configuration file. Do all the configurations in amavisd.conf, in Section VII.

This setting controls whether SpamAssassin will run all tests, or omit the ones that require Internet access. Disabling the Internet tests, which include RBLs (Realtime Blackhole Lists), open relay databases, some DNS checks, and optionally Pyzor and Vipul's Razor, will let more spam through.

Vipul's Razor and Pyzor are distributed spam databases of actual spams. Spammers spew forth millions upon millions of the same message; Vipul's Razor and Pyzor use a distributed system of reporting and spamtraps to keep their databases current, and then generate digital signatures of the messages to enable fast checking.

But if you're on a slow or unreliable Internet connection, this will speed up performance:

$sa_local_tests_only = 0;  #set to 1 to disable Internet tests

Don't bother checking small messages, because most spam is over 64K in size:

$sa_mail_body_size_limit = 64*1024; 

The most important and useful SpamAssassin setting is the level at which it tags messages as spam.

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

You'll want to watch this closely for several months. Higher numbers let more spam through. Lower numbers are more aggressive, so you run the risk of having legitimate mail tagged as spam.

E-mail newsletters and HTML mail from friends are likely candidates for false positives, or even people with an inexplicable fondness for too many exclamation points, or all-caps. I'm old and grumpy, and I don't care if I lose some messages. Anyone who really wants me will find a way. You know, with archaic communcations devices like telephones and paper letters. But when you're running a server for other users, you probably can't afford to be that cavalier. The safest method is to filter messages tagged as spam into a special folder, for human eyeball review.

Continued on page 2: Some More Fine Tuning

This article was originally published on Sep 7, 2004
Get the Latest Scoop with Networking Update Newsletter