Anti-spam DNSBL by BOates [CHANGES REQUIRED TO WORK WITH SPAMASSASSIN 3.4.2 or later in v76+]

This functionality must be updated to work with SpamAsasssin 3.4.2 or it will break all mail delivery on cPanel v76+ : Anti-spam DNSBL by BOates [CHANGES REQUIRED TO WORK WITH SPAMASSASSIN 3.4.2 or later in v76+]

I've put together a new anti-spam DNSBL that I feel fills a current gap in the existing anti-spam block lists out there. I'm looking for some individuals whom run cPanel servers to add the DNSBL to their configuration and see how it fares, as a sort of beta test.

THE PROBLEM
I've personally observed a growing trend with spammers involving short lived domains. They register a brand new domain, ensure that a valid SPF record, valid PTR (RDNS) record, and sometimes even valid DKIM are setup. Then they blast out mail for a few hours/days, and abandon the domain before it's effectively evaluated by existing anti-spam block lists.

The spam I've been getting from this spammer technique has even registered a negative score from SpamAssassin (meaning it is inclined to believe it's definitely good email).

THE RESPONSE
How am I attacking this technique? Essentially, the DNSBL I've put together blocks any domain name that were registered less than 5 days ago. Once the domain ages past 5 days, it automatically expires from the block list.

Now, you may be familiar with a DNSBL that attempts to fulfill this very need already. SpamEatingMonkey's "Fresh" DNSBL. The problem is, I've tried it. In fact, attempting to use SEM's Fresh DNSBL is what prompted me to produce my own DNSBL because it was only catching about 1 in 50 fresh domains, sometimes even a much worse effectiveness ratio.

STATISTICS
I've been running this on my own personal machine for just under a month, which has a handful of personal use domains.

2015-03-20 => 2015-04-12
Emails Blocked by my DNSBL: 8,326
Emails Blocked by SpamHaus/Barracuda: 3,525
Emails Blocked by SpamAssassin: 266
Emails Delivered to inboxes: 3,870

RISKS
As I'm sure is painfully obvious to everyone, the risk here is that the DNSBL does not make any attempt to discern from a legitimate new internet user deploying their brand new shiny domain versus a devious spammer abusing freshly registered domains. Both are unilaterally blocked until their domains are 5 days old.

The difference is that the legitimate user will keep using their domain after 5 days, whereas the spammer will have long since abandoned their (now widely recognized and blacklisted) domain. Since this block list requires no de-listing (all domains auto-delist after the domain is over 5 days old), it's at least a short lived temporary problem at best.

I may look into a forced early-delist if legitimate customers are finding this too much of a problem, but the early-delist option could be abused by spammers as well, of course.

INTERESTED?
Well, hopefully I've piqued your interest. That's my goal here so I can test in more real world scenarios and see if it's as effective as I seem to find on my own personal box. This DNSBL is still in early stages of testing, though. It could very well fall flat on its face and be unscalable in its current form. That's why I need your help with testing it.

If you'd like help test it, follow the below steps:

1.) SSH into your server as root and create/edit the following file:

/usr/local/cpanel/etc/exim/perl/trimdomain

2) Copy/Paste the below code inside and save it (This has been updated to SpamAssassin 3.4.1+)

Code:

sub trimdomain {
   require Mail::SpamAssassin::RegistryBoundaries;
   my $domain = shift;
   my $rb = new Mail::SpamAssassin::RegistryBoundaries;
   return $rb->trim_domain($domain);
}

3.) Still on the server as root, create/edit the following file:

/usr/local/cpanel/etc/exim/acls/ACL_MAIL_POST_BLOCK/custom_begin_mail_post

4.) Copy/Paste the below code inside and save it

Code:

drop
    !authenticated = *
    dnslists    = fresh.dieinafire.com/${perl{trimdomain}{$sender_address_domain}}
    message     = Fresh Domain Blocked - [${perl{trimdomain}{$sender_address_domain}}] is listed on (fresh.dieinafire.com)

