Email Author Header FieldBrandenburg InternetWorkingdcrocker@bbiw.net
Applications and Real-Time
domainemailsecuritymessagingdkimspfauthenticationreportingconformanceauthororiginationoriginalfromsenderInternet 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
.
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
() 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
. Introduction
. Terminology
. Author Header Field
. Discussion
. Security Considerations
. IANA Considerations
. Experimental Goals
. References
. Normative References
. Informative References
Acknowledgements
Author's Address
IntroductionInternet 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 . 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 , 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 .TerminologyTerminology and architectural details in this document are
incorporated from .
Normative language, per :
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
when, and only when, they appear in all capitals, as shown here.
Author Header FieldAuthor: is a new message header field being defined. It has the same
syntax as the From: header field . 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 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).
DiscussionThe 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 . It is registered with IANA, which cites
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 . Obviously, any security-related processing of a message needs to
distinguish the From: field from the Author: field and treat their information
accordingly.Security ConsiderationsAny 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.)IANA ConsiderationsIANA has registered the Author: header field, per
, 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
Experimental GoalsGiven 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?
ReferencesNormative ReferencesAugmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Internet Mail ArchitectureOver its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.Internet Message FormatThis document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Registration Procedures for Message Header FieldsThis specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesINTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev1 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev1 also provides the capability for an offline client to resynchronize with the server. IMAP4rev1 includes operations for creating, deleting, and renaming mailboxes, checking for new messages, permanently removing messages, setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching, and selective fetching of message attributes, texts, and portions thereof. Messages in IMAP4rev1 are accessed by the use of numbers. These numbers are either message sequence numbers or unique identifiers. IMAP4rev1 supports a single server. A mechanism for accessing configuration information to support multiple IMAP4rev1 servers is discussed in RFC 2244. IMAP4rev1 does not specify a means of posting mail; this function is handled by a mail transfer protocol such as RFC 2821. [STANDARDS-TRACK]Sieve Email Filtering: MIME Part Tests, Iteration, Extraction, Replacement, and EnclosureThis document defines extensions to the Sieve email filtering language to permit analysis and manipulation of the MIME body parts of an email message. [STANDARDS-TRACK]Standard for the format of ARPA network text messagesAcknowledgementsThe idea for this field was prompted by discussions in the IETF's
DMARC Working Group, with participation from: , ,
, ,
, ,
, ,
, and .Author's AddressBrandenburg InternetWorkingdcrocker@bbiw.net