--On Wednesday, May 14, 2014 08:36 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
...
Ale,
At the risk of repeating myself...
(1) I think it is a bad idea for the IETF to be formally
spending effort to work around damage caused by a non-IETF
protocol. I note that, if this were a protocol that was
specified in the IETF and over which the IETF had change
control, we would be trying to fix the protocol itself or
would withdraw or depreciate it because of the damage caused.
This misrepresents the situation so substantially it is
essentially a strawman argument. In particular, DMARC did not
emerge, full formed, out of the void. It's the logical
evolution of ADSP, a standards-track IETF protocol.
A standards-track IETF protocol that was deprecated by a process
that claimed it was unused and harmful. If it had been the
intent to replace ADSP with an IETF-developed DMARC, that would
properly have been handled by submitting the DMARC specification
for standards-track publication, one that obsoleted and
deprecated ADSP and that, to the degree appropriate,
demonstrated that it solved the problems that made ADSP
problematic.
In fact an argument can be made that in terms of responsible
mail handling, DMARC is actually an improvement over ADSP. In
particular, ADSP provides policy choices of "unknown", "all",
and "discardable", wheras DMARC provides "none", "quarantine",
and "reject". Honoring a "discardable" policy causes mail to be
lost, whereas at least "reject" provides an indication that
something went wrong.
So? Based on the argument that ADSP was broken, there was an
IETF discussion and a decision by the IESG that community
consensus justified deprecating it and moving it historic.
Whether DMARC is better or not, derived from IETF work or not,
it was not developed as an IETF protocol and the IETF was not
consulted before it was deployed.
The fact that ADSP was developed in tandem with DKIM also
means that the IETF cannot reasonably claim that attaching
these sorts of semantics to From: fields was in any way
unexpected. As such, there was at least a resposibility to
document likely interoperability problems use of DKIM in this
way would cause.
Yes, I agree with that. I don't know why that wasn't done when
either DKIM or ADSP were published, but suggest that, had DMARC
been exposed to the IETF consensus process, it would have
provided an additional opportunity to get those problems noticed
and documented. Of course, no one can guess whether that
opportunity would have led to anything.
But let's suppose for a moment the assertion that this is
simply a case of a non-IETF protocol coming at us out of the
blue. I still categorically reject the assertion that it's not
our responsibility to address the issues it has raised. Our
job is to write documents that improve email.
I don't recall saying anything about "out of the blue". All
I've asserted is that DMARC itself was not developed within the
IETF, using an open process, was not approved via an IETF
consensus process, and that the IETF does not have change
control over its evolution.
Now, if dmarc.org wanted to turn the protocol over to the IETF,
give IETF change control, and propose it for the standards
track, we would be having a different discussion. And I assume
that many of us would join in trying to insist that
standards-track publication not occur without at least a clear
set of health warnings and possibly modifications to other
protocols and procedures to contain the damage.
Of course a line has to be drawn somewhere; the IETF can't
possibly respond to every single stupid thing that people do
on the Internet. But when three of the largest MSPs in
existence decide to publish problematic DMARC policies and
large numbers of email receivers have implemented DMARC
checks, resulting in widespread damage, and subsequently
refuse to reconsider those policies, I think the line was
crossed.
Suppose I agree (I've got mixed feelings about that, but set
them aside). IETF participants can discuss the issue using IETF
facilities. That has been happening and I certainly don't
object to it. However, for the IETF to actually recommend an
action requires that we have a document and some sort of
community consensus. To my best recollection, we've never said
"don't use that" or "use that only this way" to something that
was not an IETF (or predecessor)-developed protocol without
providing a substitute. If people want to do the work and there
is any hope of adoption, I'd be in favor of a DMARC2 effort in
the IETF.
Of course, if "three of the largest MSPs in existence decide to
publish problematic DMARC policies" that result in advantages to
them but cause harm to others, that could also be interpreted in
other ways that are outside IETF scope and should stay that way.
(2) I believe it is unacceptable for a new protocol or
capability to impose costs on operators of other systems in
the absence of clear and broad consensus about why the
changes are needed and appropriate. That consensus may well
exist for DMARC and its policy statements among the
contributors/ supporters of dmarc.org, but it is fairly clear
to me that it does not exist in the IETF.
The "new protocol" of which you speak is, in fact, a
combination of three pieces: DMARC, SPF, and DKIM. Two of
thoese are standards-track protocols, and one of those (SPF)
has a built-in policy mechanism which, if used, most assuredly
does "impose costs on operators of other systems".
And as I noted above, it's not like the IETF didn't publish
ADSP on the standards track, or that this usage of DKIM was a
surprise.
So it seems that the IESG felt there was an IETF consensus in
this area.
Or that the IESG and the community were not paying sufficient
attention. I would agree if you said "that is no excuse", but
it calls the way we do some sets of protocols like this into
question.
...
Doing nothing will result in a mix of three reactions. 1,
ML admins changing the From: of domains who publish strict
DMARC policies; 2, some users changing mailbox provider;
and 3, less domains publishing strict DMARC policies.
Or 4. ML revoking the posting rights of users from domains that
report policy errors. Or 5. Rather than unsubscribing the
failing recipients, either ignore the error or report the
failures to the original message sender, thus making it clear
to them the cost they're paying for the provider they have
chosen.
Except in order to do either of these well you need some
additional status codes, codes which only the IETF can assign.
(And yes, I'm aware that a ML can perform its own check on the
From: domain and if it lists a reject policy refuse the mail,
thus avoiding the need for new error codes. Except that's both
a lot more work with a less reliable outcome.)
Agreed.
The good news, such as it is, is that the relevant registry is
"Specification Required", meaing this can be done in the DMARC
base specification or some other informational RFC. Which I
guess would avoid significant IETF involvement.
Yes.
There are two more options you didn't mention: (4) more
systems either not implementing DMARC or ignoring strict
policy specifications, and (5) driving some users and
activity away from the use of mailing lists entirely in favor
of using more "social network" web sites and activities. I
note that some people believe that DMARC and strict policies
are part of a business model to force that result. I don't
believe that personally, but the optics are unfortunate.
I'll note that "ignoring stricy policy specifications" is not
necessarily a good thing. Having a DMARC failure contribute to
an overall spam score can easilt lead to mail being silently
lost instead of being rejected, with all that implies.
Yes (and see below).
The combined
effect seems to weaken both DMARC and mailing lists.
So? Perhaps we should be focusing more on strategies that
weaken DMARC to the degree necessary or appropriate without
weakening mailing lists or imposing added costs on those who
operate or subscribe to them.
Well, yeah, that's kinda the point of this exercise.
The analogy is obviously not exact, but, if some external
group came up with a protocol that weakened TCP and
undermined all of our congestion control mechanisms, we might
be pointing out the damage and encouraging people to not use
that protocol -- perhaps even figuring out ways to block its
use -- but would not be scurrying to alter TCP to better
accommodate the behavior of that new protocol, especially if
the alterations made "normal" use of TCP less efficient or
effective.
On the contrary, if the protocol that external group came up
with was widely deployed and there were reasonable tweaks that
could make them coexist, I think that's exactly what the
Transport Area would do.
It would be an interesting experiment in some ways. Beyond
that, we'd have to get down to what tweaks (and by whom) would
be considered reasonable.
Disclaimer: As you know, but other readers may not, I've got an
extremely bad attitude toward mail changes that, in the interest
of mitigating delivered spam, violate the basic design
assumptions of Internet email or reduce its functionality. That
is undoubtedly affecting my attitude toward this situation even
though it probably shouldn't.
john