Re: (DMARC) We've been here before, was Why mailing lists (Martin Rex) Thu, 17 April 2014 18:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2F3901A01B3 for <>; Thu, 17 Apr 2014 11:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gAPznAiEG1tq for <>; Thu, 17 Apr 2014 11:18:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6BF421A018D for <>; Thu, 17 Apr 2014 11:18:20 -0700 (PDT)
Received: from by (26) with ESMTP id s3HIIFFQ003939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Apr 2014 20:18:15 +0200 (MEST)
Subject: Re: (DMARC) We've been here before, was Why mailing lists
In-Reply-To: <alpine.BSF.2.00.1404162346400.2194@joyce.lan>
To: John R Levine <>
Date: Thu, 17 Apr 2014 20:18:15 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: Pete Resnick <>, "" <>
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 18:18:23 -0000

John R Levine wrote:
> > The originator (well, more to the point, the originator's mail server) 
> > doesn't need a signal that it's a mailing list; it's simply that the 
> > destination makes an "if I forward the mail, I'll be including this" piece of 
> > data available, and the originator's server can then include that in the 
> > signature of the message. I was thinking this could be in some special kind 
> > of DMARC (or whatever) record that lived in the mailing list's domain and 
> > could be queried by the originator's server.
> We argued at great length about this issue when we were doing DKIM.  The 
> magic token has to be cryptographically tied to the contents of the 
> original message, or bad guys can take the token from a real message and 
> replace the body with spam.  So that means a token tied to a hash of the 
> contents of the message which is, of course, a DKIM signature.  This 
> scheme is equivalent to requiring that lists preserve DKIM signatures, 
> which they don't.
> 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.

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.