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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/