Trying to sum up the situation here:
1. Several people have argued (somewhat convincingly) that:
- Source IP address reputation services can be valuable tools for
blocking spam,
- Such services can be better at identifying spam than per-message
content analysis,
- Such services can (and sometimes do) provide better feedback to the
sender, and thus better accountability, than per-message content
analysis that occurs later in the signal path, and
- At least some such services have very low false positive rates.
It's important to keep these in mind, as they appear to make a
compelling case for some kind of standardized reputation service.
2. Several people have also related experiences of valid messages being
blocked by such reputation services, and of the difficulty of routing
around them and getting their reputations corrected.
This strongly argues for such reputation services to have strict
accountability, and for there to be a clear, well-defined means by which
senders can correct erroneous reputations, and to get vital messages
delivered in spite of erroneous reputations.
3. An informal protocol for reporting reputations using DNS has been in
use for several years, and such use has become widespread. An IRTF
group (ASRG) began a useful effort to document this protocol.
4. At some point ASRG decided that the protocol should be on the IETF
standards track and has requested such.
--
This process that produced this proposal reminds me of several patterns
I've seen come up often in IETF.
1. The first pattern is when an author or group gets confused between
the goal of writing an informational document to describe existing
practice, and the goal of writing a standards-track document that
describes desirable practice.
Offhand, I cannot recall a single experience when this has produced
satisfactory results. The two goals are very much in conflict. When
describing existing practice, it is very tempting to add extensions that
seem to be desirable, but which in fact are not part of existing
practice. This is misleading at best, and at worst can cause
interoperability problems (my favorite example of this is RFC 1179).
OTOH, when writing standards that are based on existing practice, it is
very tempting to include existing practice (for the sake of
"compatibility") within the scope of permitted behavior, even when that
practice is dubious for one reason or another - poor security, say, or
poor scalability.
Over the years I've formed the opinion that the only reasonable way to
build a standard from existing practice was to first commit to
accurately documenting existing practice and publishing that document as
Informational. Part of that process should be to document known
limitations of that existing practice. Only after that document is
completed should there be an attempt to design a standard that is
compatible with existing practice. That effort needs to be treated as a
design effort and subject to all of the usual vetting. Furthermore it
needs to be understood that serious flaws from the original protocol
must not be included in the standard for the sake of backward compatibility.
2. The second pattern is when people insist that a widely deployed
protocol is inherently deserving of standardization, without further
vetting or changes, merely because it is widely deployed.
The simplest way of responding to this is that this is irrelevant under
our process. The RFC 2026 criteria for proposed standard status require
both "rough consensus" of the IETF community and "no known technical
omissions".
The fact that something is widely deployed may be a indication of its
utility, but is not an indication of technical soundness. Nor is it an
indication of consensus of the IETF technical community.
3. The third pattern is when a closed industry group, or an open group
that is not chartered to develop a standard protocol, insists that its
product merits standardization by IETF because it has gained consensus
of that group.
The problem with this is that the group did not attract the wide range
of interests that would normally attend an IETF standardization effort,
nor did the group operate under processes designed to ensure fairness
and openness. Such efforts can be considered in the IETF process as
individual submissions, but they need a great deal of scrutiny, as this
tactic is often used as an "end run" around IETF. My experience with
individual submissions is that simple, noncontroversial proposals
affecting a small number of parties rarely present serious obstacles to
standardization, but proposals that affect a large number of parties are
much more difficult, and with good reason.
The main point to be made here is that the consensus of an external
group means nothing in terms of either IETF consensus or judgment of
technical soundness. In particular, external groups often have a much
narrower view of protocol requirements than IETF does.
All of these patterns are associated with delays in accepting a
standard. They are also associated with poorer quality standards.
--
Back to the proposal at hand. We have a proposal on the table for a
service which seems to have significant value if implemented properly.
And yet the proposal omits many of the details that appear to be
required for the service to have value, deferring those to a later "BCP"
document. So there's an argument that the proposal as currently written
is incomplete, and standardization of the protocol is premature at best.
It is worth repeating that just because the notion of a reputation
service has value, and such services are widely used, does not imply
that using IP addresses as identifiers or the DNS protocol as a means of
transmitting reputation are technically sound. There is reason to doubt
both of these assumptions, and there is no evidence that these design
questions have been given due consideration and resolved - as our
process would normally require.
At the same time, the process that produced this proposal has at least
three traits of processes that have been known to cause problems in the
past. This should if nothing else give us pause, and counsel us to
proceed with caution.
So my recommendation to ASRG (and this document's authors) is as follows:
1. Abandon the effort to publish draft-irtf-asrg-dnsbl as a standards
track document, and instead commit to publishing it as an Informational
document as an accurate description of existing practice. Be sure to
document observed limitations of existing practice.
2. Ask IETF to charter a working group tasked with developing a protocol
for communicating email sender reputation. The group can consider
DNSBL as a possible solution but should not be bound by a requirement to
be compatible with it, or to use DNS at all.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf