combined.rbl.msrbl.net dead

raytrax

raytrax

Verified User
Joined
Aug 5, 2011
Messages
19
Hi, we have several servers with the latest versions of exim, dovecot, spamassassin, spamblocker, etc.
For 1 hour ago the RBL combined.rbl.msrbl.net is rejecting all the mails of any emitter to any receiver.
It seems that the domain has expired today and they have renewed it today, I think that for this reason it is giving problems.
If you have problems, delete the line inside exim.conf and restart the service.
FYI
 
Code: 
perl -pi -e 's|combined.rbl.msrbl.net : \\\n||g' /etc/exim.conf
service exim restart
 
Quick fix
Code: 
[FONT=arial]echo 'RBL_DNS_LIST==cbl.abuseat.org : b.barracudacentral.org : zen.spamhaus.org : hostkarma.junkemailfilter.com=127.0.0.2' > /etc/exim.strings.conf.custom
service exim restart[/FONT]
 
Last edited:
Did somebody already contacted John (DirectAdmin support) about this to roll out a new exim.conf?

The domain where the RBL runs on seems to be for sale (so it is not a temporary outage/failure).
 
Last edited:
Thanks for the info guys.
Yes, a mass roll-out was done yesterday to update the exim.conf files:
http://forum.directadmin.com/showthread.php?t=54919
http://forum.directadmin.com/showthread.php?t=54920

I've googled around, but wasn't able to find any exim flags that would prevent the case where an DNSBL is "down", but do have a theory as to what happened.
Here's something interesting to add though, the actual DNS server for that DNSBL/RBL service is actually "up".. but returning blank values, eg: (random gmail IP):
Code: 
[server]# dig 165.6.217.172.combined.rbl.msrbl.net @combined.rbl.msrbl.net

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.62.rc1.el6_9.2 <<>> 165.6.217.172.combined.rbl.msrbl.net @combined.rbl.msrbl.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33873
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available


;; QUESTION SECTION:
;165.6.217.172.combined.rbl.msrbl.net. IN A


;; AUTHORITY SECTION:
combined.rbl.msrbl.net. 14400   IN      NS      msrbl-1.europe.msrbl.net.
combined.rbl.msrbl.net. 14400   IN      NS      msrbl-1.americas.msrbl.net.


;; ADDITIONAL SECTION:
msrbl-1.europe.msrbl.net. 14400 IN      A       37.187.21.68
msrbl-1.americas.msrbl.net. 14400 IN    A       37.187.21.68
The DNSBL will return a blank value if a query is not listed, so the above passes. Should not have triggered a block.
The only way that exim should be flagging an IP as bad is if:
1) It can connect to the RBL
2) that RBL returns a positive IP address, so 127.0.0.1 or higher. Each RBL returns it's own variation on what constitutes a block, but for most, anything means block, and nothing means pass.

So.... my current theory (just guessing) is that exim asks the combined.rbl.msrbl.net if a given IP was bad, and the RBL service was not actually down, but maybe in the process of going down, possibly redirecting requests elsewhere, or temporarily returning an incorrect value...
Could have even been a wildcard added by mistake, but now I'm just speculating. If it returned 127.0.0.1 or even any actual IP address, exim could have interpreted this as "true" thus blocking the smtp request.

So exim is probably behaving correctly, and the RBL was temporarily at fault for returning false positives. Hard to confirm without actually testing it during it's failure period.

Anyway, now all requests to it seem to be returning the blank value, so perhaps it's up again, or perhaps it's just in a plecibo state so exim requests to it continue to work, but all pass.

In any case, the RBL is removed from the exim.conf list now, so update if you've not already done so.

John
 
You must log in or register to reply here.
Back
Top