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+)
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
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:
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:
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:
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);
}/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)/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.
Last edited by a moderator:
