Kolab 3 Anti-Spam

During the last month of running Kolab 3.0 on my Debian server, I tweaked some settings for anti-spam fighting.

Here is what I did and what you can do to have your Kolab 3.0 inboxes as spam-free as possible.

Greylisting

Stopping spam before it enters the queue is a good thing. One way to achieve this is Greylisting:

Reject a triplet (sending host, sender address, recipient address) on the first deliver attempt with a temporary error (450 4.2.0 <tobias@tobrunet.ch>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/tobrunet.ch.html) and save this triplet. On the second delivery attempt check the triplet against the database and if it matches, allow this message to be delivered. This stops many spam senders because they only try it once. A correctly configured MTA tries it again after a few minutes and the mail is delivered.

A drawback of this mechanism is that an email which is sent for the first time has a longer delivery time and if you have impatient users,
they won't like it. It's also possible to lose emails if the sending MTA is not correctly configured, but then the sending MTA has probably other problems and could be a spam sender.

Installing and configuring postgrey

Implementing Greylisting on Kolab 3.0 running on Debian is very easy:

1. Install postgrey: apt-get install postgrey
2. Add postgrey policy filter to Postfix by editing main.cf and adding check_policy_service inet:127.0.0.1:10023 to smtpd_recipient_restrictions at the end of the list (restart/reload postfix after this change)
3. Check you mail.log if postgrey is acting as expected:
   Feb 25 20:31:56 james postgrey[3211]: action=greylist, reason=new, client_name=mtasender.domain.com, client_address=123.52.23.32, sender=sender@domain.tld, recipient=tobias@tobrunet.ch

A nice Blog post on Debuntu explains some parameters which can be tweaked for postgrey

Spamassassin

On a default Debian installation, Spamassassin is not enabled in the Amavis configuration. This is too bad, because Spamassassin can help to stop many spam emails. To enable Spam scanning in Amavis, remove the comment before @bypass_spam_checks_maps in the file /etc/amavis/conf.d/15-content_filter_mode and restart amavis. Spamassassin has to be trained with spam and ham. There is some good documentation about that topic in Chapter 6. Combating Spam of the official Kolab 3.0 documentation.

Blacklists

RBL blacklists (Real-time Blackhole Lists) helps to block known spamming IP addresses at the SMTP conversation level. All configured Blacklists will be queried (using DNS) to check if the connecting IP of the MTA is listed on the Blacklist. The sending MTA is then blocked with a hard error, f.e. 554 5.7.1 Service unavailable; Client host [190.190.76.151] blocked using zen.spamhaus.org; http://www.spamhaus.org/query/bl?ip=190.190.76.151

RBL configuration

RBL blacklists are directly integrated into Postfix and are configured in main.cf:

submission_recipient_restrictions = [...] reject_rbl_client zen.spamhaus.org, reject_rbl_client ix.dnsbl.manitu.net, reject_rbl_client bl.spamcop.net, [...]

I'm using Spamhaus, IX and Spamcop blacklist at the moment, as I've made good experience with them. Wikipedia hosts a comprehensive comparison table of RBLs: Comparison of DNS blacklists

Backup MX

One of the best things I could do in fighting spam was removing the backup MX record from DNS and not use any backup MX anymore. The reason is the backup MX did not have any spam fighting technologies and did not know anything about the primary MX (available mail addresses, greylisting triplets, ...). This is the case on many backup MX systems and spam sender know that. So they startet to send spam directly to the backup MX which accepts all mails without scanning and delivers it to the primary MX. The primary MX is then accepting mails from a well known good mail server and did not have the possibility to identify spam as good as if they were sent directly to the primary MX.

In my opinion a backup MX is not necessarily needed. A well configured MTA should retry sending messages for several days if it could no deliver it on the first attempt until it's returned to the sender. The primary MX should be up again after a few hours or within a day, so there's no need for a backup MX.

Anti-Virus

Scanning E-Mail for viruses should be done on the MTA to stop malware from entering the system. Virus scanning is done in Amavis using Clamav, but on Debian it's disabled by default. To enable it, remove the comment before @@bypass_virus_checks_maps in the file /etc/amavis/conf.d/15-content_filter_mode and restart amavis. The user clamav needs to be added to the amavis group so that the permissions are correct (restart clamav and amavis).