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

Michael Richardson <> Thu, 17 April 2014 22:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B39001A0134 for <>; Thu, 17 Apr 2014 15:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.163
X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TUCiKYYDezPU for <>; Thu, 17 Apr 2014 15:16:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0DA881A0130 for <>; Thu, 17 Apr 2014 15:16:39 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 3ED6520029; Thu, 17 Apr 2014 18:16:59 -0400 (EDT)
Received: by (Postfix, from userid 179) id E525063ABD; Thu, 17 Apr 2014 18:16:32 -0400 (EDT)
Received: from (localhost []) by (Postfix) with ESMTP id CEB3B63ABA; Thu, 17 Apr 2014 18:16:32 -0400 (EDT)
From: Michael Richardson <>
Subject: Re: (DMARC) We've been here before, was Why mailing lists
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Thu, 17 Apr 2014 18:16:32 -0400
Message-ID: <>
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: Thu, 17 Apr 2014 22:16:44 -0000

Martin Rex <> wrote:
    >> Every attempt to create a signing scheme that is flexible enough to deal
    >> with all the routine stuff that lists do (e.g., reorder, discard, or
    >> flatten MIME parts while adding the usual subject tags and body footers)
    >> while being robust enough to prevent bad guys from replacing the message
    >> with spam has completely failed.  We can try again, but I don't see any
    >> reason to think that the result would be any different.

    > I fail to understand where the problem comes from.  The idea/architecture
    > of the rfc822 "sent on behalf of" (Sender:) seems clear.  If anything
    > should be authenticated at all, then it is what _the_sender_ decides
    > to send.

    > The sender might be asserting the authorship of the message (plus or
    > minus a few bits) to someone else by including the authors name in
    > a From: field that differs from the Sender: field.

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

    > A technology that is obsessed about the contents of the From:-Field
    > of an rfc822/2822/5322 Email message that ignores the semantics of
    > the Sender: field appears broken to me.  A sender that received
    > the original EMail with a signature might indicate so (and authenticate
    > this indication), but unless the original message is included verbatim
    > an opaque blob, the original signature may no longer work -- such as
    > when a mailing list software cleans/streamlines submissions, so the
    > original signature should be stripped.

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

Is "on behalf of" part of the specification...  not literally using those
words, which is a shame, because I think that it's really good wording.
section 3.3.6 says:

   The resent originator fields indicate the mailbox of the person(s) or
   system(s) that resent the message.  As with the regular originator
   fields, there are two forms: a simple "Resent-From:" form, which
   contains the mailbox of the individual doing the resending, and the
   more complex form, when one individual (identified in the "Resent-
   Sender:" field) resends a message on behalf of one or more others
   (identified in the "Resent-From:" field).

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-