DMARC Use of the RFC5322.Sender Header Field
draft-crocker-dmarc-sender-00

Abstract

Internet mail defines the RFC5322.From field to indicate the author of the message's content and the RFC5322.Sender field to indicate who initially handled the message. The RFC5322.Sender field is optional, if it has the same information as the RFC5322.From field. That is, when the RFC5322.Sender field is absent, the RFC5322.From field has conflated semantics, with both a handling identifier and a content creator identifier. This was not a problem, until development of stringent protections on use of the RFC5322.From field. It has prompted Mediators, such as mailing lists, to modify the RFC5322.From field, to circumvent mail rejection caused by those protections.

This affects end-to-end behavior of email, between the author and the final recipients, because mail from the same author is not treated the same, depending on what path it followed. In effect, the RFC5322.From field has become dominated by its role as a handling identifier.

The current specification augments use of the RFC5322.From field, by enhancing DMARC to use the RFC5322.Sender field. This preserves the utility of RFC5322.From field while also preserving the utility of DMARC.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 13, 2021.

Copyright Notice

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Overview
• 3. Domain Owner Actions
• 4. Mail Originator Actions
• 5. Mail Receiver Actions
• 5.1. Extract RFC5322.Sender and RFC5322.From Domains
• 5.2. Determine Handling Policy
• 6. Security Considerations
• 7. IANA Considerations
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Author's Address

1. Introduction

Internet mail conducts asynchronous communication from an author to one or more recipients, and is used for ongoing dialogue amongst them. Email has a long history of serving a wide range of human uses and styles, within that simple framework, and the mechanisms for making email robust and safe serve that sole purpose.

Internet mail defines the RFC5322.From field to indicate the author of the message's content and the RFC5322.Sender field to indicate who initially handled the message. [Mail-Fmt] The RFC5322.Sender field is optional, if it has the same information as the RFC5322.From field. That is, when the RFC5322.Sender field is absent, the RFC5322.From field has conflated semantics, as both a handling identifier and a content creator identifier. These fields were initially defined in [RFC733] and making the redundant RFC5322.Sender field optional was a small, obvious optimization, in the days of slower communications, expensive storage and less powerful computers.

The dual semantics of the RFC5322.From field was not a problem, until development of stringent protections were put in place, on the use of the RFC5322.From field. It has prompted Mediators, such as mailing lists, to modify the RFC5322.From field, to circumvent mail rejection caused by those protections. This affects end-to-end usability of email, between the author and the final recipients. If the mailing list does not modify the RFC5322.From field, there is the risk of the message being rejected or quarantined by the receiving system. If the mailing list does modify the RFC5322.From field, mail received from the same author is treated differently by the recipient's software, depending on what path the message followed.

Author Name <user@example.com>

Author Name via Listname <listname@list.example.com>

By way of example, mail by:

Because the current email protection behavior involves the RFC5322.From field, and pertain to the human author, it is common to think that the issue, in protecting the field's content, is behavior of the human recipient. However there is no indication that the enforced values in the RFC5322.From field alter end-user behavior. In fact there is a long train of indication that it does not. Rather, the meaningful protections actually operate at the level of the receiving system's mail filtering engine, which decides on the dispostion of received mail.

In effect, the RFC5322.From field has become dominated by its role as a handling identifier. This specification defines enhancement for use of the RFC5322.Sender field by DMARC. [DMARC] It is designed with the view that enhancement of standards works best as incremental additions. DMARC functionality is preserved, as is long-standing recipient email usability..

Teminology and architectural details in this document are incorporated from [Mail-Arch].

Discussion of this draft is directed to the dmarc@ietf.org mailing list.

2. Overview

This specification defines modifications to DMARC, to add use of the RFC5322.Sender header field, taking precedence over use of the RFC5322.From field. The changes are:

• A tag is added to the DMARC DNS record, to flag support for this enhancement, indicating that valid mail originating from this domain will have an aligned RFC5322.Sender field.
• The message originator creates a RFC5322.Sender field that is identical to the RFC5322.From field, and therefore provide DMARC alignment. This ensures that DMARC will continue to validate as it would without this enhancement.
• Receiving systems supporting the enhancement check for the RFC5322.Sender domain's DNS DMARC record.
  • If there is a record and it contains the enhancement flag, DMARC evaluation is performed on that domain name.
  • If there is no record or the record does not contain the enhancement flag, then DMARC evaluation proceeds is before, using the RFC5322.From domain name.

The enhancement preserves existing DMARC operation, but permits DMARC success in some scenarios that either used to fail or that produce Mediator actions to bypass DMARC. The following table shows DMARC interactions between original vs. enhanced originators and receivers:

3. Domain Owner Actions

For a domain that supports the use of RFC5322.Sender field evaluation for DMARC, the woner specifies an additional DMARC Policy Record tag:

snd:

When present, this tag signals that mail originated by the domain owner MUST have a RFC5322.Sender field, as well as a RFC5322.From field and that evaluation SHOULD be based on the domain name in the RFC5322.Sender field.

4. Mail Originator Actions

Mail originators, for domains supporting enhanced DMARC, create a RFC5322.Sender field that is a duplicate of the RFC5322.From field.

5. Mail Receiver Actions

5.1. Extract RFC5322.Sender and RFC5322.From Domains

The domain in the RFC5322.Sender field and the domain in the RFC5322.From field are extracted as the domains to be evaluated by DMARC.

5.2. Determine Handling Policy

To arrive at a policy for an individual message, Mail Receivers MUST perform the following actions or their semantic equivalents. Steps 2-4 MAY be done in parallel, whereas steps 5 and 6 require input from previous steps.

The steps are as follows:

1. Sender:

   Extract the RFC5322.Sender domain from the message.

   Query the DNS for a DMARC policy record.

   Continue if one is found and it contains an "snd" tag;.

   From:

   Otherwise extract the RFC5322.From domain from the message.

   Query the DNS for a DMARC policy record

   Continue if one is found.

   Fail:

   Otherwise terminate DMARC evaluation.

2. Perform DKIM signature verification checks. A single email could contain multiple DKIM signatures. The results of this step are passed to the remainder of the algorithm and MUST include the value of the "d=" tag from each checked DKIM signature.
3. Perform SPF validation checks. The results of this step are passed to the remainder of the algorithm and MUST include the domain name used to complete the SPF check.
4. Conduct Identifier Alignment checks. With authentication checks and policy discovery performed, the Mail Receiver checks to see if Authenticated Identifiers fall into alignment as described in Section 3. If one or more of the Authenticated Identifiers align with the RFC5322.From domain, the message is considered to pass the DMARC mechanism check. All other conditions (authentication failures, identifier mismatches) are considered to be DMARC mechanism check failures.
5. Apply policy. Emails that fail the DMARC mechanism check are disposed of in accordance with the discovered DMARC policy of the Domain Owner. See Section 6.3 for details.

6. Security Considerations

This enhancement entails the same security issues as the basic DMARC service.

7. IANA Considerations

None.

8. References

8.1. Normative References

8.2. Informative References

Author's Address