summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9057.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9057.txt')
-rw-r--r--doc/rfc/rfc9057.txt350
1 files changed, 350 insertions, 0 deletions
diff --git a/doc/rfc/rfc9057.txt b/doc/rfc/rfc9057.txt
new file mode 100644
index 0000000..839a147
--- /dev/null
+++ b/doc/rfc/rfc9057.txt
@@ -0,0 +1,350 @@
+
+
+
+
+Independent Submission D. Crocker
+Request for Comments: 9057 Brandenburg InternetWorking
+Category: Experimental June 2021
+ISSN: 2070-1721
+
+
+ Email Author Header Field
+
+Abstract
+
+ Internet mail defines the From: header field to indicate the author
+ of the message's content and the Sender: field to indicate who
+ initially handled the message on the author's behalf. The Sender:
+ field is optional if it has the same information as the From: field.
+ This was not a problem until development of stringent protections on
+ use of the From: field. It has prompted Mediators, such as mailing
+ lists, to modify the From: field to circumvent mail rejection caused
+ by those protections. In effect, the From: field has become
+ dominated by its role as a handling identifier.
+
+ The current specification augments the altered use of the From: field
+ by specifying the Author: field, which ensures identification of the
+ original author of the message and is not subject to modification by
+ Mediators. This document is published as an Experimental RFC to
+ assess community interest, functional efficacy, and technical
+ adequacy.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for examination, experimental implementation, and
+ evaluation.
+
+ This document defines an Experimental Protocol for the Internet
+ community. This is a contribution to the RFC Series, independently
+ of any other RFC stream. The RFC Editor has chosen to publish this
+ document at its discretion and makes no statement about its value for
+ implementation or deployment. Documents approved for publication by
+ the RFC Editor are not candidates for any level of Internet Standard;
+ see Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc9057.
+
+Copyright Notice
+
+ Copyright (c) 2021 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.
+
+Table of Contents
+
+ 1. Introduction
+ 2. Terminology
+ 3. Author Header Field
+ 4. Discussion
+ 5. Security Considerations
+ 6. IANA Considerations
+ 7. Experimental Goals
+ 8. References
+ 8.1. Normative References
+ 8.2. Informative References
+ Acknowledgements
+ Author's Address
+
+1. Introduction
+
+ Internet mail conducts asynchronous communication from an author to
+ one or more recipients and is used for ongoing dialog 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 content header's From: field to indicate
+ the author of the message and the Sender: field to indicate who
+ initially handled the message on the author's behalf [Mail-Fmt]. The
+ Sender: field is optional if it has the same information as the From:
+ field. That is, when the Sender: field is absent, the 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 Sender: field optional was a small, obvious
+ optimization in the days of slower communications, expensive storage,
+ and less powerful computers.
+
+ The dual semantics were not a problem until development of stringent
+ protections on use of the From: field. It has prompted Mediators,
+ such as mailing lists, to modify the From: field to circumvent
+ receiver mail rejection caused by those protections. This affects
+ end-to-end usability of email between the author and the final
+ recipients, because mail received from the same author is treated
+ differently by the recipient's software, depending on what path the
+ message followed.
+
+ By way of example, mail originating with:
+
+ From: Example User <user@example.com>
+
+ which is sent directly to a recipient, will show the author's display
+ name correctly and can correctly analyze, filter, and aggregate mail
+ from the author based on their email address. However, if the author
+ sends through a mailing list and the mailing list conducts a common
+ form of From: modification needed to bypass enforcement of stringent
+ authentication policies, then the received message might instead have
+ a From: field showing:
+
+ From: Example User via Example List <listname@list.example.org>
+
+ The change inserts an operational address, for the Mediator, into the
+ From: field and distorts the field's display name as a means of
+ recording the modification.
+
+ In terms of email identification semantics, this is a profound
+ change:
+
+ * The result is that the recipient's software will see the message
+ as being from an entirely different author and will handle it
+ separately, such as for sorting or filtering. In effect, the
+ recipient's software will see the same person's email as being
+ from a different address; this includes the person's actual
+ address and each of the mailing lists that person's mail transits.
+
+ * Mediators might create a Reply-To: field with the original From:
+ field email address. This facilitates getting replies back to the
+ original author, but it does nothing to aid other processing or
+ presentation done by the recipient's Mail User Agent (MUA) based
+ on what it believes is the author's address or original display
+ name. This Reply-To action represents another knock-on effect
+ (e.g., collateral damage) by distorting the meaning of that header
+ field, as well as creating an issue if the field already exists.
+
+ In effect, the From: field has become dominated by its role as a
+ handling identifier. The current specification augments this altered
+ use of the From: field by specifying the Author: field, which
+ identifies the original author of the message and is not subject to
+ modification by Mediators.
+
+ While it might be cleanest to move towards more reliable use of the
+ Sender: field and then to target it as the focus of authentication
+ concerns, enhancement of existing standards works best with
+ incremental additions, rather than with efforts at replacement. To
+ that end, this specification provides a means of supplying author
+ information that is not subject to modification by processes seeking
+ to enforce stringent authentication.
+
+ This version is published as an Experimental RFC to assess community
+ interest, functional efficacy, and technical adequacy. See
+ Section 7.
+
+2. Terminology
+
+ Terminology and architectural details in this document are
+ incorporated from [Mail-Arch].
+
+ Normative language, per [RFC8174]:
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+3. Author Header Field
+
+ Author: is a new message header field being defined. It has the same
+ syntax as the From: header field [Mail-Fmt]. As with the original
+ and primary intent for the From: field, the Author: field is intended
+ to contain the email address of the author of the message content.
+ It also can contain the displayable human name of the author.
+
+ The [ABNF] for the field's syntax is:
+
+ author = "Author:" mailbox-list CRLF
+
+ which echos the syntax for the From: header field.
+
+ This header field can be added as part of the original message
+ creation process, or it can be added later, by a Mediator, to
+ preserve the original author information from the From: field.
+
+ The goal of the Author: field is to reflect information about the
+ original author. However, it is possible that the author's MUA or
+ Mail Submission Agent (MSA) will not create it but that a Mediator
+ might know it will be modifying the From: field and wish to preserve
+ the author information. Hence, it needs to be allowed to create the
+ Author: field for this if the field does not already exist.
+
+ Processing of the Author: field follows these rules:
+
+ * If an Author: field already exists, a new one MUST NOT be created,
+ and the existing one MUST NOT be modified.
+
+ * An author's MUA or MSA MAY create an Author: field, and its value
+ MUST be identical to the value in the From: field.
+
+ * A Mediator MAY create an Author: field if one does not already
+ exist, and this new field's value MUST be identical to the value
+ of the From: field at the time the Mediator received the message
+ (and before the Mediator causes any changes to the From: field).
+
+4. Discussion
+
+ The Author: header field, here, is intended for creation during
+ message generation or during mediation. It is intended for use by
+ recipient MUAs, as they typically use the From: field. In that
+ regard, it would be reasonable for an MUA that would normally
+ organize, filter, or display information based on the From: field to
+ give the Author: header field preference.
+
+ Original-From: is a similar header field referenced in [RFC5703]. It
+ is registered with IANA, which cites [RFC5703] as the controlling
+ source for the entry. However, that document only has a minimal
+ definition for the field. Also, the field is solely intended for use
+ by Mediators to preserve information from a modified From: field.
+ The current specification can be used during either origination or
+ mediation.
+
+ While the basic model of email header fields is highly extensible,
+ there well might be implementation and usability considerations for
+ carrying this field through to end users, such as via [IMAP].
+
+ Obviously, any security-related processing of a message needs to
+ distinguish the From: field from the Author: field and treat their
+ information accordingly.
+
+5. Security Considerations
+
+ Any header field containing identification information is a source of
+ security and privacy concerns, especially when the information
+ pertains to content authorship. Generally, the handling of the
+ Author: header field needs to receive scrutiny and care, comparable
+ to that given to the From: header field, but preferably not in a way
+ that defeats its utility.
+
+ Given the semantics of the Author: header field, it is easy to
+ believe that use of this field will create a new attack vector for
+ tricking end users. However (and perhaps surprisingly), for all of
+ the real and serious demonstrations of users being tricked by
+ deceptive or false content in a message, there is no evidence that
+ problematic content in a header field, which is providing information
+ about message's author, directly contributes to differential and
+ problematic behavior by the end user. (The presents an obvious
+ exercise for the reader to find credible, documented evidence.)
+
+6. IANA Considerations
+
+ IANA has registered the Author: header field, per [RFC3864], in the
+ "Provisional Message Header Field Names" registry:
+
+ Header field name: Author
+ Applicable protocol: mail
+ Status: Provisional
+ Author/Change controller: Dave Crocker <dcrocker@bbiw.net>
+ Specification document(s): RFC 9057
+
+7. Experimental Goals
+
+ Given that the semantics of this field echo the long-standing From:
+ header field, the basic mechanics of the field's creation and use are
+ well understood. Points of concern, therefore, are with possible
+ interactions with the existing From: field, anti-abuse systems, and
+ MUA behavior, along with basic market acceptance. So the questions
+ to answer while the header field has experimental status are:
+
+ * Is there demonstrated interest by MUA developers?
+
+ * If MUA developers add this capability, is it used by authors?
+
+ * Does the presence of the Author: field, in combination with the
+ From: field, create any operational problems, especially for
+ recipients?
+
+ * Does the presence of the Author: field demonstrate additional
+ security issues?
+
+ * Does the presence of the Author: field engender problematic
+ behavior by anti-abuse software, such as defeating its utility?
+
+8. References
+
+8.1. Normative References
+
+ [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234,
+ DOI 10.17487/RFC5234, January 2008,
+ <https://www.rfc-editor.org/info/rfc5234>.
+
+ [Mail-Arch]
+ Crocker, D., "Internet Mail Architecture", RFC 5598,
+ DOI 10.17487/RFC5598, July 2009,
+ <https://www.rfc-editor.org/info/rfc5598>.
+
+ [Mail-Fmt] Resnick, P., Ed., "Internet Message Format", RFC 5322,
+ DOI 10.17487/RFC5322, October 2008,
+ <https://www.rfc-editor.org/info/rfc5322>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
+ Procedures for Message Header Fields", BCP 90, RFC 3864,
+ DOI 10.17487/RFC3864, September 2004,
+ <https://www.rfc-editor.org/info/rfc3864>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+8.2. Informative References
+
+ [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+ 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
+ <https://www.rfc-editor.org/info/rfc3501>.
+
+ [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part
+ Tests, Iteration, Extraction, Replacement, and Enclosure",
+ RFC 5703, DOI 10.17487/RFC5703, October 2009,
+ <https://www.rfc-editor.org/info/rfc5703>.
+
+ [RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
+ "Standard for the format of ARPA network text messages",
+ RFC 733, DOI 10.17487/RFC0733, November 1977,
+ <https://www.rfc-editor.org/info/rfc733>.
+
+Acknowledgements
+
+ The idea for this field was prompted by discussions in the IETF's
+ DMARC Working Group, with participation from: Benny Lyne Amorsen,
+ Kurt Anderson, Laura Atkins, Adrian Farrel, Murray S. Kucherawy, Mike
+ Hammer, John Levine, Alexey Melnikov, Jesse Thompson, and Alessandro
+ Vesely.
+
+Author's Address
+
+ Dave Crocker
+ Brandenburg InternetWorking
+
+ Email: dcrocker@bbiw.net