Eliot Lear wrote: > On 11/10/08 10:37 PM, John Levine wrote: >>> I hope the charter, unlike the previous one, will require the >>> development of a protocol for communicating email sender reputation >>> that can be implemented in email products without known patent >>> encumbrances that are incompatible with open source software. Email >>> is simply too important to allow otherwise. >>> >> >> Not to belabor the totally painfully obvious, but DNSBLs are a >> protocol for communicating email sender reputation that are >> implemented in open source software without patent encumbrances and >> have been for a deacade. >> >> What would be the point of yet another WG to reinvent this wheel? >> > > I tend to agree. Here are a few questions for the IESG when considering > this matter: > > 1. Would declining to publish as a standard harm or hurt the > community? Would refusing to publish as a standard stop implementations > or merely create potential interoperability issues that could lead to > more legitimate messages being dropped? How are either of these questions relevant to the criteria in RFC 2026? > 2. Does the IESG perceive that the creation of a working group would > substantially change the content of the document in question? Put > another way, what would a working group consider doing differently? The working group could analyze the requirements of a reputation service based on IP address, determine whether and how any newly discovered requirements could be met using DNS, and fill in any details that are missing from the informational specification that are needed for reliable and robust interoperation _of the mail transport system_ when using DNSxBLs. Given the obvious use of this protocol as a means to influence mail delivery decisions, I do not think it's appropriate to evaluate this system as merely a protocol for carrying single bits of data independent of their semantics. It needs to be evaluated for its effect on mail delivery. Examples of details that need to be specified, at a minimum, include TTLs (what should they be set to and why), security, TXT records (which IMHO should be mandatory, along with a specification for how they're returned in SMTP which should also be mandatory, and some specification for what those TXT records say or point to). I suspect there are additional details that also need to be specified. My belief is that among the goals of standardizing this practice would be: To improve transparency and accountability of DNSBLs to end users over what it is now, to improve security and reduce the potential for use of DNSBLs for attack (including both DoS attack and thwarting of spam blocking), to improve consistency in reporting between different DNSBLs. > 3. Would publishing on some other track serve a legitimate purpose, > other than to duck the above two issues? Publishing the current document (with appropriate revisions) as Informational would help avoid the conflict between accurately documenting existing practice and observed experience with that practice (which is entirely appropriate for Informational), and documenting desirable practice (which is what standards are for). Efforts to do both at the same time always, in my experience, produce poor results. Perhaps more obviously, publishing the current document as Informational allows documentation of existing practice in a short timeframe, and > If the answer to the last question is "no", then I ask that the IESG > properly address the first two. I hope the IESG will respect our established process, and recognize that (a) there are indeed technical omissions in this document, and (b) the document as currently written does not have rough consensus of the IETF technical community, as shown already by the expressed concerns of several contributors to this list. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf