John Levine wrote:
Today, messages can just disappear on the way to the user's mailbox
(often at or after that last-hop MTA). They do so without NDNs out
of fear of blowback, and they do so for two main reasons. ...
You know, DNSBLs make mystery disappearances less likely, not more.
The DNSBLs that most people use are typically checked at SMTP time, sp
MTAs can give a 5xx rejection using the TXT record from the DNSBL that
identifies why the mail was rejected.
Indeed, and more concretely: NDNs aren't inherently bad (blowback).
It's "accept then generate NDN" that's inherently bad. Anti-spam
techniques that are after the destination's MX should not generate NDNs,
because all of it is potentially blowback by definition.
The "just disappear" argument more applies to techniques that can't NDN
without blowback. Which, includes, for example, ALL client-side
filtering no matter what filtering they use, and all server-based
"accept-then-analyse" filtering. Not DNSBLs per-se.
By far the most common server-based implementations using DNSBLs reject
at SMTP time (usually with some sort of remediation information in the
error message), which suppresses almost all blowback, yet "you" still
find out what happened. In contrast, for example, the most common
implementations of (say) content analysis do accept-then-analyse, and
should not NDN because it'll be blowback.
Full analysis during SMTP time of (say) content and rejecting at SMTP
time is considerably rarer (we're one of the rarer ones). In part
because older revisions of the SMTP standards weren't very clear about
handling of rejections after DATA. We decided to ignore that limitation.
In other words, in general you're far more likely to find out about your
email not getting through (and how to fix it) if it was a DNSBL hit than
most other techniques. It's not intrinsically inherent to DNSBLs, it's
just the "overwhelming experience".
Unlike you, I don't see "overwhelming community consensus for
this mechanism".
Aw, come on. There's a billion and a half mailboxes using the
Spamhaus DNSBLs, on systems ranging from giant ISPs down to hobbyist
Linux boxes.
All of the very largest email and spam filtering infrastructures use
DNSBLs (generally IP-based reputation lists) in one way or another,
whether they tell you or not. I said "all" because I meant "all" -
that's not hyperbole for "most".
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf