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.:
reject=550 5.7.1 <fred(_at_)example(_dot_)com>... Mail refused -
[201.45.252.2] listed by Spamhaus (http://www.spamhaus.org) - forward this
message to nov-13-2008(_at_)example(_dot_)com if you believe this is a mistake
of course nov-13-2008(_at_)example(_dot_)com needs to be exempted from the same
blocking and should forward to the postmaster/abuse staff at example.com.
There are many other ways to accomplish the same thing at minimal effort
and cost; the unifying factor they all share is that recognize that all
anti-spam setups have non-zero FP rates, so it's a good idea to be prepared
to deal with those situations when they arise.
---Rsk
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf