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