Internet-Draft Author March 2021
Crocker Expires 23 September 2021 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-crocker-email-author-04
Published:
Intended Status:
Experimental
Expires:
Author:
D. Crocker
Brandenburg InternetWorking

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 version is published as an Experiment, to assess community interest, functional efficacy, and technical adequacy.

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 23 September 2021.

Table of Contents

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 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:

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 Experiment, 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]:

RFC EDITOR: Please remove for publication:

3. Author Header Field

A new message header field is defined: Author:. 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 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 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:

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:. 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 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 this 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 demonstration 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

The IANA is request to register the Author header field, per [RFC3864], into the Provisional Message Header Field Names Registry:

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, 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:

8. References

8.1. Normative References

[ABNF]
Dave, D., Ed. and P. Paul, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, , <https://www.rfc-editor.org/rfc/rfc5234>.
[Mail-Arch]
Crocker, D., "Internet Mail Architecture", RFC 5598, , <https://www.rfc-editor.org/rfc/rfc5598>.
[Mail-Fmt]
Resnick, P., Ed., "Internet Message Format", RFC 5322, , <https://www.rfc-editor.org/rfc/rfc5322>.
[RFC3864]
Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, DOI 10.17487/RFC3864, , <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, , <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, , <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, , <https://www.rfc-editor.org/rfc/rfc5703>.
[RFC733]
Crocker, D., Vittal, J., Pogran, K., and D. Henderson, "Standard for the Format of ARPA Network Text Messages", RFC 733, , <https://www.rfc-editor.org/rfc/rfc733>.

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.

Author's Address

Dave Crocker
Brandenburg InternetWorking