With all the spamming and malware travelling through email, blacklisting (DNSRBLs) has become one popular way of dealing with it. Basically, a host that is known to be sending SPAM is put onto a blacklist and mail servers lookup their peers when they get a connection, and if they get a result from the lookup they reject any mail, or just quarantine it.

DNSRBLs are very prevalent and many mail administrators don't even know they are using them. Typically mail security suites will use DNSRBLs as part of it's checks, but also some major network equipment manufacturers are adding this capability into network equipment.

What happens when you get blacklisted?

I've had to deal with this a few times at companies, and it can be a real hassle. With well run systems most of the time it's people outside the company that have problems communicating with the company, but also occasionally you will have an employee do something that others don't like which will get company servers blacklisted.

I have even had my own servers blacklisted by a major network equipment vendor and when I enquired why their argument seemed to be that my servers didn't send enough mail to be known to them and that a lot of SPAM came from the NNN.0.0.0/8 network which I am part of.... excuse me?! With running out of IPv4 addresses, larger network blocks have been carved up (sometimes into tiny fragments) and re-distributed, and that particular block turns out to to span the whole of Europe, much of it in eastern Europe and former Sovient countries. That's 16 million addresses and I am blacklisted because I have a one of them. This gives you an idea just how arbitrary some blacklisting services can be. Others are extremely aggressive and blacklist on minor things, while some are just very prone to messing up and having errors in their databases.

What can also confuse things is that typically any ISP, large company or mail provider will have several "mail servers" which may actually turn out to be each a mail server farm hiding behind NAT routers and/or load balancers. The result is that some mail they send gets through and some doesn't - it all depends on what outbound server / server farm each mail goes through. This can also mean that problems go unreported as people retry sending and mostly get through.

Blacklisting at the receiving MX will often result in a rejection so the sender receives an immediate response telling them the mail has been rejected due to blacklisting. Surprisingly often this results in them calling up the recipient to tell them that their servers are blocked for sending SPAM when actually it's the sender's servers being blocked. It's also very common that DNSRBLs are used in downstream mail security tools which will typically quarantine or sometimes even delete suspected SPAM mail (no point in trying to bounce it back to a spammer). This can be very frustrating as it doesn't tell anyone what the problem is - the mail just vanishes until someone asks an admin and they check the logs (if there are any) and/or fish it out of the quarantine.

Pre-emptive measures

I'm a big advocate of monitoring. Often faults can be minimised by catching early signs and good planing. Worst case problems can be detected early and measures taken to avoid problems (eg. taking an outbound mail server out of service until blacklists are cleared).

One thing I've done previously is to script up automated checks of outbound mail servers IPs against common DNSRBLs. This can be run from a CRON job as regularly as required to ensure your servers are clear.

Download: DNSRBL checker Perl script 20120426

Before using this you will need to edit it and add your IP addresses in. It already contains a bunch of DNSRBLs collected from various sources (if you know of more then please send them in), you just need to put yours in the @IP array:

my @IP = (
    '127.0.0.1',
    '::1',
);

Replace the IPs with yours and the script should report any that lookup on the DNSRBLs.

To run it regularly you can create a CRON job or just throw it in /etc/cron.daily or as appropriate for how regularly you want to check and CRON should email through any output from the script. To test you could temporarily add a few known spammy IP addresses from your mail logs and see if they get reported.

Terms & Conditions

DNSRBLs often have a commercial interest or just need to avoid becoming overloaded so they do have restrictions on the service and conditions of use. In many cases low volume commercial use is permitted, but please be aware and obey the terms of the DNSRBL providers.