Re: DMARC: perspectives from a listadmin of large open-source lists

Dave Cridland <> Tue, 15 April 2014 07:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 29DDF1A031D for <>; Tue, 15 Apr 2014 00:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.521
X-Spam-Status: No, score=0.521 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0HMv5dqPyEyp for <>; Tue, 15 Apr 2014 00:42:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c02::234]) by (Postfix) with ESMTP id 3D8CA1A019D for <>; Tue, 15 Apr 2014 00:42:15 -0700 (PDT)
Received: by with SMTP id l6so10456340oag.11 for <>; Tue, 15 Apr 2014 00:42:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xkXiHdfovNU76aAHJpVO8sn6fdE4Knp8o6mpWCJgmnI=; b=PbmfWdlULJ7yDbmA0DoQWwKNbn0Tl4Ld/cEdKUBOVW34R3arSqwt3a2JK3cRwE6z8m 2v71rGJwB62iUCJL3IcYrwtSLZUdhVgVsFMuPIVQAAF/rQYRwHbYjJuOs1IzqQhuy6do XmVuWfRAbjTPUzy3Q/c8Im1SdcTHNhNw2KwuU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=xkXiHdfovNU76aAHJpVO8sn6fdE4Knp8o6mpWCJgmnI=; b=XsujIaXFbgkn5sqUfn77M557WOjQ9biDJwfbDPCqvR8DUipilY6mdLI82HCYX+pzHH 3AXkBfE0azFP+NYfdmfAr49YcnuCLqlukZjesMRuy9HjxcLaev/DH1PENwKAOAK0Mcx1 mnTFDF/EUDgI3vgnlHmwut3etJhfxtycX0EE5quMuHiZHyYTF8+cUXt6JVquc+pkKPut eQHAjvYEZWs7iuBnICakG7MkBm2Z5hxpNUHzkhQbz0FQPvLDWDhRQNzxoRDlhgPFUG36 xYAZjQH3/fRSS97Ptv9qSNnaTTtvDV0NFxGiyC24P2euWOXXD2ZYNAikZw7cg5Akvqat 0eog==
X-Gm-Message-State: ALoCoQlHixD8BQkILrxNJU84VhVKPdEdqn7fj9cf7xwurrIS/erO8vPsmtInc1r8rDFOvEImOKfH
MIME-Version: 1.0
X-Received: by with SMTP id s5mr158268obf.35.1397547732240; Tue, 15 Apr 2014 00:42:12 -0700 (PDT)
Received: by with HTTP; Tue, 15 Apr 2014 00:42:12 -0700 (PDT)
In-Reply-To: <>
References: <20140414024956.26078.qmail@joyce.lan> <> <alpine.BSF.2.00.1404132327560.26258@joyce.lan> <> <alpine.BSF.2.00.1404132346420.26386@joyce.lan> <> <> <> <> <> <> <> <>
Date: Tue, 15 Apr 2014 08:42:12 +0100
Message-ID: <>
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
From: Dave Cridland <>
To: "Murray S. Kucherawy" <>
Content-Type: multipart/alternative; boundary=001a11c2a20c231f6b04f70ff0d1
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: Tue, 15 Apr 2014 07:42:19 -0000

On 15 April 2014 01:11, Murray S. Kucherawy <> wrote:

> On Mon, Apr 14, 2014 at 3:02 PM, Dave Cridland <> wrote:
>> One of the very specific items that was on the proposed charter was
>>> dealing with the question of how to integrate DMARC with mailing lists.
>>> This was called out very early on as an open issue, as were some other
>>> important ones:
>> Right, but the WG was expected to make it work with mailing lists without
>> changing it. Tough ask.
> Could it not have been done as an extension?  And as I recall, one of the
> proposed paths was to just record and publish DMARC as it is now, and then
> get a WG going to help revise it into something that also resolves the
> questions in the proposed charter, on the standards track.  This also
> failed to gain acceptance.

