Re: [dmarc-ietf] Sender vs From Addresses

Ken O'Driscoll <ken@wemonitoremail.com> Wed, 24 March 2021 11:54 UTC

Return-Path: <ken@wemonitoremail.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 DE5B83A2B73 for <dmarc@ietfa.amsl.com>; Wed, 24 Mar 2021 04:54:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wemonitoremail.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 QR7vSCEptG43 for <dmarc@ietfa.amsl.com>; Wed, 24 Mar 2021 04:54:52 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150139.outbound.protection.outlook.com [40.107.15.139]) (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 0A6793A2B74 for <dmarc@ietf.org>; Wed, 24 Mar 2021 04:54:51 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RRFponMBPcNs6iguuUQD7vSxlJ51uHxsll8+RoIqOGokIJyIenJ6PUF3pfnliVTPc8j3liPbqqCntISmz/7BG0aa5FozAGvgaHy8vu+U/XUru4ypTa6f/veefG8y6XpNjnR23T12WOUVFCYcQh+Uw9vT2YJN3gzD/XZgLjdwBpZSSP+NquYtgpRwLDVfKlrnfNjQlH04ToDvf9CSxr/aj2IKBO/bJQaGyQisc2IHDyt/nJ+P85Wg8lE0ROJffFr1UYuta5t7xfpGLgE2oD9e7pPsNVpMiGINf1F6u3cEQGeVRuKRGmDA6FJolTvr8L2uXKx1BS+dKSH8yRFVKvvdJQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8AHykka4wydgMQI9PSg9u2VWr3bjVPM1f5BOkpjgXsw=; b=dTqQ0T4PbUSdpbjhEf8U/6zzbG5XkFjxJ09ewmmTRvJPvSP7PjnMJmi06/WkDFcliHO335vsnvhOTdavWr4PFqDVuStjT434znKyHfSHEqRC3bdtQwXEZmEGt99vg6SzoNFj8r9waaN+8eov3wGOJfJB/E18o/T8ZYgHMLbf0U7cRRWP0nOpHZmIrymonGVCkJx8NYlbVaQAmDQdyhfYry2fqwTui90Qo8uofpj5ObdTXQdKSkwwVZ2s6X2zSbJAcBCxAeXajZQtE1Q/muCMKh4KjItDeulKQoT5cSRKy8Af45dMPhOIZ1RlHQX1K2IUuzQJjCfjewIjtpfP0tXipQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wemonitoremail.com; dmarc=pass action=none header.from=wemonitoremail.com; dkim=pass header.d=wemonitoremail.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemonitoremail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8AHykka4wydgMQI9PSg9u2VWr3bjVPM1f5BOkpjgXsw=; b=JsiCp4A/tl53cZ6o8uhDxcQQ+JNJz6z8AxyYkn99q56gEX0DjKu9wYnmKKTss+usiOSoPW/mE83MeGZsJqGJMY9aZsMuImaH8rAQYM5Sqavty5dEg1wLw/DetShXaNa//BN/NtKScQjVmd2sJVf+pxZhxrMzxFT6iHJNU9Uck6lVU7PT5hdbY1NtEVrhPBlsNw3C6PcxfZ6mHfhKDECpc9DfMnnjOt6cxyiEgz3xyFqQbSek+hwWIw+liL33r2noNIz4LOgEstPed/ZDzdgNkTdEuB6H2+N1cFg96Je81njs3r6YsX6rYJ42PUAi+sxzDaNADjQ+66QYfus1ygnNFA==
Received: from VI1PR01MB7053.eurprd01.prod.exchangelabs.com (2603:10a6:800:19a::9) by VI1PR01MB6477.eurprd01.prod.exchangelabs.com (2603:10a6:800:153::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24; Wed, 24 Mar 2021 11:54:49 +0000
Received: from VI1PR01MB7053.eurprd01.prod.exchangelabs.com ([fe80::cc4d:9c81:1286:c67c]) by VI1PR01MB7053.eurprd01.prod.exchangelabs.com ([fe80::cc4d:9c81:1286:c67c%7]) with mapi id 15.20.3977.025; Wed, 24 Mar 2021 11:54:49 +0000
From: Ken O'Driscoll <ken@wemonitoremail.com>
To: Charles Gregory <Charles@possumdelight.com>
CC: IETF DMARC WG <dmarc@ietf.org>
Thread-Topic: Sender vs From Addresses
Thread-Index: AdcgkuKhihmmxnZnSJC0xMH2ibjOrQADKZuQ
Date: Wed, 24 Mar 2021 11:54:49 +0000
Message-ID: <VI1PR01MB7053E1ED6ED09791428D6EE4C7639@VI1PR01MB7053.eurprd01.prod.exchangelabs.com>
References: <6cacad89cb2049858938fce107d60dd9@possumdelight.com>
In-Reply-To: <6cacad89cb2049858938fce107d60dd9@possumdelight.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: possumdelight.com; dkim=none (message not signed) header.d=none;possumdelight.com; dmarc=none action=none header.from=wemonitoremail.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 621f269e-52d2-4a07-570b-08d8eebba08f
x-ms-traffictypediagnostic: VI1PR01MB6477:
x-microsoft-antispam-prvs: <VI1PR01MB6477588C898D8FF76FB4C775C7639@VI1PR01MB6477.eurprd01.prod.exchangelabs.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lujkWeSQ1glGsddGgYq+mYYT0TRYM8CHYYuPUDuKPZSdbfswmtve442nGWUEvXdfv3prBshnCRLlSJMsVYSA+pXm4vGGNF1k5q7qvT2MOg+uJhlOo4pOoURsx8ZQimUqrtEwaEMl9Ae99xLb/U72nBXUxQ4MColRc5eeezBhjRO/YgT2Eg7xqjoFb20gkgHNm4Hf1UD+4Cmk6f+I72hgSfCq5JunD+19o2D7833ZCLtEOD66sFcSeoe0nXc91aZXTaESNS9MTG8V76aGpVTyUBGakf6Wp5Airk5/1Mqzz3I6mXW8N2SHDj08D06StNr11frFPU0GL3238k15CKLlKPFYvQIlQPgMQ0tF2863o2rwuDxesdC7/vC0B23nzKEk4hzBAUWsFFl6pmZo/8nkxGrtNdXBfrU22x1R1lHRI1sMJHwIKp0pjvIqT2Uf6roBLgDmkXTgOY2Qbq5h6V86AKTQGiwm2hhGhBU+gqrhVk/mdzRAXNZVr06O+BmcLiekZsej9X5GjK6jpjYMCiBVVo0BiKB4DDHu8S2mlFEdzuRtmZkIJjcUomVfH6H8w6wi/f9y8mEfXH54PYJWHH+gVtivzGSZEXenvRJAKs73WjqhFyyl7f6GzDRsCpHSs3bA11+/KMGT9HF2+wI1TUuPmDGC2Q94VXuz30PhFaJynnuJDVGgVs34i5XE0jjxod6QRZcBGQrE2iSfliMFUt0VUiMbuMvLkDhY2o3czbK5a3Y=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR01MB7053.eurprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(39830400003)(376002)(396003)(366004)(136003)(346002)(83380400001)(52536014)(86362001)(2906002)(186003)(4326008)(5660300002)(26005)(38100700001)(71200400001)(55016002)(3480700007)(316002)(21615005)(8676002)(6916009)(9686003)(66476007)(166002)(33656002)(66946007)(8936002)(66556008)(64756008)(53546011)(9326002)(66446008)(478600001)(966005)(6506007)(76116006)(7696005); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?us-ascii?Q?zs8TiZoIlOx7cFV97rS3WlmsOMXjrn3NZd5AG8LFMrRKqNr/4aOEvAXR3rKU?= =?us-ascii?Q?R1DifdY5eN7KTX8lM5cMN4tW0Dm4+REG0GenVmlgkekAPBpg4Hdz367fgwp6?= =?us-ascii?Q?n8kdOmRKwY2lUYNxWfKEfmU/StWniAyGFyIiOndG9RHorWA8juAbrl/APrp7?= =?us-ascii?Q?lNb4RqoSQ1d92qaYURKdK5cKkhXYCi4vnDCOl2GMnT9iX0QGJrbTtHyf3VSk?= =?us-ascii?Q?gUzgZjIAKOzDS5m/OtOLsUbcrVEJsiaTy+MwVcq2lKhWCI7Rqeq9gFH8c1DC?= =?us-ascii?Q?EpHvHztgY5pZioFwd+RQgwjjT1OqPfu/2pIThBPOn2z73vKzt6tkX++WyKqG?= =?us-ascii?Q?UzvfQHHGMJxESYUb0LbN2z3zL5Vq+uz2eOYEfF8d8Riq+pQZ4ztJxpLoPhZe?= =?us-ascii?Q?jBJkM/I93cl1gKTOn2gm61okBvi+t70VWZEDm9FpsftEAxvfpoBQ/jt0vMmb?= =?us-ascii?Q?EnfPHOu6WBpDebf/P3wEjkewl3uXMkM+9c+VzrXoMdDRiHhAF35PRMJNNh4z?= =?us-ascii?Q?yFGKmhzq2uLCPovnsrDFgkcMBYDo8sJn9L/1qwKWzM3TkFa5ilJgZ50C6BPF?= =?us-ascii?Q?dE52LGZMHYYMg29Ad7b4spvdwIcOb52YnGW+dzEHOaw9vWnSZCGdBTLRgoBj?= =?us-ascii?Q?jkil+G7WCz4fRWg9CYHvNUlbsu8HkvCvEiwRfStvV7WxhWcpZUIDRMuV0dNA?= =?us-ascii?Q?NkGAWH9Lnb1KTt42b5OvwFEElTMrf3/R4ZJFgay53jcT9M8m5VZdXq4jXxZP?= =?us-ascii?Q?6QG4JJznCRm7NQV3QeFGS/jHPXklx26WH50JGD+CkHMT2/jEijKpnch3jr8X?= =?us-ascii?Q?S9EbuV+mBqTzsGZ44e5ict9I97CugjSHNz8glB0LIsdP5JXmHfBGmmd/9g1c?= =?us-ascii?Q?59S3nAbCiUEFCtFR+sHpa4+/7y5Pe9QM6SebaL/5Gg97yyyI5NJdNxb0UVdd?= =?us-ascii?Q?OD7RNljC20ecsXwNX+AVdp/yta1bCPw7jT0ebyYIobDGKyBa//xLEMrEvfSK?= =?us-ascii?Q?Vdv19ISIDuP0eKHcfXXLQ4ZHi5GQrAbKptehCGUJtll5J+khTNGzFM4RngWG?= =?us-ascii?Q?HdjINb33BCBsxMmnIZVFKfWwIf8/chvhqWKIIvc3MrgSqZbbPNWQ+Ab89ozQ?= =?us-ascii?Q?C6Owyy6GpjUohCvLJ9SgVvVU9MQiNHkBQRQe/XxnRVZRo7/PXFsbrBfmx5UU?= =?us-ascii?Q?xdu+uRo1kb0KFck+AbiDQUKwebRhRl6VE8mXyzaFlkj+RBvwwaQeHoNuGOAb?= =?us-ascii?Q?Vnu5C7+1HHm9GmnX4CksG0sWiwLtq0npnNwEIaq1K5vLfMK8MHdJa+aCufa8?= =?us-ascii?Q?T/g=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_VI1PR01MB7053E1ED6ED09791428D6EE4C7639VI1PR01MB7053eurp_"
MIME-Version: 1.0
X-OriginatorOrg: wemonitoremail.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: VI1PR01MB7053.eurprd01.prod.exchangelabs.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 621f269e-52d2-4a07-570b-08d8eebba08f
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2021 11:54:49.1544 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: a2b1d6fe-fc8b-4b7c-b9f1-d7b1ab3d23b3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: kFk0HTAs+xM9RefXz546/QaQ4EzcdB/xBhGOhm/VdgthQMvGCNxl+hsvj8UJvgqqQDuI3fVV+XrGJ9EGlPwXKw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR01MB6477
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/lXOA8xN7_K-nXX50KNYdNyxFYMo>
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 11:54:58 -0000

Hi Charles,

DMARC is intended to prevent unauthorised use a domain name in the 5322.From header. This header was chosen because it is displayed in MUAs and is the target of spoofing attempts in phishing campaigns. I agree that there is some ambiguity in the original RFC but the intention is clear - DMARC exclusively works on 5322.From by design not oversight.

The interoperability issues between DMARC and mailing lists etc. are well understood and documented (for example, see https://www.rfc-editor.org/rfc/rfc7960.html) and the underlying protocols where the policy get applied, namely SPF and DKIM, already had interoperability issues with intermediaries even before DMARC came along.

There is actually an existing working group draft discussing extending DMARC to incorporate the 5322.Sender header, see https://datatracker.ietf.org/doc/draft-ietf-dmarc-sender/. That document goes into considerable detail on how 5322.Sender could be incorporated in the future.

Ken.

From: dmarc <dmarc-bounces@ietf.org> On Behalf Of Charles Gregory
Sent: Wednesday 24 March 2021 09:49
To: dmarc@ietf.org
Subject: [dmarc-ietf] Sender vs From Addresses

I'm having trouble with DMARC prioritizing the From address over the Sender address.  Couldn't a future version at least allow this behavior to be modified with the DNS entry or something?

I found my issue well articulated in the thread copied below and completely agree with this gentleman.

Thoughts???

Taken from:  email - Why does DMARC operate on the From-address, and not the envelope sender (Return-Path)? - Server Fault<https://serverfault.com/questions/753496/why-does-dmarc-operate-on-the-from-address-and-not-the-envelope-sender-return>
----------------------------------------

1.      Why was DMARC designed that way?
*         because the people who designed it apparently didn't read section 3.6.2 of RFC 5322<https://tools.ietf.org/html/rfc5322#section-3.6.2>.2>, or misinterpreted it, or ignored it.

That section clearly establishes that a Sender: header, when present, takes priority over a From: header, for the purposes of identifying the party responsible for sending a message:

The "Sender:" field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the "Sender:" field and the mailbox of the actual author would appear in the "From:" field. If the originator of the message can be indicated by a single mailbox and the author and transmitter are identical, the "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD appear.

Contrast this with the rationale given in RFC 7489<https://tools.ietf.org/html/rfc7489#section-3.1>.1>:

DMARC authenticates use of the RFC5322.From domain by requiring that it match (be aligned with) an Authenticated Identifier. The RFC5322.From domain was selected as the central identity of the DMARC mechanism because it is a required message header field and therefore guaranteed to be present in compliant messages, and most Mail User Agents (MUAs) represent the RFC5322.From field as the originator of the message and render some or all of this header field's content to end users.

I contend that this logic is flawed, as RFC 5322<https://tools.ietf.org/html/rfc5322#section-3.6.2> goes on to call out this error explicitly:

Note: The transmitter information is always present. The absence of the "Sender:" field is sometimes mistakenly taken to mean that the agent responsible for transmission of the message has not been specified. This absence merely means that the transmitter is identical to the author and is therefore not redundantly placed into the "Sender:" field.

I believe that DMARC is broken by design, because
*         it conflates authority to send and proof of authorship;
*         it misinterprets prior RFCs, and
*         in doing so it breaks any previously compliant list-serv that identified itself by adding its own Sender: header.

If a Sender: field is present, DMARC should say to authenticate that field and ignore the From: field. But that's not what it says, and therefore I consider it to be broken.

RFC 7489<https://tools.ietf.org/html/rfc7489#section-3.1> continues:

Thus, this field is the one used by end users to identify the source of the message and therefore is a prime target for abuse.

This is simply wrong (in the context of justifying ignoring the Sender: header). At the time that DMARC was designed, common email clients would routinely display a combination of the information from Sender: and From: fields, something like From name-for-mailing-list@server on behalf of user@original.domain<mailto:user@original.domain>. So it was always clear to the user who was responsible for sending the message they were looking at.

________________________________

Suggestions that Reply-To: is an adequate replacement are also flawed because that header is widely misinterpreted as "additional recipient" rather than "replacement recipient", and replacing the original sender's Reply-To: would impair the functionality for those users.


Charles A. Gregory