Keith Moore wrote: > I think you're missing the point. Oh, no, I fully understand the point. In contrast, I think you're relying on false dichotomies. For example: > Better "interoperation" of a facility that degrades the reliability of > email, by encouraging an increased reliance on dubious filtering > criteria and rumors, is not a desirable goal. There is no such thing as a filtering mechanism that is 100% accurate, and hence all are dubious to one degree or another. Every technique relies upon factors that are based on intuition and experience, rather than physical law. A demonstrable assertion that "IP x is demonstrably infected with Srizbi and anything it emits is probably crap" and communicated by DNS is much less dubious than "this combination of random content fragments makes it look like a Nigerian 419, sorta, marginally". Indeed, experience shows that a correctly chosen set of DNSBLs is often not only more effective than other techniques in correctly identifying malicious email, can often have far fewer false positives than just about any other mechanism. It certainly is counterintuitive that "source reputation" might be more accurate than "per email evaluation". But, experience in the field demonstrates the true reality - the current state of the art is that intelligently chosen DNSBLs (the aforementioned BCP is intended to help that) often work much better than complete reliance on the latter. Furthermore, incorrect DNSBL listings are easier to cope with than, say, random combinations of SpamAssassin scores that just happen to zap a desirable email. This is not specific to SA. It's just as applicable to other things like Bayesian. We run DNSBLs and SpamAssassin here on the MXes. The former catches 10 times as much as the latter, FPs less, and is a lot easier to explain and remediate than the latter. We _hate_ SA FPs, because it's so much more difficult to ensure that it doesn't repeat. [The obvious Bayesian/SA remediation (whitelisting email addresses) isn't good enough. Virtually all malicious email is forged. Thus, whitelisting senders leaves you wide open to getting zapped by forgeries.] > Even assuming that there's some benefit in having third-party reputation > services (which IMHO is not well-established), Again, a false dichotomy: DNSBLs are not necessarily third-party, and other perfectly reputable techniques (eg: outsourcing your spam filtering to a spam filtering company or relying on your ISPs filtering) are third party by definition. Indeed, running your own copy of SpamAssassin on your own mail box is just as much giving away "control" of your filtering to a third party with their own evaluations techniques of greater or lesser dubiousness. Is it not third party because you can tweak the rules of SA? You can also locally whitelist around DNSBL entries. The only way you can get away from "third party" is to write your own filters from scratch, and ignore everybody else's heuristics. I generate several DNSBLs for use here only. Why shouldn't there be a standard so that mail server software I buy/lease/license will interoperate with DNSBLs I create? "Not well-established"? You don't seem to have any idea how prevalent the use of DNSBLs is. It's probably the industry's dirty little secret because of the occasional media event. But there have been similar media events about other filtering techniques that aren't 3rd party, nor source reputation. The reality is: almost everybody uses DNSBLs, and ALL of the very big sites do. > use of DNS to communicate > such reputation, and basing such reputation on IP addresses, is itself > very dubious. You may think it dubious, but it is usually more reliable and effective than any other, and its popularity alone means it needs to be standardized. Rejecting the standardization of DNSBL protocols because the entries of a specific DNSBL _might_ be dubious is in itself a dubious position. > The problem isn't just the rumor passing mechanism, but > the mechanism is indeed part of the problem. > > It's not as if we're arguing about whether to standardize a facility > that is widely believed to work well. It is widely believed to work well. That's part of the point. > We're arguing about whether to > standardize a facility that causes problems for everyone. No more so than filtering in general. > Back when I started working with email, getting a message reliably > delivered was something of a black art, because you had to know how to > thread your message through the hodgepodge of Internet, uucp, BITNET, > DECnet, fidonet, and whatnot. That was in some sense understandable > because Internet access was not widely available, and there wasn't > really any common network that everybody could tap into. > > Today, getting a message reliably delivered is once again a black art. > But today, it's not for lack of standards or network connectivity. It's > because so many messages are filtered for dubious reasons, or on the > basis of what are essentially unsubstantiated rumors, or because of > over-reliance on IP source addresses as identifiers. DNSBLs exist and their use is extremely widespread because the industry _does_ believe in them. There is a very large number of efforts to demystify DNSBLs and deal with DNSBL issues. DNSBLs used to provide positive reputation, not just negative. It is no longer the black art of that hodgepodge of networks both you and I remember trying to support way back then. It is well-established and has evolved a long way from Vixie's original RBL. We have to get our heads out of the sand and put it on a solid standards footing to finish the job of de-black-arting it. As for capricious/rumors and so on, please refer to the proposed BCP I mentioned earlier. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf