Re: DMARC: perspectives from a listadmin of large open-source lists Tue, 15 April 2014 15:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 865881A04DC for <>; Tue, 15 Apr 2014 08:17:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 4.994
X-Spam-Level: ****
X-Spam-Status: No, score=4.994 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793, SPF_HELO_SOFTFAIL=0.732, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qKzjIecR0bJb for <>; Tue, 15 Apr 2014 08:17:24 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 870761A0658 for <>; Tue, 15 Apr 2014 08:17:24 -0700 (PDT)
Received: from by (PMDF V6.1-1 #35243) id <> for; Tue, 15 Apr 2014 08:12:19 -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; Tue, 15 Apr 2014 08:12:11 -0700 (PDT)
Message-id: <>
Date: Tue, 15 Apr 2014 07:51:20 -0700 (PDT)
Subject: Re: DMARC: perspectives from a listadmin of large open-source lists
In-reply-to: "Your message dated Mon, 14 Apr 2014 10:28:51 -0700" <>
References: <20140414024956.26078.qmail@joyce.lan> <> <>
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: Tue, 15 Apr 2014 15:17:28 -0000

> On Sun, Apr 13, 2014 at 7:57 PM, Miles Fidelman
> <>wrote;wrote:

> >
> > It strikes me that the real way to address some of these issues is to add
> > a few new headers to SMTP - to get rid of the overloading of the From: and
> > Reply-to: headers associated with mailing lists.  An SMTP extension that
> > would absorb some of the well-known and well-understood functions of list
> > software.
> >
> > [...]
> >

> I made that same suggestion on a different list.  It seems as if that
> suggestion was made long ago and the debate reached "religious"
> proportions.  One of the usual answers emerged, which was that it'll take
> forever to get this deployed with sufficient ubiquity as to be helpful.

Suggestion? Try suggestions. I can think of at least four proposals at various
times, and I'm quite sure there have been others. At least one of them, by John
Myers, was written down in a draft.

And the problems with these proposals weren't religious. Rather, the problem
has always been that originator header semantics are already fairly nuanced,
and adding a bunch of them seems to exceed our design abilities. As a result
the discussions bogged down in misunderstandings about minutiae and talking
at cross purposes.

The only discussion I know of in this space that reached "religious
proportions" was the one in the failed mailing list WG.  But that was largely
focused on the "right" way to use existing header fields, not the addition of
new fields. So I don't think that really counts.

> I'm guessing that means we shouldn't try.

OK, for this to work you're going to have to come up with a solution that's
clear and comprehensible, get general agreement on it, publish it, and then get
widespread support for it implemented and deployed in both list processors and
user agents in a fairly timely way.

I'd also say there's a good chance that DMARC will have to be changed in some
way to support it, so that needs to be on the table. And that support needs to
be deployed.

Given these realities, do you think this is worth spending (a probably large
amount of) time doing?