On 5/13/2022, John Levine via mailop wrote:
It appears that Chris via mailop <[email protected]> said:
On 2022-05-13 12:57, Grant Taylor via mailop wrote:
I suspect that their $BLOCKING method has progressed to false positives
as a way to get email administrator's attention.
It's progressed to false positives because some people run mail servers
who aren't parsing DNSBL return codes right.
What he said. My mail server isn't very good at telling one return
code from another so once a week I run a dedicated script on each
DNSBL I use to make sure it does return a reasonable result for
127.0.0.2 and no result for 127.0.0.1. If it doesn't, I stop using it.
In the past I had advocated for DNSBL clients to validate response
codes. Back then my recommendation was to ensure a response within
127.0.0.0/8 and not within 127.0.0.0/31. Now, over a decade later, I'm
going to suggest that 127.255.255.255 also be flagged as an error,
logged, and the query not be used as a source of reputation.
Additionally, I just want to remind people that there are many ways that
a DNSBL operator could attempt to inform users of policy issues;
* CNAMEs as flags to listed objects
* Flagging in response codes to listed objects
* List nothing
* Return error (SERVFAIL or REFUSED)
* Drop the request
* Return NS records to things that fail or are really slow.
* List everything
.. But because there is no actual user sitting behind the DNSBL client,
and many DNSBL clients don't validate response codes, only a couple of
those might actually be understood by someone reviewing logs (both on
the mail server and the local resolver)
SgtChains
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