An "incremental and optional" extension which would not require changes to
the deployed software and operational practises. You want an optional
extension which would optionally allow DMARC to traverse mailing lists
usefully when it's optionally deployed? Good one. Can I base it off ACAP?

In fact, I can't find any evidence for willingness to let go of change
control. The closest I can find is a year and a day ago, when you said:

"I'm pretty sure the intent is to publish the current base draft through
the ISE, since it was developed outside the IETF, but if it changes (via
rechartering), move it to the IETF stream.  The latter can obsolete the
former if the timing warrants doing so.  Thus, if the working group is ever
actually cracking open the base draft, it's on the IETF stream."

Note, that's "via rechartering", so the WG was not initially chartered to
change the base spec. The actual proposed charter says it could recharter
in extremis, but that's after two paragraphs explaining why it shouldn't.

>> Sorry, but given the way in which IETF participants were asked to work on
>> DMARC, there is absolutely no way you could say that the "DMARC people came
>> to the IETF to [...] complete development" - it was more or less stated
>> that development was done and dusted - and the IETF didn't reject it on the
>> basis that no engineering work remained - the DMARC people rejected any
>> engineering work happening.
>> It doesn't actually matter whether you think the reasons behind this were
>> valid; the fact is that you're putting one heck of a slant on recent
>> history, and it's not borne out by what's in the archives.
> I remember what was said.  I'm not trying to be revisionist here.  Rather,
> I think I'm trying to remember all the details of a very chaotic
> negotiation.
Go read the archives. Refresh your memory.

> I can't say I blame the DMARC people, or anyone for that matter, for
> trying to insulate itself against its work being bogged down for months or
> longer rat-holing on things as has been the fate of so many past efforts in
> the same area.  (See the thread Wes George started this morning
> separately.)  Maybe they tried too hard and maybe I even contributed.  But
> I also think maybe the IETF needs to rethink its position on taking on work
> from outside organizations in the first place, which was one of several
> road blocks that came up.  Another is that it was too far along the
> deployment axis to be eligible for consideration as new IETF work,
> regardless of whether the main document was up for revision.  Yet another
> is that despite repeated requests, we couldn't even more than a couple of
> people (I can remember four) to submit substantive reviews of the current
> document; it seemed like the IETF wasn't interested regardless of the other
> "regulatory" issues.
It's hard to be interested in doing IETF work on something that wasn't
managed by IETF process, or IPR rules, and was actively marketed as being
done, deployed, and not subject to further change. "Please review our
specification so we can ignore your comments and rubber stamp the result"
is not a tremendously attractive proposition.

I suspect that had the IETF been involved considerably earlier, none of
this would have happened. I'm not really sure how this could have been
fixed, as I've noticed a strong tendency amongst organisations which
control large proportions of the deployed market to assume that minority
viewpoints do not count. The "60% of all mailboxes" fanfare is an example
of this. I've seen similar from browser vendors in WebSocket, and I've no
doubt that the major router vendors play the same card with BGP et al.

Some of this is understandable - expertise and experience do tend to pool
at such organisations - but increasingly I feel that we've lost sight,
somewhere, that - for example - because 60% of the world's mailboxes are
handled by the DMARC cabal, that still leaves 40% who may have somewhat
different needs and requirements from the protocol. Given the expense and
difficulty of IETF participation for smaller organisations and individuals,
it's hard for them to club together and stand up to the 8000lb gorillas.

DMARC is not an IETF standard - you know this, I realise - but there was no
sense from the messages exchanged a year ago that it ever would be an IETF
product in anything more than - perhaps - name.

> I don't have any idea how to retroactively fix all of that, and I suspect
> it would be another rat-hole to try.  What I'd really like to talk about is
> where we go from here.
It really depends on whether the 8000lb gorillas are open to letting go of
the change control or not. A year ago they clearly weren't.