5.) Make Exim rebuild its exim.conf to include the two changes we made by running:

/scripts/buildeximconf

6.) Restart Exim by running:

/scripts/restartsrv_exim

7.) When the DNSBL rejects a message, you will see log output in /var/log/exim_mainlog that looks similar to below:

8.) Done! You're now utilizing the DNSBL. Please post some feedback if you do decide to test it out.

UNINSTALL

1.) Remove the file: /usr/local/cpanel/etc/exim/perl/trimdomain
2.) Remove the snippet previously added to the file: /usr/local/cpanel/etc/exim/acls/ACL_MAIL_POST_BLOCK/custom_begin_mail_post
3.) Rebuild exim.conf by running: /scripts/buildeximconf
4.) Restart Exim by running: /scripts/restartsrv_exim
5.) The DNSBL is now entirely uninstalled

FAQ
Q: Will this block my new customers from sending out email?
A: Not on your end. The exim.conf entry ignores authenticated users, which permits your own server's users to send email outbound even if their own domain is less than 5 days old. However, if the receiving server is using this same DNSBL, they'll be blocked from delivering to that server. As mentioned, once their domain is over 5 days old they'll auto-delist from the block list.

TROUBLESHOOTING
Q: In exim_mainlog, I see:

A: Something is blocking you from running a DNS Lookup against the DNSBL *or* your DNS Queries are taking far too long to resolve. This could be a problem on your end *or* my DNSBL's end (one of the reasons I'm trying to load test it).

Verify that you can query the DNSBL directly by running:

dig +short test.fresh.dieinafire.com

It should return '127.0.0.2' like below:

If it just returns to a blank prompt, then something is wrong and either your DNS resolvers in /etc/resolv.conf are causing problems or some firewall settings are at fault.

 

Yep you're right. It works pretty close to SpamCop or SpamHaus do in terms of cPanel + Exim integration, just doing a lookup with a domain instead of an IP. If a lookup to the block list fails for any reason, the fallback behavior is to treat it like the block list responded that it's NOT spam. So if my server gets overloaded or for any reason it becomes unavailable, it would not negatively affect deliverability.

 

Fantastic! Yeah that's why I decided to share it in hopes others would experience that same spam drop off. It's instantaneous and super effective.

Did you deploy it on a multiple servers or spread the word? Noticed today that my little VM that it's been running on on starting thrashing CPU handling the load and it looks like I'm getting tons of queries. I'm going to have to possibly look at expanding it/growing it (which is good!). Tried to spread the word on WHT some months back, but it would seem it is against their forum rules to essentially "advertise" a free service.

 

Nope it's still online and working.

Looks like I recently messed up the record for 'fresh.dieinafire.com' specifically, but that does not affect the actual DNSBL functionality since Exim is only ever going to be looking up <somedomain>.fresh.dieinafire.com which has been functional. I've fixed the record now so that http://fresh.dieinafire.com will load (the page describing the listing/delisting procedure). This means you should be able to ping it again.

Regarding a surge of spam, I noticed that this week spammers seem to be targeting the ".top" gTLD (they seem to rotate to new gTLDs every couple of weeks), and their WHOIS server is horrible -- failing to return any sort of response in my occasions. So when my service goes to cache newly registered domains, it's failing to get a lot of responses back and has to err on the side of assuming it's an okay domain.

So, I am seeing some spam from '.top' TLDs in my personal mailbox now, and there's not a lot I can do about it since the problem resides within .top's registrar WHOIS service operating poorly.

For future reference, you can always check if the DNSBL is online and responsive by running the below dig:

Code:

dig +short @104.236.11.151 test.fresh.dieinafire.com

As long as you get "127.0.0.2" back as a response, the service is online and responsive.

If you are getting spam from newly registered domains from TLDs other than ".top"., post or message me a few of the example offending domains and I'll look into why they're being let through.