SpamAssassin and Amavisd: Go Ninja On Your UBE Woes
Amavisd-new and SpamAssassin

Carla Schroder
Thursday, September 9, 2004 11:38:36 AM
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 tells
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.
Next: Configuring Postfix To Use Amavisd-new »