Complete Virtual Mail Server/amavisd spamassassin clamav

Introduction
Spam is becoming more and more of an issue on the internet and a robust and solid solution is required. There are payed services for even more spam protection but should not be required and will not be discussed in this article.

Postfix
The first line of defense, is postfix itself. Postfix offers a few basic means to block spam, or rather spammers. Using smtpd_client_restrictions it is possible to use public DNS blacklists. There are 3 popular DNS blacklists of which one is incorporated into the other. These two lists are also the most accurate ones. The most important one is zen.spamhaus.org and as a backup bl.spamcop.net can be used. Using them with postfix is very simple. Add these domains as reject_rbl_client in main.cf.

Introduction
Spam-assassin and ClamAV are the tools to block spam and virusses, however amavis is required to tie this all together. Amavis will actually behave as a mailserver in itself, accept mail, filter it, and send it onwards again. For this to work, postfix will need to actually listen for mail twice. The default port 25 is where mail initially is received on. From there on it is sent to amavis, which will be listening on port 10024. When amavis is done with the message, it will be sent to postfix on a different port, 10027. The reason for this should be obvious. If mail would be offered again on port 25, it would be passed to amavis again and thus in an endless loop. Obviously, postfix on port 10027 would only be listening to known hosts, like localhost and not check for spam anymore.

Installatoin
Amavis should have been installed already, if not, emerge it. This should pull in spam-assassin and clamav as its dependancies.

Basic Configuration
Amavisd offers an enormous amount of options and going over all them will take some time. The configuration file /etc/amavisd.conf however is well documented and divided into clear sections. Each section will be examined as needed. Only options that will be changed will be mentioned to cut down the text for readability.

