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+)
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: 2015-04-13 10:14:22 H=(ftj09.freezebloodsugarcure.ninja) [192.200.201.9]:47300 rejected MAIL : Fresh Domain Blocked - [freezebloodsugarcure.ninja] is listed on (fresh.dieinafire.com)
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: 2015-04-13 12:13:05 DNS list lookup defer (probably timeout) for domain.tld.fresh.dieinafire.com: assumed not in list
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: # dig +short test.fresh.dieinafire.com 127.0.0.2
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.
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
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: 2015-04-13 10:14:22 H=(ftj09.freezebloodsugarcure.ninja) [192.200.201.9]:47300 rejected MAIL : Fresh Domain Blocked - [freezebloodsugarcure.ninja] is listed on (fresh.dieinafire.com)
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: 2015-04-13 12:13:05 DNS list lookup defer (probably timeout) for domain.tld.fresh.dieinafire.com: assumed not in list
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: # dig +short test.fresh.dieinafire.com 127.0.0.2
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.
-
its working in these days? 0 -
its working in these days?
The author has not replied since May. I think it is not reliable to use this blacklist right now.0 -
I believe this RBL is still working, but I ran across one like it -- actually several, with different time constraints -- from SpamEatingMonkey. Here's their ten day new domain RBL. There are also SEM-FRESH which is 5 days, SEM-FRESH15, and SEM-FRESH30 available. [I am not in any way affiliated with either SpamEatingMonkey or BOates.] 0 -
With today's cPanel nightly update, this ACL has stopped working. failed to expand ACL string "fresh.dieinafire.com/${perl{trimdomain}{$sender_address_domain}}": Can't locate Mail/SpamAssassin/Util/RegistrarBoundaries.pm in @INC (you may need to install the Mail::SpamAssassin::Util::RegistrarBoundaries module)
0 -
Just to let you know this has stopped working properly when cPanel updated to version 76.0.4 Checking the cause of delivery inability, this was due to custom directives in the Exim Configuration. The following lines : 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) Which were located under section : custom_begin_mail_post Initially resulted in error along the following lines. 2018-11-06 11:21:10 H=(mail.asthenervestop.icu) [192.119.96.109]:33352 temporarily rejected MAIL : failed to expand ACL string "fresh.dieinafire.com/${perl{trimdomain}{$sender_address_domain}}": Can't locate Mail/SpamAssassin/Util/RegistrarBoundaries.pm in @INC (you may need to install the Mail::SpamAssassin::Util::RegistrarBoundaries module) (@INC contains: /usr/local/cpanel /etc/exim/perl /usr/local/cpanel /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib/x86_64-linux-64int /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/cpanel_lib /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/5.26.0/x86_64-linux-64int /usr/local/cpanel/3rdparty/perl/526/lib64/perl5/5.26.0 /opt/cpanel/perl5/526/site_lib/x86_64-linux-64int /opt/cpanel/perl5/526/site_lib) at /etc/exim.pl.local line 1963. There was a SpamAssassin update in which the module was deprecated and replaced as shown here : https://www.gsp.com/cgi-bin/man.cgi?section=3&topic=Mail::SpamAssassin::Util::RegistrarBoundaries
I had no choice to remove this from my servers due the fact I was not able to receive any emails at all.0 -
The SpamAssassin functionality this tool is using was deprecated in version 3.4.1 and removed in version 3.4.2 because it is now provided by another method. Mail::SpamAssassin::Util::RegistrarBoundaries(3) - domain delegation rules This module is DEPRECATED AND REPLACED WITH Mail::SpamAssassin::RegistryBoundaries !! DO NOT USE. This is left as transition fallback for third party plugins. It will be removed in the future but all functionality has been transitioned to Mail::SpamAssassin::RegistryBoundaries and the TLD updates via 20_aux_tlds.cf delivered via sa-update with version 3.4.1 As this plugin has not yet been updated to work with the latest version of SpamAssassin, the only option at this time is to uninstall it when upgrading to a version of cPanel that bundles SpamAssassin 3.4.2 (v76+) in order to ensure mail continues to function. 0 -
Hey folks, The modifications to /usr/local/cpanel/etc/exim/perl/trimdomain to become compliant with SpamAssassin 3.4.2 / cPanel & WHM v76 would be: sub trimdomain { require Mail::SpamAssassin::RegistryBoundaries; my $domain = shift; my $rb = new Mail::SpamAssassin::RegistryBoundaries; return $rb->trim_domain($domain); }
I wasn't aware that anyone was really making much use of this still, although I continue to use it for personal use. The DNSBL has been in continuous operation since the post was made with no plans to stop operation. Admittedly, I hadn't been keeping up with cPanel & WHM changes and this caught me by surprise. My apologies.0 -
Can you please post new steps for new install for cPanel version 76 for those who want to use it. 0 -
I am unable to edit old posts myself, but it looks like one of the cPanel staff members (cPanelMichael, it looks like) already updated the original post in this thread with the changes. So the original post is now accurate again. 0 -
Thank you This helps people who still want to use it or those who are new that want to use it. 0 -
Hello, is this works together with ConfigServer MailScanner? 0 -
I am unable to edit old posts myself, but it looks like one of the cPanel staff members (cPanelMichael, it looks like) already updated the original post in this thread with the changes. So the original post is now accurate again.
Any plan to share your code? Due to my bandwidth speed and latency limitation, I am thinking to install it on my own network, so the DNSBL query can be local not going to your server0 -
Does it work with version 80.0.13? Has anyone succeeded to make it work these days? It looks like a very good solution but I tried to install and tests was unsuccessful. BR. 0 -
That's awesome. Thanks for this. I'll let you know how it goes . I just added this to my server and it's working superbly 0 -
Sorry to dig up an old thread - but seems relevant here. It seems SpamAssassin updated at some point and using Mail::SpamAssassin::RegistryBoundaries started to generate errors: [font="courier new">config: registryboundaries: no tlds defined, need to run sa-update In the exim_mainlog. Or maybe it's something specific to my setup. Anybody else seeing this in their logs? 0 -
Yes I am also getting these errors in the exam_mainlog. I guess that explains why I have started getting a load of spam again, and is also a testament to how good this method of spam blocking is. I wish CPanel would integrate this into WHM. I patiently await any ideas on how to get it working again. 0 -
My previous message seems to be pending moderator approval for some reason, but I have tried reinstalling SpamAssassin and will see how it works over the next day. Thanks 0 -
No, it didn't seem to work. I just had another spam email with the same log entry config: registryboundaries: no tlds defined, need to run sa-update 0 -
Until you reach 5 messages on the forums they have to be manually approved, so that's why you're seeing a delay. If you're still seeing that issue it might be best to open a ticket with our team so we can check that directly on the system for you. If you do open a ticket, please post the number here so I can follow along and keep this thread updated. 0 -
The issue is related to the use of [font="courier new">Mail::SpamAssassin::RegistryBoundaries in the trimdomain subroutine that is added in [font="courier new">/usr/local/cpanel/etc/exim/perl/trimdomain I'm not exactly sure what the trimdomain subroutine is doing and why [font="courier new">Mail::SpamAssassin::RegistryBoundaries has to be used. Perhaps whatever this subroutine is doing could be accomplished without the use of [font="courier new">Mail::SpamAssassin::RegistryBoundaries For now, I've just disabled this blacklist. I'm not sure how relevant it is any more anyway. Seems this issue has been around for quite some time. Although the recent update to cPanel seemed to have caused some havoc with this blacklist and Mailman mailing lists. We had Mailman messages stuck in queue and just constantly being resent. That's what initially brought me to this. 0 -
This hasn"t caused any mails to be stuck in my mail queue. I"ve noticed a dramatic increase in spam in the last week though. 0 -
I've done some more digging on this issue, and the release notes for SpamAssassin v3.4.3 say: - RegistryBoundaries did not load 20_aux_tlds.cf properly in older versions. Old hardcoded list is now removed and RB will print "no tlds defined, need to run sa-update" unless it can find list from config files.
So it seemstrimdomin
used to use a hardcoded list of TLDs but now relies on an updatable list. It says we should runsa-update
which I located at/usr/local/cpanel/3rdparty/perl/532/bin/
and ran, but I am still getting the same error. I tried restarting spamd with/usr/local/cpanel/scripts/restartsrv_spamd
but no dice. Anyone more familiar with SpamAssassin and the CPanel config? ps. @cPRex I have over 50 messages since 2015 yet my new messages are still pending approval.0 -
UPDATE - this thread was in a Forum that is no longer getting much use, so all new replies were moderated. I've adjusted this now. It might also be a good idea to submit a ticket so we can check that SpamAssassin issue on the machine directly. 0 -
Thanks @cPRex i've opened a support request for this (#94312230) 0 -
Thanks for that - I'm following along with that ticket on my end now and I'll make sure to keep this thread updated. 0
Please sign in to leave a comment.
Comments
86 comments