The current cPanel implementation for handling the zen.spamhaus.org DNSBL needs correction.
Using the tick-a-box method of enabling zen.spamhaus.org via the Exim Configuration Manager can result in naively rejecting clean email based on any non-empty return value.
As per the spamhaus documentation, their system isn't limited to the basic return values in the range 127.0.0.[2..11] for listed IPs. They can also return a value of 127.255.255.0/24 as per...
https://docs.spamhaus.com/datasets/...icMirrors/MTAs/020-Postfix.html#configuration
The 127.255.255.0/24 values are used to signify a rejection of the actual request itself for a few different reasons - excessive request rate, perceived public DNS server traits,
open resolvers, and more. Rejecting email based on a return value in that range is simply wrong.
Point number 1 covers this in the spamhaus documentation at...
https://www.spamhaus.com/product/help-for-spamhaus-public-mirror-users/
Last night, one of our private DNS servers was incorrectly flagged by them as being a public and open resolver, and they began returning request rejections in the 127.255.255.0/24 range. Surprisingly, the result was the rejection of all incoming items until our monitoring alerted us, and we disabled the zen.spamhaus checking, and raised a ticket with spamhaus.
We never suspected the cPanel DNSBL implementation would be that silly, and looking at the implementation, it's a fairly minor correction that's needed.
For example, to reject on SBL, CSS, XBL and PBL (all contained in ZEN), the following targeted test should be used...
Currently the cPanel implementation just uses a naive test of...
That fires off a rejection for any non-empty reply - including the 127.255.255.0/24 group which spamhaus clearly describes as "ERRORS (not implying a listed response)".
This is not an enhancement. This is just a basic bug fix that's needed.
Best regards,
LBJ
Using the tick-a-box method of enabling zen.spamhaus.org via the Exim Configuration Manager can result in naively rejecting clean email based on any non-empty return value.
As per the spamhaus documentation, their system isn't limited to the basic return values in the range 127.0.0.[2..11] for listed IPs. They can also return a value of 127.255.255.0/24 as per...
https://docs.spamhaus.com/datasets/...icMirrors/MTAs/020-Postfix.html#configuration
The 127.255.255.0/24 values are used to signify a rejection of the actual request itself for a few different reasons - excessive request rate, perceived public DNS server traits,
open resolvers, and more. Rejecting email based on a return value in that range is simply wrong.
Point number 1 covers this in the spamhaus documentation at...
https://www.spamhaus.com/product/help-for-spamhaus-public-mirror-users/
Last night, one of our private DNS servers was incorrectly flagged by them as being a public and open resolver, and they began returning request rejections in the 127.255.255.0/24 range. Surprisingly, the result was the rejection of all incoming items until our monitoring alerted us, and we disabled the zen.spamhaus checking, and raised a ticket with spamhaus.
We never suspected the cPanel DNSBL implementation would be that silly, and looking at the implementation, it's a fairly minor correction that's needed.
For example, to reject on SBL, CSS, XBL and PBL (all contained in ZEN), the following targeted test should be used...
Code:
dnslists = zen.spamhaus.org=127.0.0.2,127.0.0.3,127.0.0.4,127.0.0.5,127.0.0.6,127.0.0.7,127.0.0.8,127.0.0.9,127.0.0.10,127.0.0.11
Code:
dnslists = zen.spamhaus.orgThis is not an enhancement. This is just a basic bug fix that's needed.
Best regards,
LBJ
Last edited:
