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