RFC 9057

Email Author Header Field

📅 published June 2021, from ietf

RFC 9057: Email Author Header Field 🎀

Okay so bestie, this one is an Experimental RFC 💅 (so not a Standards Track thing, it's a "let's see if people actually want this" kind of vibe ✨). It was written by D. Crocker from Brandenburg InternetWorking and published in June 2021 🌸. It's an Independent Submission, which means it came in outside the usual IETF stream, and the ISSN is 2070-1721 (that's the RFC series number, not something to stress about 🧚). It doesn't obsolete anything and doesn't update anything either, so it's a fresh little contribution 🍓.

Abstract ✨

So here's the tea ☕. Internet mail has the From: header field, which tells you who wrote the message, and the Sender: field, which tells you who handled it for the author. Sender: is optional when it would just repeat From: 🙈. That was totally fine until people got really strict about protecting the From: field. Now mailing lists (the "Mediators") edit From: so their mail doesn't get rejected 😭, and From: ends up being more about who handled the message than who wrote it. Iconic glow-up, but make it chaotic 💀.

This doc proposes a new Author: header field that keeps the original author's identity intact, and Mediators aren't allowed to mess with it 🔥. It's published as Experimental so people can check if it's actually useful, works in practice, and is technically solid 🦋.

1. Introduction 🌈

Okay so email is basically async messaging from an author to one or more recipients, and people use it to chat back and forth for all sorts of reasons 💖. The safety mechanisms exist to support that simple job, and that's the whole point ✨.

The From: field says who wrote the message, and Sender: says who handled it for them [Mail-Fmt]. Sender: can be left out when it matches From:, so From: ends up doing double duty as both "handler" and "creator" 👑. Those fields came from [RFC733], and skipping the redundant Sender: was a little optimization back when storage was pricey and computers were slow 🧚.

Here's where it went sideways 😭. Strict protections on From: came along, and Mediators like mailing lists started rewriting From: just so their messages wouldn't bounce ✨. That means the same person's mail can look totally different to the recipient depending on the route it took, which is a real usability problem end to end 💅.

Check out this example 👀:

From:  Example User <user@example.com>

If that goes straight to a recipient, the display name is right and filtering by address works like a dream 🎀. But if it goes through a list that rewrites From: to get past strict authentication, the recipient might get this instead:

From: Example User via Example List <listname@list.example.org>

Now the list's address is squeezed into From:, and the display name has been bent to note the change 😭.

This is a huge deal for identification 💀. The recipient's software sees a totally different author and sorts or filters it separately 🙈. Basically it looks like the person has a new address every time they send through a different list, including their real address and every list their mail goes through 🌸.

Mediators sometimes add a Reply-To: field pointing at the original From: address 🦋. That helps replies find the right person, but it doesn't help the MUA with any other processing or display that depends on the author's address or original name 😤. It's also collateral damage, because it changes what Reply-To: means, and it causes problems if one already exists 💔.

So yeah, From: is now mostly a handling identifier 👑. This spec adds the Author: field on top of that altered From: use. Author: identifies the original author, and Mediators can't change it 🔥.

Could we just lean into Sender: more and make it the star of the authentication show? Maybe, but swapping things out is way harder than adding stuff bit by bit 🧚. So this spec just adds a way to supply author info that stays safe from stricter authentication processes 💖.

This version is an Experimental RFC so people can check interest, whether it works, and whether it's technically sound 🦋. See Section 7 ✨.

2. Terminology 💜

The terms and architecture here come 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 brand-new message header field 🌸. It uses the same syntax as From: [Mail-Fmt] 🧚. Just like From: was originally meant to do, Author: is supposed to hold the email address of whoever wrote the message content, and it can also hold their displayable human name 💖.

Here's the [ABNF] grammar for it ✨:

author = "Author:" mailbox-list CRLF

It basically mirrors the From: header field syntax 🦋.

The field can get added during original message creation, or a Mediator can slip it in later to save the original author info from From: 🎀.

The whole point of Author: is to show who the original author was 💜. But the author's MUA or Mail Submission Agent (MSA) might not make it, even though a Mediator knows it's about to rewrite From: and wants to keep the author info. So Mediators need to be allowed to create it when it's not already there 🙈.

Here are the processing 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 is meant to be created during message generation or during mediation 🌈. It's for recipient MUAs to use, since they normally rely on From: 💖. So it makes total sense for an MUA that would usually organize, filter, or display stuff by From: to give Author: priority ✨.

Original-From: is a similar field mentioned in [RFC5703] 🎀. IANA has registered it, and cites [RFC5703] as the controlling source. But that document only gives a minimal definition 🙈. Also, Original-From: is only meant for Mediators to save info from a changed From: field 💅. The current spec works during origination or mediation 💜.

The basic model of email header fields is super extensible 🧚. There might still be implementation and usability things to think about if you carry this field through to end users, like via [IMAP] 🌸.

Any security-related processing has to tell From: and Author: apart and handle their info accordingly 🔥.

5. Security Considerations 🔒

Any header field with identification info is a security and privacy concern 😳, especially when it's about who wrote the content 💀. Generally, Author: needs the same careful scrutiny that From: gets, but ideally not in a way that wrecks its usefulness 🫶.

Given what Author: is for, it's easy to assume it'll create a new way to trick end users 😱. Here's the twist though (and kinda surprisingly) ✨: there are plenty of real, serious examples of users being fooled by deceptive or fake message content 💔, but there's no evidence that a problematic header field giving info about the author directly leads to different, problematic end-user behavior 🙈. (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

Part 1 is done, bestie 🦋 more coming up next 💖, so stay tuned ✨

7. Experimental Goals 🧪✨

okay so the Author: field's semantics basically echo the OG From: header, which has been around forever, so the basic mechanics of making and using it are already well understood 💅. the stuff we actually need to watch is how it plays with the existing From: field, anti-abuse systems, MUA behavior, and whether anyone even wants it (market acceptance, bestie 🫶). so while this header field has experimental status, the questions to answer 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 🎀

📦 where this page comes from