For this example amavisd will be running on host foo but this could be any other host as well, amavisd does not require to run on the same host as postfix. Also the domain used is only used to identify the server itself with, not the domains amavisd will be scanning. {{Note|With amavis being quite complex, troubleshooting can be difficult enough as it is.

The first step, is to disable all actual checks and to enable logging. Also some default values should be setup.

{{File|/etc/amavisd.conf|Disable anti-spam, enable logging| @bypass_virus_checks_maps = (1); # controls running of anti-virus code @bypass_spam_checks_maps = (1);  # controls running of anti-spam code
 * 1) $bypass_decode_parts = 1;         # controls running of decoders&dearchivers

$mydomain = 'example.com'; $myhostname = 'foo.example.com';

$log_level = 5;             # verbosity 0..5, -d }}

{{Note|virusalert@example.com and spam.police@example can be renamed to undef if not wanting to receive any information on breaches. If not, these e-mail addresses should exist.}}

Normally restarting postfix should restart aswell, for now, only amavisd should be started to see if there are any initial problems. {{RootCmd|/etc/init.d/amavisd start}}

Linking amavisd to Postfix
With amavisd working in bare skeletal mode, it should theoretically just pass mail through. Perfect for testing the postfix -> amavisd -> postfix binding.

First, a second postfix transport, where amavis will inject its mail, is added. A lot of options are defaulted to empty, since either they have been checked already, or interfere otherwise.

With this transport in place, it should only listen on localhost and only accept mail from localhost. This should be extended if amavis is run elsewhere, but keep in mind anything is accepted.

Next another transport is added for, which could be considers 'being' amavis in a sense.

After the transport for amavis has been added, smtp should be told to route all mail through amavis. For this two option need to be added to smtpd and change the maxproc to match amavis's.

Restarting both amavisd and postfix then should pass all mail through amavisd.

Testing
Sending a message to testuser@example.com remotely and locally should work fine. After the message has arrived, the headers should be checked.

Looking at the mail headers, it should be noticed that it was sent through amavisd and re-deliverd to postfix. Mail header Examining the above it is clearly visible that the mail was received by postfix via SMTPS even. It was then forwarded to amavisd on port 10024 via LMTP and finally redelivered to postfix using SMTP again.

Introduction
ClamAV is the De facto open source virus scanner for linux. Amavis can be linked to many different free and commercial virus scanners, but here clamav will be used. ClamAV is specifically designed for scanning e-mail. IT concists of two parts, clamav itself, and freshclam, the clamav updating service. By default it updates every two hours, which should be enough for anyone.

Installation
ClamAV should have been installed already, if not it should be emerged.

{{Note|The 'clamdtop flag lets clamav build the clamdtop utility, a nice monitoring tool for the viruscanner.

Configuration
ClamAV will be configured to run in daemonized mode, e.g. it will be listening for connections (from amavisd). The other option (and the default fallback in amavisd) is to have amavisd use the commandline scanner, which is much slower and much much more resource intensive.

ClamAV does not have to be run on the same host, however it is recommended for performance reasons to keep it on the same host, depending on resource usage.

To be able to communicate, clamav needs to be part of amavisd's group.

It always helps to allow clamd to output some debug information.

Also clamd needs some settings setup in its configuration file so that amavis can talk to it.

Next starting clamd from the init scripts may produce an error message about an outdated virus database. This is normal, as the virus database has not yet been updated. Freshclam takes care of that and should be started before clamd is.

The log file can be examined for any configuration problems.

Linking amavisd to clamav
Amavisd should connect to the socketed clamd and thus clamav needs to be enabled as one of the main antivirus scanners. The fallback of invoking clamav from the commandline should not be changed. Also the virus check bypass needs to be disabled to be effective.

After restarting clamd Virusses should be able to detected and blocked.

Testing
To test whether the virus filter works, an anti-malware testfile exists, sending an e-mail using this string should trigger the virus scanner. {{Code|EICAR-STANDARD-ANTIVIRuS-TEST-FILE| X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* }}

Looking at the mail.log file, the following should be revealed.

In theory, the virus scanner should be fully functional now.

Introduction
Spam Assassin is an excellent spam filter. It has become quite complex throughout the years and requires some effort to configure correctly. Spam Assassin called from within amavisd to check e-mail for its spam value.

Installation
There really should be no need to install spamassassin separately. The spamassassin useflag should have pulled it in as a dependency of amavisd-new.

Configuration
The default configuration suffices for standard use.

Updating
A key feature of Spam Assassin is its ability to self-update. Updates are handled via a so-called update channel. Besides spam assassin's own channel, there is saupdates by openprotect.com which collects the recommended rules from SARE - SpamAssassin Rules Emporium and condenses them into an update.

Spam Assassin comes with the sa-update tool so updates can be fully automated. Spam Assassin updates can be done by using the --nogpg flag to ignore gpg keys, but should really only be done as a last resort. Adding the spamassassin GPG key is a simple 2 step process.

After adding the spamassassin update channel, it needs to be updated. After running this command, check for any errors.

Adding the openprotect channel happens similarly.

Also this channel needs to be updated. Any errors should be spotted here.

Once these updates have completed they need to be compiled for use with Spam Assassin. Also any errors should be spotted here.

Unlike clamav, there is no 'freshassassin' and a cronjob is required to do updates. To keep Spam Assassin up to date, a cronjob should be created for the tas.

Making the cronjob executable ensures it runs regularly.

Linking amavisd to Spam Assassin
Actually, Spam Assassin does not need to be linked to amavisd, it is an integral part of amavisd. Enabling the spamfilter in amavisd does spam filtering.

And amavisd needs to be restarted.

Testing
Testing is done again via a client connecting to port 25 that does not have its own spamfilter. For content GTUBE can be used. On that site there is also a suitable mail message in RFC-822 format. Sample spam body

Checking in the testusers inbox, or junkbox more likly, the message can be found and its header examined. Spam Header

Finetuning Amavisd
Amavis has a few more settings that can be changed to do some fine-tuning.

Recipient delimiter
When using postfix with the recipient_delimiter amavisd can be told to make use of this feature.

Disperse quarantine
It is possible to disperse the quarantine over several sub-directories.

For this directories need to be created first.

Also, setting a spam cutoff level helps in reducing stored spam. The cutoff level makes it that no spam is stored above a certain spam-score.

Spam Delivery
$final_spam_destiny is by default set to D_PASS, meaning that even with a high score at which it gets marked as spam, it is still deliverd to the users mailbox. Modern mail-clients, which trust Spam Assassin can then automatically move it to their SPAM folder.

Cleanup
With Spam Assassin and ClamAV working as expected, debugging information can be reduced to the normal minimal.