I think you're missing the point. 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. Even assuming that there's some benefit in having third-party reputation services (which IMHO is not well-established), use of DNS to communicate such reputation, and basing such reputation on IP addresses, is itself very dubious. 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. We're arguing about whether to standardize a facility that causes problems for everyone. 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. Keith Chris Lewis wrote: > As the architect of a large email infrastructure, a senior technical > advisor to the Mail Anti-Abuse Working Group, and ASRG member, I find > myself disagreeing with the points made by John and Keith that I > included at the end. > > As a consumer (and producer) of DNSBLs, I need technical standards that > define DNSBL protocol so I can spec/build/acquire/use software that > interoperates correctly and maintains/improves the reliability of our > email and email in general. > > I also want policy predictability in the DNSBLs I use or am likely to > encounter when our users send email, but that does not belong in a DNSBL > technical standard on protocols. It belongs in a different document. > More below. > > Yes, the very existence of DNSBLs is unfortunate, but they have become > an outright necessity for many mail systems. Our (and many other, > including all of very largest) mail infrastructures heavily rely on > DNSBLs for the majority of their filtering. No other filtering > technique deals as effectively with the massive floods of spam and other > malicious content that we receive (in some cases well in excess of 90% > of all email). > > Yes, some people honestly believe that the use of DNSBLs for blocking is > a bad idea. But those objections fall away when they're used in > aggregate scoring systems like SpamAssassin, where they're just one > minor factor of many. DNSBLs need to be standardized, whether they > block an email, tweak a score a bit like SpamAssassin, or as in some > environments, improve an email's likelihood of getting through (eg: > whitelists). > > There are many advanced non-DNSBL techniques that can and do work well > in place of DNSBLs on small to medium systems. Unfortunately, they are > either considerably less ineffective or are impractical in large to very > large systems trying to withstand the full spectrum of email abuse that > they have to deal with daily. DNSBLs (locally sourced or otherwise) > often make the difference between email remaining useable or becoming > unuseable in environments like ours. > > It is but one tool of many tools. Yet, for many infrastructures, by far > the most effective. Virtually every major email system uses DNSBLs in > one way or another, whether it's visible or not, whether it's used > directly by themselves, or in concert with other mechanisms (eg: scoring). > > Failing to standardize the technical protocols used by them would be a > major mistake. > > More specific points: > > 1) There are no technical omissions in the specification that I am aware > of. It is a technical specification of the bits on the wire (the > protocol), with little else. > > 2) I presume the "technical omissions" comment was intended to mean a > lack of standardization of "how things got on and off DNSBLs". These > are not, and should not, be considered technical issues. Specifying how > something got on and off a DNSBL would be equivalent to insisting that > RFC2822 attempt to standardize how mail readers insert an email address > in the To header. RFC2822 specifies the format of To headers, not how > they got there. > > Yes, there are issues about such things, and consistency in some of > these areas is desired. But, they do not belong in a technical > standard. This is why I, Matt Sergeant, and others have been working on > a DNSBL policy BCP what could be considered a companion document: > http://www.ietf.org/internet-drafts/draft-irtf-asrg-bcp-blacklists-04.txt > > I hope to make a few final grammatical changes to the above document in > the next few days and move it on towards last call. > > 3) Making draft-irtf-asrg-dnsbl a standard (and ultimately approving the > BCP) serves to improve the consistency and interoperability of DNSBLs, > and therefore email itself. Not making it a standard only perpetuates > uncertainty on the protocol itself, failure to implement software that > interoperates correctly, unpredictable (and some times capricious) > failure modes, and ultimately impairs the reliability of email. > > Case in point: If a DNSBL domain becomes unregistered, and is picked up > by a reseller, they usually insert DNS A record wildcards causing web > queries to go to a common web page. Or if a DNSBL domain is mispelled > by its users, it may collide with a different domain that wildcards A > records. Such scenarios aren't rare, they happen frequently. Without > this standardization, the implementors of DNSBL clients don't realize > that DNSBL queries that return A records outside of 127/8 is an error > condition not a positive result. Such mail servers usually end up > blocking ALL of their email - concrete examples of where lack of > standardization drastically impairs email interoperability. > > John C Klensin wrote: > >> Sadly, I have to agree with Keith. While these lists are a >> fact of life today, and I would favor an informational document >> or document that simply describes how they work and the issues >> they raise, standardizing them and formally recommending their >> use is not desirable at least without some major changes in our >> email model and standards for what gets addresses onto --and, >> more important, off of-- those lists. >> >> john >> >> >> --On Friday, 07 November, 2008 18:38 -0500 Keith Moore >> <moore@xxxxxxxxxxxxxxxxxxxx> wrote: >> >>> DNSBLs work to degrade the interoperability of email, to make >>> its delivery less reliable and system less accountable for >>> failures. They do NOT meet the "no known technical omissions" >>> criterion required of standards-track documents. >>> >>> The fact that they are widely used is sad, not a justification >>> for standardization. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf