If you run a mail server, whether it's for your own personal email or for your company and its employees, one of the biggest challenges you'll face is keeping spam at bay. Fortunately, several organizations maintain DNSBLs available for public use. These blacklists of known spammer servers and networks are the biggest hammer in a mail admin's toolbox, and are easy to configure in most common MTAs.
Used wisely, a good selection of DNSBLs can reject most of your incoming spam early in the SMTP conversation. This prevents your server from having to process those messages through other, more resource-intensive filtering strategies. On the other hand, each blacklist you enable adds another potential DNS lookup for every incoming message, and another opportunity for false positives that discard legitimate mail. To that end, it's a good idea to keep an eye on how the DNSBLs you choose are working on your system.
In this post I'll share some methods for gauging how DNSBLs are performing on a Postfix install. If you're following along with a production system, you might want to copy its
maillog to another server for processing, especially if its size exceeds your free RAM.
In judging a blacklist, there are two important metrics to consider:
How many junk transactions is it helping you block? A DNSBL that only identifies a handful of abusive senders per day may not be worth keeping around.
- How many false positives are being generated? Even the most permissive of blacklists will flag some legitimate senders as spammy from time to time.
False positives can be a tough nut to crack, because no amount of monitoring can guess when someone's expected messages didn't arrive. Only your users can provide that insight. You should make yourself (or your ticket system) approachable to your users so they can let you know when the system doesn't meet their expectations. Follow up on each report, and if a DNSBL is responsible for missing mail, weigh the benefits of its continued use against its rate of false positives.
A DNSBL's rejection rate is much easier to figure out. To discover the numbers, we'll consult the Postfix log file(s). In its default configuration, Postfix records a DNSBL rejection with a
maillog entry that looks like this:
Feb 6 20:11:39 mailman postfix/smtpd: NOQUEUE: reject: RCPT from unknown[188.8.131.52]: 554 5.7.1 Service unavailable; Client host [184.108.40.206] blocked using sbl-xbl.spamhaus.org; https://www.spamhaus.org/query/ip/220.127.116.11; from=<user@helo-host> to=<user@rcpt-host> proto=ESMTP helo=<example.com>
Since the entries are all formatted the same way, we can use some standard Linux text processing utilities to crunch the log and gather the target numbers. Here's a bash one-liner to tally up the number of messages rejected using each DNSBL. I've broken it into three lines for illustrative purposes:
grep "$(date +%b\ %e)" /var/log/maillog* | grep 'Service unavailable' | \ cut -f $((20 + $(date +%e | tr -cd ' ' | wc -c))) -d' ' | \ sort -n | uniq -c | sort -nr
The first line filters the
maillog files for records from today that indicate a DNSBL rejection. (If your
maillog rotates into zipped files, you may need to hack on this a bit.)
That funky second line determines where to find the DNSBL hostnames in the log records. If you imagine each
maillog entry as a list of columns separated by spaces, the DNSBL's hostname appears in field #20... Unless the current day of the month is only 1 digit long. In that case, Postfix pads the date with a space, so we have to shift one more column to the right.
The last line performs the accounting and sorts everything into a list.
Running that command, I get the following sample output:
5490 sbl-xbl.spamhaus.org; 66 dyna.spamrats.com; 60 psbl.surriel.com; 52 truncate.gbudb.net; 25 spam.dnsbl.anonmails.de; 11 noptr.spamrats.com; 8 dnsbl.dronebl.or...