IETF Logo Mail Archive

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

mrex@sap.com (Martin Rex) Thu, 17 April 2014 20:23 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 02A251A00FE for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 13:23:09 -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 dJnrRKAUY-gb for <ietf@ietfa.amsl.com>; Thu, 17 Apr 2014 13:23:04 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 585891A0162 for <ietf@ietf.org>; Thu, 17 Apr 2014 13:23:04 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s3HKMx8U023752 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Apr 2014 22:22:59 +0200 (MEST)
Subject: Re: (DMARC) We've been here before, was Why mailing lists
In-Reply-To: <7E18CCC2-AB08-448A-A6B4-940413FF553D@gmail.com>
To: Douglas Otis <doug.mtview@gmail.com>
Date: Thu, 17 Apr 2014 22:22:59 +0200
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: <20140417202259.2AA1D1ACD1@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/ZfUVMuXi8XlmqXJQ2uS6wPjYunc
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
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 20:23:09 -0000

Douglas Otis <doug.mtview@gmail.com> wrote:
> 
> Martin Rex <mrex@sap.com> wrote:
>> 
>> 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.
> 
> Merging Sender and From header fields by MUAs offers no protection
> when actual sources of messages remain unknown.

This is *NOT* about protection or authentication, this is purely about
rfc822/2822/5322 message semantics.  Something that has been well-defined
and constant for decades.

At the beginning of this Email there are two quotations with assertions
of authorship.  There really is no difference to the name in the From:
field of an EMail that is carried with a different Sender (and envelope
MAIL FROM:) through an SMTP transport system.

There is no difference in semantics between the assertions above
and the rfc822-header assertion in "From:", when an rfc822 message
is transferred through an SMTP MTA system in an "on behalf of" scenario
with a differing Envelope "MAIL FROM" & matching Sender: rfc822-header.


-Martin

v2.23.0 | Report a Bug | By Email