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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf