On Fri, Nov 14, 2008 at 1:45 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com>
wrote:
--On Thursday, 13 November, 2008 11:56 -0500 Rich Kulawiec
<rsk(_at_)gsp(_dot_)org> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf