Network Working Group D. Crocker
Internet-Draft Brandenburg InternetWorking
Intended status: Experimental March 9, 2021
Expires: September 10, 2021
Email Author Header Field
draft-crocker-email-author-02
Abstract
Internet mail defines the From: 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.
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 September 10, 2021.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Crocker Expires September 10, 2021 [Page 1]
Internet-Draft Author March 2021
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Author Header Field . . . . . . . . . . . . . . . . . . . . . 4
4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Experimental Goals . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
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 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 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
receiver mail rejection, caused by those protections. This affects
Crocker Expires September 10, 2021 [Page 2]
Internet-Draft Author March 2021
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 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 have a From:
field along the lines of:
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:
o 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, for the person's actual address and each
of the mailing lists that person's mail transits.
o 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 done
by the recipient's MUA based on what it believes is the author's
address or original display-name. This Reply-To action represents
another knock-on collateral damage, by distorting the meaning of
the field, as well as creating an issue if the field already
existed.
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.
Crocker Expires September 10, 2021 [Page 3]
Internet-Draft Author March 2021
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 standards works best with incremental
additions, rather than 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.
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.
RFC EDITOR: Please remove for publication:
Discussion of this draft is directed to the ietf-822@ietf.org
mailing list.
3. Author Header Field
A new message header field is defined: Author:. It has the same
syntax as From: [Mail-Fmt]. As with the original and primary intent
for the From: header field, the Author: header field is 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: 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 MSA
will not create it, but that a Mediator might know that it will be
modifying the From: field and wish to preserve author information.
Crocker Expires September 10, 2021 [Page 4]
Internet-Draft Author March 2021
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:
o If an Author: field already exists, a new one MUST NOT be created
o An author's MUA or MSA MAY create an Author: field, and its value
MUST be identical to the value in the From: field
o A Mediator MAY create an Author: field, if an 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. Lastly, the field is solely intended for
use by Mediators, to preserve information from a modified From:. The
current specification can be used either during origination or during
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 From: from Author: and treat their information
accordingly.
5. Security Considerations
Any header field containing identification information is a source of
security and privacy concerns, especially one pertaining 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.
Crocker Expires September 10, 2021 [Page 5]
Internet-Draft Author March 2021
Given the semantics of this field, it is easy to believe that use of
this field will create a new attack vector for tricking end-users.
However, for all of the real and serious demonstration of users'
being tricked by deceptive or false content in a message, there is no
evidence that problematic content in a field providing information
about message's author directly contributes to differential and
problematic behavior by the end user.
6. IANA Considerations
The IANA is request to register the Author header field, per
[RFC3864]
Header field name: Author
Applicable protocol: mail
Status: Experimental
Author/Change controller: Dave Crocker <dcrocker@bbiw.net>
Specification document(s): *** This document ***
7. Experimental Goals
Given that the semantics of this field echo the long-standing From:
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, with anti-abuse systems,
and with MUA behavior, along with basic market acceptance. So the
questions to answer, while the header field has experimental status
are:
o Is there demonstrated interest by MUA developers?
o 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
recipients?
o Does the presence of the Author field demonstrate additional
security issues?
o Does the presence of the Author field engender problematic
behavior by anti-abuse software, such as defeating its utility?
Crocker Expires September 10, 2021 [Page 6]
Internet-Draft Author March 2021
8. References
8.1. Normative References
[ABNF] Dave, D., Ed. and P. Paul, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[Mail-Arch]
Crocker, D., "Internet Mail Architecture", RFC 5598, July
2009.
[Mail-Fmt]
Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[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, October 2009.
[RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson,
"Standard for the Format of ARPA Network Text Messages",
RFC 733, November 1977.
Appendix A. Acknowledgements
The idea for this field was prompted by discussions in the IETF's
DMARC working group, with participation including: Benny Lyne
Amorsen, Kurt Anderson, Laura Atkins, Adrian Farrel, Murray S.
Kucherawy, Mike Hammer, John Levine, Alexey Melnikov, Jesse Thompson,
Alessandro Vesely.
Crocker Expires September 10, 2021 [Page 7]
Internet-Draft Author March 2021
Author's Address
Dave Crocker
Brandenburg InternetWorking
Email: dcrocker@bbiw.net
Crocker Expires September 10, 2021 [Page 8]