Re: (DMARC) We've been here before, was Why mailing lists

"Murray S. Kucherawy" <> Fri, 18 April 2014 15:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C27141A03AE for <>; Fri, 18 Apr 2014 08:21:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OaRpHv1Qmsm2 for <>; Fri, 18 Apr 2014 08:21:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22f]) by (Postfix) with ESMTP id D7A8D1A01AF for <>; Fri, 18 Apr 2014 08:21:00 -0700 (PDT)
Received: by with SMTP id x12so602295wgg.18 for <>; Fri, 18 Apr 2014 08:20:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=943BlK5Ui662Pz9WBkdc8NU/5X/23w7glEDp1THibRQ=; b=e4adGdUFxt08wdvzN6WdZ6RCbk/1CM60022FHGwMotwKWwLynenzyetL2bV3wIDDPl TbTqvgxjgGYBzqtHmOpi9um3cQINcJRonK3PnWxLpgd2C+8FtFNO2tdPK/2zBaPZHMqE qNskwzuHJSrXAGvM+oZ4LsqoAZZdMy5H6X5yWYoaVjkCrbX1td1P//Sd9Z3qbT1h1okh FgJN4o7LP4ooIcEjqb8flvXa7jQbKbUbzlPz5PguWuj6KU419f1Gb/VbNuA9bXAN6SmO uFOzkbJleQEaYs0fG9nKUGYSSTNTlMudWehjOb/hTuJvvZLANWqCoBCn70+lGe0Cv0XJ pIVQ==
MIME-Version: 1.0
X-Received: by with SMTP id y9mr2808356wiw.26.1397834455431; Fri, 18 Apr 2014 08:20:55 -0700 (PDT)
Received: by with HTTP; Fri, 18 Apr 2014 08:20:55 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Fri, 18 Apr 2014 08:20:55 -0700
Message-ID: <>
Subject: Re: (DMARC) We've been here before, was Why mailing lists
From: "Murray S. Kucherawy" <>
To: Michael Richardson <>
Content-Type: multipart/alternative; boundary=f46d043894772bc3bb04f752b230
Cc: Pete Resnick <>, John R Levine <>, "" <>
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: Fri, 18 Apr 2014 15:21:06 -0000

On Thu, Apr 17, 2014 at 3:16 PM, Michael Richardson

> So, the bug is that Yahoo/DMARC/ are authenticating the From:, when it
> should
> really be authenticating the Sender:. DMARC should key it's policy from
> Sender: rather than From, and if it did that then:
>   1) we could leave the From: intact, which is what's good for the end
>      users.
>   2) the list would change the Sender:, which is what we would establish
>      the reputation of the list, not the From:
>   3) MUAs would compare the From: and Sender:, and if they differed,
>      could say useful things like:
>      "From: via"quot;.
> (I was also wondering this morning on my commute if a layer of
> message/rfc822
> added by the mailing list might be a useful interim hack)

One of the key points about DMARC's design is that it's concerned
specifically with From:.  The reason is that the content of From: is what's
typically shown to the recipient by MUAs.  If DMARC keyed off Sender:
instead, then this would work:


DKIM-Signature: v=1;; ...

If DMARC pays attention to Sender: in favor of From:, then this passes, but
what the user is shown that the message is from with a
DMARC pass.  Not good.

Using Sender: as the authentication key was suggested and ultimately
abandoned during both DomainKeys (RFC 4870, the predecessor to DKIM) and
Sender-ID (RFC 4406, pretty much never implemented) for this sort of reason.

    > MUAs which are not implementing the rfc822/2822/5322 "on behalf of"
>     > semantics of a message that carries both From: and Sender: header
>     > fields ought to be FIXED.  Standards that build on rfc822/2822/5322
>     > and do not respect "on behalf of" semantics of messages with
>     > both "Sender:" and "From:" also need to be FIXED.

I don't believe that's standardized.  I'm also not sure we (the IETF) want
to enter into user space like MUAs, an area we have historically avoided
because we don't really have such expertise.