Antispam misconfigurations

Introduction

This blog post is about ensuring correct operation of one particular antispam solution. However, I think that the thoughts about possible misconfigurations expressed here apply to most of them.

The following combination of mail-related software is quite popular: Postfix + DSPAM + Dovecot. Each of these products comes with an extensive user manual, and packages are available for almost every linux distribution. So, I decided to use it for the company mail. In fact, Postfix and Dovecot were already installed (with all users being virtual), and it only remained to install DSPAM, because spam became a problem for some users.

Here is what kinds of non-spam messages go through our server: business mail (invoices, documents, commercial offers), technical support, discussions within the team, bugtracker tickets, automated notifications (e.g. when contracts are about to expire).

There are many manuals on setting up DSPAM together with Postfix and Dovecot. Below are the common things mentioned in them.

Postfix should pass the incoming mail into DSPAM. The preferred protocol for doing this is LMTP over a unix-domain socket. DSPAM should add X-DSPAM-* headers to them and reinject into Postfix. Then Postfix should contact Dovecot via LMTP, and then the message finally gets delivered to the user's mailbox (or the spam folder, with the help of a sieve filter). If DSPAM makes a mistake, the user can move the message appropriately via IMAP, and the dovecot-antispam plugin will train DSPAM about this incident.

So far so good. I installed DSPAM (with a simple hash driver backend) and configured the rest of mail-related software to use it. It even appeared to work for me after initial training. But then, we encountered problems, not explicitly mentioned in the manuals, described below. If you are reading this post, please test your mail servers for them, too.

Training did not work for some users

Some users, including myself, used their full e-mail (including the company domain) as their IMAP username, and some didn't include the domain part. Both setups worked for sending and receiving mail. However, in the initial configuration, the user's login was passed to dspam-train as-is:

antispam_dspam_args = --deliver=;--client;--user;%u

Result: for some users (those who didn't append the domain to their IMAP username), the retraining process looked for the hash file in /var/spool/dspam/data/local, while that hash file is always in /var/spool/dspam/data/ourdomain.ru. The fix is to spell the domain explicitly:

antispam_dspam_args = --deliver=;--client;--user;%n@ourdomain.ru

In fact, I think that any use of %u in Dovecot configuration is wrong if you have only one domain on the mail server.

Duplicate e-mail from monitoring scripts

Monitoring scripts send e-mail to root@ourdomain.ru from other hosts if something bad happens. However, after configuring DSPAM, each of such messages arrived twice to my mailbox. This happened because the "root" alias is expanded recursively (this is OK, as root is virtual and has nothing to do with uid 0). We want to archive all root mail for easy reference, as well as to deliver it to the actual sysadmins. The alias expansion happened twice: once before DSPAM and once after it. The solution is to disable it once. I disabled it before DSPAM:

smtp      inet  n       -       n       -       -       smtpd
  -o content_filter=lmtp:unix:/var/run/dspam/dspam.sock
  -o receive_override_options=no_address_mappings

However, this was a mistake.

Training still did not work for sales

The sales team complained that they were not able to train DSPAM so that the incoming commercial queries end up in their inbox, and not in the spam folder. Manual training didn't help, either. This appeared to be a variation of the first problem: wrong path to the hash file.

The sales team has a "sales" mail alias that expands to all of them. As such, due to the previous "fix", Postfix told DSPAM that the mail is addressed to sales@ourdomain.ru:

smtp      inet  n       -       n       -       -       smtpd
  -o content_filter=lmtp:unix:/var/run/dspam/dspam.sock
  -o receive_override_options=no_address_mappings

Thus, DSPAM placed the hash file in /var/spool/dspam/data/ourdomain.ru/sales, while the training process looked in /var/spool/dspam/data/ourdomain.ru/$person. The solution was to move the no_address_mappings option after DSPAM, i.e.  the reinjection service. This way, both DSPAM and the dovecot-antispam plugin see the expanded recepient addresses.

Some e-mail from new team members was marked as spam

A general expectation is that authenticated e-mail from one user to the other user on the same corporate mail server is not spam. However, the new team members (and even some old ones) misconfigured their e-mail clients to use port 25 (with STARTSSL and authentication) for outgoing e-mail. As such, all their outgoing e-mail was processed by DSPAM, because the only factor that decides whether to process the e-mail is the port. The solution was to educate everyone on the team to use port 587 for outgoing e-mail, which is not configured to process messages with DSPAM. Also it would have been nice to make authentication always fail on port 25, but I didn't do this yet.

Outgoing e-mail was sometimes marked as spam

The general expectation is that outgoing mail should never be marked as spam, even if it is spam. If you disagree, then please note that there is nobody to notice the problem, and nobody except root can retrain the spam filter in such case.

This is mostly a duplicate of the previous item, with an interesting twist. Namely, there are some web scripts and cron jobs that send mail to external users, and both connect to 127.0.0.1:25 without authentication. I solved this by splitting the default smtp line in master.cf into two: one for 127.0.0.1:smtp, and one for my external IP address. Spam filtering is enabled only for the second line.

Conclusion

It works! Or at least pretends to work. With so many pitfalls already seen, I cannot be sure.