search

svarshavchik / courier

Courier Mail Server
http://www.courier-mta.org
71 stars 12 forks source link

Clairity on Spamhaus DNSBL error codes #47

Open acarrico opened 1 year ago

acarrico commented 1 year ago

As far as I can tell, courier doesn't directly support current Spamhaus DNSBL return codes. I'm posting the issue here to ask if anyone can verify, and to publish my own understanding for others to look at and possible correct:

Queries that are on the Zen combined list may return 127.0.0.2 through 127.0.0.11 to indicate which lists they are on, or 127.255.255.252, 127.255.255.254, or 127.255.255.255 as error codes.

According to the couriertcpd manual, "couriertcpd's DNS access list lookup normally ignores the contents of the actual A record in the DNS access list", so an etc/courier/esmtpd setting like the following (where is potentially a spamhaus DQS key):

BLACKLISTS='-block=<key>.zen.spamhaus.org,BLOCK'

will block all incoming messages, blacklisted or not if a spamhaus error code is returned. A setting like:

-block=<key>.zen.spamhaus.org/127.0.0.2

may work, but it should be a range, like the postfix:

reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]

and also there should be some kind of notice or logging when an error code appears, because in this case blacklisted addresses would be silently accepted or rejected, depending on the -block setting.

In the release notes for 1.1.3, I see, * tcpd/tcpd.c (docheckblocklist): Fix DNSBL lookuup logic.. I scanned around in the history and file tcpd.c and it doesn't seem like there is any further support for the error codes.

Finally, there is mailing list thread that touches on the issue. My reading of this thread is that the poster upgraded to a new Courier version and stopped seeing their problem, but that seems strange. The poster also reports, "I checked for one of the blocked IP's manually from the mail server. I got NXDOMAIN, not one of the error codes. If it were that I sent too many queries, would I not have gotten 127.255.255.255 instead of nxdomain?" My understanding is that this is apparently another way the DNSBL can fail if you are using a public DNS to access it, and that perhaps using the <key> above would have resolved that issue. I wonder if the poster actually changed their DNS server and therefore stopped getting error codes, but future error codes would still potentially block their mail?

Someone else in that thread says, "This is not an courier-mta issue," but I do think there is a courier deficiency in that -block isn't documented to accept a set of acceptable A records, and perhaps the reality of DNSBL error codes should be mentioned in the docs as well.

That is all I have got. I'd be interested to hear if anyone else has looked into this issue. Thanks.

acarrico commented 1 year ago

Note: In my examples, it may be necessary to add the variable name -block=<key>.zen.spamhaus.org,BLOCK/127.0.0.2. The documentation shows an example without the BLOCK variable name, but also says it must be there.