Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists Thu, 17 April 2014 06:23 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8DE3E1A03D6 for <>; Wed, 16 Apr 2014 23:23:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 2.794
X-Spam-Level: **
X-Spam-Status: No, score=2.794 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KY1359IdR4pM for <>; Wed, 16 Apr 2014 23:23:22 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 942291A0025 for <>; Wed, 16 Apr 2014 23:23:22 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Wed, 16 Apr 2014 23:18:17 -0700 (PDT)
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=iso-8859-1
Received: from by (PMDF V6.1-1 #35243) id <> (original mail from for; Wed, 16 Apr 2014 23:18:07 -0700 (PDT)
Message-id: <>
Date: Wed, 16 Apr 2014 23:00:42 -0700 (PDT)
Subject: Re: DMARC from the perspective of the listadmin of a bunch of SMALL community lists
In-reply-to: "Your message dated Mon, 14 Apr 2014 10:53:42 -0700" <>
References: <> <> <> <> <> <>
To: "Murray S. Kucherawy" <>
Cc: "" <>, ietf <>
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: Thu, 17 Apr 2014 06:23:26 -0000

> On Sat, Apr 12, 2014 at 4:35 PM, <> wrote:

> > The underlying technical issue is that the two technologies DMARC is built
> > on -
> > DKIM and SPF - both attach additional/restrictive semantics to
> > longstanding mail
> > system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.)
> >

> Something's amiss here.  What new semantics does DKIM attach to From:?  As
> far as I know, it only requires that the field be signed.  It doesn't
> require that it be interpreted in a particular way or that it contain any
> particular value.

I was trying to be brief. Yes, I'm well aware that DKIM can be used in other
ways. This entire discussion is within the context of DMARC here. Do you
disagree that DMARC's use of DKIM and SPF assign additional semantics to header
and envelope from fields respectively?

> > Like it or not, the IETF published a draft that defines certain mechanisms
> > which, if used improperly by a large provider, cause serious problems for a
> > large number of people. The text describing the consequences of the use of
> > those mechansisms in the drafts is, IMO, entirely inadequate.
> >

> It's the same document that was posted on other web sites for some time,
> and was in use by a number of operators (including Yahoo) long before it
> went into the datatracker.


> As it's only a draft, there's ample opportunity to make such improvements.

You're missing the point. When Yahoo made this change wouldn't it have been
nice to be able to point to the draft and say, "This is explicitly contrary
to what the draft says"?

> Also: By "the IETF published a draft", are you talking about an RFC, or the
> DMARC base draft?

The draft, of course.

> It seems extreme to lay blame on the IETF in general
> merely for having an open mechanism by which to post a draft for all to see
> and discuss.  A "Request For Comment", as it were. 

You may think it extreme. I don't. I think the IETF's politics have led to  it
inching closer to moral hazard territory for a long time, and with this
incident it has stepped in it.

> Are you suggesting that
> process should be closed or moderated somehow?

What I suggested is that we need to have a serious discussion of what, if
anything can be done to ameliorate the damage in this case. Others have
suggested that we also need to look at how to prevent this from happening
in the future. I concur.

> > And it's not like we didn't know. As others have pointed out, this issue
> > existed in the earlier ADSP proposal. It was given insufficient attention
> > there as well.

> As with any draft, its content is only as good as its contributions and the
> reviews it got.

I hope you're not saying that this is now fault of the people who failed to
contribute to the draft.

> > Of course the IETF can fall back on the usual excuses, including, but not
> > limited to:
> >
> >     Yahoo, of all ISPs, should have known better
> >     We don't tell people what to do
> >     It was just a draft
> >     It was never intended to be a standard
> >     We're not the Internet Protocol Police
> >     etc.
> >
> > I'm sorry, but this time none of these dogs are hunting for me. An
> > attractive
> > nuisance is an attractive nuisance, and this is what the IETF has, albeit
> > with
> > the best of intentions, managed to create.
> >

> I would add to this that, by its ultimate inaction in the face of a
> protracted period of abuse and attempts by participants to solve that
> problem within its procedures, the IETF has abdicated any authority it may
> have had.

That may be your assessment. Given subsequent comments from other people,  mine
is now that this effort was looking for a rubber stamp, didn't like it when
that didn't happen, and proceeded to skirt around the edges of the process.

With disasterous results.