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

mrex@sap.com (Martin Rex) Thu, 17 April 2014 18:18 UTC

Return-Path: <mrex@sap.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3901A01B3 for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 11:18:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAPznAiEG1tq for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 11:18:20 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF421A018D for <ietf@ietf.org>; Thu, 17 Apr 2014 11:18:20 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (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 <johnl@taugh.com>
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: <20140417181815.8A5871ACD1@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/rUcQXlLnwy6A5deHmht7t_-yMF8
Cc: Pete Resnick <presnick@qti.qualcomm.com>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=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.


-Martin