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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 17 April 2014 22:16 UTC

Return-Path: <mcr@sandelman.ca>
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 B39001A0134 for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 15:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.163
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUCiKYYDezPU for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 15:16:39 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA881A0130 for <ietf@ietf.org>; Thu, 17 Apr 2014 15:16:39 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 3ED6520029; Thu, 17 Apr 2014 18:16:59 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id E525063ABD; Thu, 17 Apr 2014 18:16:32 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CEB3B63ABA; Thu, 17 Apr 2014 18:16:32 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: mrex@sap.com
Subject: Re: (DMARC) We've been here before, was Why mailing lists
In-Reply-To: <20140417181815.8A5871ACD1@ld9781.wdf.sap.corp>
References: <20140417181815.8A5871ACD1@ld9781.wdf.sap.corp>
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: <9451.1397772992@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/EGhFVTiN5Lto-Zic4teAMhCQrsc
Cc: Pete Resnick <presnick@qti.qualcomm.com>, John R Levine <johnl@taugh.com>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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 22:16:44 -0000

Martin Rex <mrex@sap.com> 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
     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: Mrex@sap.com via ietf@ietf.org"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  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-