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.
My ISP is irrelevant to the scenario, and the (now former) list subscriber
doesn't even know this has happened, or why.
That sort of thing is rarely due to a DNSBL issue. DNSBLs are usually
on peers. For your email to have been blocked via both the IETF and
directly from you, it usually would have had to have been both the IETF
and you that was blocked by the list subscriber's ISP. Which one would
hope would be a rare circumstance...
It was probably a content filter.
We whitelist many mailing lists and forwarders by IP, especially those
that talk about spam.... Unless they leak LOTS of real spam (we're
talking > 99% spam). And some do.
Another real, concrete example: some (but not all) messages sent via my
employer were tossed because one of my employer's mail servers was
listed on a blacklist. As an employee, I had no alternatives for sending
mail - company policy precluded the use of "webmail" alternatives via
company infrastructure.
The duration of that event should have been short (and usually is). And
companies do have means to deal with such eventualities.
For example, in a situation like that, many people can cope by sending
such critical email by non-company infrastructure. Or relax the rules
for the duration of the problem.
Once or twice we've been inadvertently hit by a similar blacklisting.
They've always been resolved very quickly with little harm done.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf