Internet DRAFT - draft-ietf-dmarc-sender
draft-ietf-dmarc-sender
DMARC D. Crocker
Internet-Draft Brandenburg InternetWorking
Updates: 7489 (if approved) September 25, 2020
Intended status: Experimental
Expires: March 29, 2021
DMARC Use of the RFC5322.Sender Header Field
draft-ietf-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 also 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."
Crocker Expires March 29, 2021 [Page 1]
Internet-Draft DMARC September 2020
This Internet-Draft will expire on March 29, 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
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . 5
4. Mail Originator Actions . . . . . . . . . . . . . . . . . . . 6
5. Mail Mediator Actions . . . . . . . . . . . . . . . . . . . . 6
6. Mail Receiver Actions . . . . . . . . . . . . . . . . . . . . 6
6.1. Extract RFC5322.Sender and RFC5322.From Domains . . . . . 6
6.2. Determine Handling Policy . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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
Crocker Expires March 29, 2021 [Page 2]
Internet-Draft DMARC September 2020
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 that
the message will be rejected or quarantined by the receiving system.
However, if the mailing list does modify the RFC5322.From field, mail
received from the same author will be treated differently by the
recipient's software, depending on what path the message followed.
By way of example, mail by:
Author Name <user@example.com>
which is sent directly to a recipient, will show the user's display
name correctly and can correctly analyze and aggregate mail from that
user, based on their email address. However if the user sends
through a mailing list, and the mailing list conducts a common form
of RFC5322.From modification, needed to bypass enforcement of
stringent authentication policies, then the received message might
have a RFC5322.From field along the lines of
Author Name via Listname <listname@list.example.com>
The change inserts an operational address, for the Mediator, into the
RFC5322.From field, and distorts the field's display-name, as a means
of recording the modification. The result is that the recipient's
software will see the message as being from an entirely different
author and will handle it separately. Mediators might create a
Reply-To: field, with the original RFC5322.From field email address.
While this facilitates a recipient's responding to the original
author, it does nothing to aid other processing done by the
recipient's MUA based on what it believes is the author's address or
original display-name.
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.
Crocker Expires March 29, 2021 [Page 3]
Internet-Draft DMARC September 2020
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]. 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.
COMMENT: The original version of this specification essentially
sought to have the Sender: header field treated as an alternative
to the From: header field. Unfortunately this suffers a fatal
problem, in the face of established DMARC use.
If:
* the original From: field is covered by DMARC, and
* the message goes through a Mediator that breaks aligned
authentication, and
* the receiving DMARC engine only uses the original version of
DMARC,
then it will produce a DMARC fail.
It does not appear to be possible to handle this case safely,
except by modifying the From: header field so that it does not
trigger an alignment failure. Unless there comes a time at which
concern for this case is eliminated, Mediators will continue to
have to deal with this, such as by modifying the From: field.
To that end, this version of the specification has been modified,
to make Sender: an _additional_ DMARC alignment possibility,
rather than an alternative one.
Crocker Expires March 29, 2021 [Page 4]
Internet-Draft DMARC September 2020
2. Overview
This specification defines modifications to DMARC, to add use of the
RFC5322.Sender header field, as a possible second source of DMARC
validation and policy information. The changes are:
o 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.
o The message originator creates a RFC5322.Sender field that is
identical to the RFC5322.From field, and therefore provides DMARC
alignment. This can permit DMARC to validate, even when it fails
to validate, based on the From: field.
o 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.
* DMARC evaluation is also performed, as 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:
+-------------------------------+--------------+----------------+
| \Originate/ || - Receive --> | Original | Enhanced |
+-------------------------------+--------------+----------------+
| RFC5322.From | RFC5322.From | RFC5322.From |
| RFC5322.From + RFC5322.Sender | RFC5322.From | RFC5322.Sender |
+-------------------------------+--------------+----------------+
DMARC Original/Enhanced Interactions
3. Domain Owner Actions
For a domain that supports the use of RFC5322.Sender field evaluation
for DMARC, the owner specifies an additional DMARC Policy Record tag:
snd: When present, this tag signals that mail originated by the
domain owner MAY have a RFC5322.Sender field, as well as a
RFC5322.From field and that evaluation MAY be based on the domain
name in the RFC5322.Sender field.
Crocker Expires March 29, 2021 [Page 5]
Internet-Draft DMARC September 2020
4. Mail Originator Actions
Mail originators, for domains supporting enhanced DMARC, can create a
RFC5322.Sender field that is a duplicate of the RFC5322.From field.
They can, instead, create one that has a separate address, such as
when the originator is an independent agent, acting on behalf of the
content creator.
5. Mail Mediator Actions
Mediators, such as mailings lists, are independent agents, acting on
behalf of authors and recipients. They take delivery of messages and
then repost them, typically with modification. In response to the
use of DMARC, they often modify the RFC 5332.From field. They can
use this Sender-based mechanism to generate their own DMARC-aligned
authentication, based on the RFC5322.Sender field.
6. Mail Receiver Actions
6.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.
6.2. Determine Handling Policy
The following procedure can result in DMARC policy information based
on the rfc5322.From, or the rfc5322.Sender, or based on both header
fields. The final choice for using this information to determine
message disposition resides with the receiving system.
To arrive at a policy for an individual message, Mail Receivers MUST
perform the following actions or their semantic equivalents. Steps
2-3 MAY be done in parallel, whereas steps 4 and 5 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.
Perform remaining, numbered steps, if one is found and it
contains an "snd" tag.
Crocker Expires March 29, 2021 [Page 6]
Internet-Draft DMARC September 2020
AND
From: Extract the RFC5322.From domain from the message.
Query the DNS for a DMARC policy record
Perform remaining, numbered steps, if one is found.
Terminate: 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. If one or more
of the Authenticated Identifiers align with the RFC5322.From (or
with the RFC5322.Sender field, if permitted by the domain owner)
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 MAY be
disposed of in accordance with the discovered DMARC policy of the
Domain Owner. Broadly, however, receivers typically do not
automatically follow such directives. Rather, they apply complex
evaluation rules, for which DMARC is merely one (or more) sets of
input data. To that end, having a DMARC assessment for the
RFC5322.From field and another for the RFC5322.Sender field
merely add to their pool of data to consider.
7. Security Considerations
This enhancement entails the same security issues as the basic DMARC
service.
8. IANA Considerations
None.
Crocker Expires March 29, 2021 [Page 7]
Internet-Draft DMARC September 2020
9. References
9.1. Normative References
[DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, March 2015.
[Mail-Arch]
Crocker, D., "Internet Mail Architecture", RFC 5598, July
2009.
[Mail-Fmt]
Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
9.2. Informative References
[RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
"Standard for the Format of ARPA Network Text Messages",
RFC 733, November 1977.
Author's Address
Dave Crocker
Brandenburg InternetWorking
Email: dcrocker@bbiw.net
Crocker Expires March 29, 2021 [Page 8]
