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

Reply via email to