On Fri, Nov 14, 2008 at 01:45:51PM -0500, John C Klensin wrote:
This is not a DNSBL problem. This is a problem with the
subscriber's ISP, which is not operating their mail system per
de facto best practices -- which include making sure that
rejection notices provide an alternate-channel means of
contacting them in order to discuss apparently-erroneous
blocking. There are a sizable number of techniques for doing
this; I happen to think the best ones are quite simple, e.g.:
(1) If the system supporting the DNSBL is following the email
protocols and decides to reject the message or bounce it, rather
than, e.g., assigning a score and moving it into the
user-related mail store, it replies back to the IETF list
manager, not the original sender. [...]
But this, and the rest of your points, have nothing at all to do with
the operation of DNSBLs -- and everything to do with the configuration
of some mail systems which *use* DNSBLs. The exact same set of issues
might easily arise due to local checks, and often does.
For example, on the mail systems that I operate, 2/3 to 3/4 of all
incoming SMTP traffic is rejected before any DNSBL lookups are done.
Those rejects are functionally identical to those generated as the result
of DNSBL checks; the only difference is the human-readable text.
---Rsk
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf