--On Wednesday, May 14, 2014 08:36 -0700 Ned Freed
<ned.freed@xxxxxxxxxxx> 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