Re: DMARC-4-ML: Can the IETF call a demonstration? Wed, 14 May 2014 16:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D40111A02ED for <>; Wed, 14 May 2014 09:34:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B4tJ57Kk8Y9a for <>; Wed, 14 May 2014 09:34:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3A38A1A0133 for <>; Wed, 14 May 2014 09:34:27 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Wed, 14 May 2014 09:29:21 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from by (PMDF V6.1-1 #35243) id <> (original mail from for; Wed, 14 May 2014 09:29:15 -0700 (PDT)
Message-id: <>
Date: Wed, 14 May 2014 08:36:09 -0700 (PDT)
Subject: Re: DMARC-4-ML: Can the IETF call a demonstration?
In-reply-to: "Your message dated Wed, 14 May 2014 08:39:40 -0400" <>
References: <> <>
To: John C Klensin <>
Cc:, Alessandro Vesely <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 May 2014 16:34:32 -0000

> --On Wednesday, May 14, 2014 13:52 +0200 Alessandro Vesely
> <> wrote:

> > After some discussion on ietf-822, two viable methods were
> > identified for DMARC for mailing lists (ML).  Someone cutely
> > suggested to do both:
> >
> > *Tweak DKIM signatures*
> >...
> > *Whitelist*
> >...
> > Both methods require each domain to build a DB of MLs.  That
> > can be done by a "manual process" (see picture) for the time
> > being.  The process consists of each ML admin extracting a
> > per-domain list of subscribers and sending it to the relevant
> >...
> > Will the admins go marching in?

> 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.

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

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.

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.

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.

> (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
>, 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.

> Contrast that with, e.g., privacy issues about
> which there have been consensus statements in the IETF, perhaps
> even statements strong enough to justify some additional costs.

> (3) Since I mentioned privacy, I should note that developing,
> keeping, and maintaining the database you mention could have
> significantly more privacy risks than simple recording of
> envelope information in server logs.  If IETF is now committed
> to privacy as a significant goal, that question needs careful
> evaluation.

Good point. I don't think the database approach is remotely viable for other
reasons - mostly that I've yet to encounter an ISP or MSP willing to take on
the task of building and maintaining such a thing - but the privacy aspect
do warrant some consideration.

> > 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.)

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

> 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.

> > 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.