Re: [dmarc-ietf] Sender vs From Addresses

Gren Elliot <gelliot@mimecast.com> Wed, 24 March 2021 18:41 UTC

Return-Path: <gelliot@mimecast.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7E23A32FB for <dmarc@ietfa.amsl.com>; Wed, 24 Mar 2021 11:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mimecast.com
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 HXhv4JwLJXWJ for <dmarc@ietfa.amsl.com>; Wed, 24 Mar 2021 11:41:28 -0700 (PDT)
Received: from eu-smtp-1.mimecast.com (service-alpha-outbound1.mimecast.com [195.130.217.223]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B8EA3A32F5 for <dmarc@ietf.org>; Wed, 24 Mar 2021 11:41:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mimecast.com; s=20130419; t=1616611284; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=u8xAQI3LFM8a2hWN2O3MHpKZZa5CWAPUuy/ucAoXucE=; b=USQRJHrEMTXGealUHic6CRJ1OnLx1id/msgKbNngmKGkNZcdGMJKv1SYQHYM4fG0BjITvn i3isYq/o0WC8TEJ/uiKaX0tlkeqIuacJgy/1AO5+PqgJfOp+Gmsmq76A7d+G2Dhxribwc6 GibSCh3E/W231aDT1BiU09Uqly/cpqk=
Received: from mail.mimecast.com (45.91.17.200 [45.91.17.200]) (Using TLS) by relay.mimecast.com with ESMTP id uk-sl-a-vzE2dvi5NnioVkzSXZNWcA-1; Wed, 24 Mar 2021 18:41:22 +0000
X-MC-Unique: vzE2dvi5NnioVkzSXZNWcA-1
Received: from LHC-IT-EML-P01.mcsltd.internal (172.17.26.211) by LHC-IT-EML-P02.mcsltd.internal (172.17.26.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Wed, 24 Mar 2021 18:41:21 +0000
Received: from LHC-IT-EML-P01.mcsltd.internal ([fe80::581:e1a7:4c7b:bd43]) by LHC-IT-EML-P01.mcsltd.internal ([fe80::581:e1a7:4c7b:bd43%4]) with mapi id 15.01.2176.009; Wed, 24 Mar 2021 18:41:21 +0000
From: Gren Elliot <gelliot@mimecast.com>
To: "dmarc@ietf.org" <dmarc@ietf.org>
Thread-Topic: Sender vs From Addresses
Thread-Index: AQHXIN1IKd8+9xh5sUaPOccbp7m+Sg==
Date: Wed, 24 Mar 2021 18:41:20 +0000
Message-ID: <F1E2D8D7-9978-4C4B-9FD7-AB6428D12789@contoso.com>
Accept-Language: en-GB, en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.16.26.8]
MIME-Version: 1.0
Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C1A1 smtp.mailfrom=gelliot@mimecast.com
X-Mimecast-Spam-Score: 1
X-Mimecast-Originator: mimecast.com
Content-Language: en-GB
Content-Type: multipart/alternative; boundary="_000_F1E2D8D799784C4B9FD7AB6428D12789contosocom_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/Q7YJ-KeIHEySwypcJ4lqVQnOCKg>
Subject: Re: [dmarc-ietf] Sender vs From Addresses
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Mar 2021 18:41:33 -0000

Hi,

For better or worse, there is long established practice in the Calendaring community when implementing iMIP (rfc6047) when an assistant is working on behalf of a manager for the manager’s email address to populate the “From:” header and the assistant’s email address to populate the “Sender:” header.  Mailing software seems to go to lengths to follow this convention even when it doesn’t do so for other email messages “sent on behalf of”.  I assume this means that things will break somewhere if this convention isn’t followed for at least some peoples calendaring software.

So, it looks like at the moment people will need to make a choice between enforcing DMARC and having calendaring software continue to function.

Surely it is possible to offer different levels of DMARC enforcement where there is a level that forces using the “From:” header and a newer level which follows the existing email standards for validating who the author is – i.e. use “Sender:” if present, else use “From:”?

Alternatively, we really ought to update the Email RFCs to deprecate the “Sender:” header.  Otherwise you effectively have canonical standards from the same standards body which flatly contradict each other.

Software and standards layered on top of email like iMIP would also need similar updates.  .  I’m not actually recommending this – whilst we might design things differently now, the existing practice with “From:” and “Sender:” makes sense to me and the level of complexity with dealing with this seems trivial compared to other things we need to deal with.

Regards,
Gren