Adding custom RBL DNS lookups to SpamAssassin

Spam is a mildly irritating reality of the Internet - you're never going to get away from it, but there are things you can do to reduce it.  I have been using SpamAssassin for years now and it's proven very useful in combating spam.  It comes preconfigured (and frequently updated) to filter out spam, and as with many *nix based open source products, is devilishly complicated to figure out and customise.  It is well worth going through the setup pain if you have any control over the receipt of your own email (i.e. don't just use the web page of a email provider).

This article is going to cover the configuration of custom RBL lookups.

An RBL is a dynamic block list that is queried in real time via the DNS system.  DNS is very lightweight and makes the technical cost of verifying sending systems minimal and bypasses the need to update local copies of massive databases.  SpamAssassin comes with a number of these built in, but there are plenty more that can be leveraged.  SpamAssassin will check every public IP address in the hop history (including the originator) against RBLs and apply scoring as appropriate.

Configuring SpamAssassin

To add a custom RBL into SpamAssassin, you need to edit your config, often found in /etc/mail/spamassassin/local.cf.

You will need to add a block for each RBL you wish to add, as per this example:

header        CUSTOM_LOOKUP_1    eval:check_rbl_txt('dnsrbl','dnsrbl.org.')
describe      CUSTOM_LOOKUP_1    Entries listed in dnsrbl.org RBL
score         CUSTOM_LOOKUP_1    2.0

CUSTOM_LOOKUP_1 can be whatever you want, it's the key for this definition, just keep it the same for each line.  You can use either check_rbl or check_rbl_txt functions to perform a lookup.  TXT records are a more recent addition to RBL lists that bring back a bit of textual information about the listing, although this usually just a URL to where the information is available.

Both these functions require a minimum of two arguments.  The first argument is used for more complex sub-query handling, which isn't covered in this article.  It can effectively be whatever you want, but keep it unique.  The second argument is the important one here, and that's the DNS zone that actually provides the RBL functionality.  This must end in a "." (technically, all fully qualified domains end in a dot, but we don't tend to use that in every day usage).

Add in as many of these blocks as you like and give them an appropriate weighting for the scoring.

Be sure to restart your service to pick up the changes, e.g. systemctl restart spamd.service.

Finding other RBLs

I have picked RBLs based on a sampling of spam that has got through and checked the source IP addresses against RBL black list checkers, such as the one on mxtoolbox.  Lists that are getting good coverage I have added in to my configuration.

It is worth pointing out that it's not just SpamAssassin that can use RBLs, other anti-spam products can, including mail servers such as Postfix.  If you run your own mail server, it's worth adding in RBL checks for bad SMTP clients.  Whilst this won't check the entire mail hop history like SpamAssassin does, it does filter out a lot of direct mail from bad hosts and stops them from even getting to your mailbox spam filters.