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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf