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