On Fri, Nov 14, 2008 at 1:45 PM, John C Klensin <john-ietf@xxxxxxx> wrote: > > > --On Thursday, 13 November, 2008 11:56 -0500 Rich Kulawiec > <rsk@xxxxxxx> wrote: > >> On Wed, Nov 12, 2008 at 11:33:46AM -0800, Randy Presuhn wrote: >>> Huh? Concrete, real example: I send a message to an IETF >>> mailing list. A list subscriber's ISP rejects the forwarded >>> message. IETF's mailman drops the subscriber, because this >>> has been happened multiple times. I can't notify the >>> subscriber, because their ISP also rejects my email. >> >> 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.: >>... > > Sigh. > > Rich, you can blame "someone else" all you like, but the reality > here is that > > (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. This strikes me as unrelated to DNSBLs. Am I misunderstanding? How is this DNSBL-specific? Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf