RFC 6854

Update to Internet Message Format to Allow Group Syntax in the "From:" and "Sender:" Header Fields 🎀

Okay bestie, let's get into it! 💖 This is RFC 6854, an IETF doc (Internet Engineering Task Force) written by B. Leiba from Huawei Technologies and dated March 2013. It's Standards Track, so it's the real deal, and its ISSN is 2070-1721. It updates RFC 5322, which is the Internet Message Format spec. It doesn't list anything it obsoletes. 🧚

Abstract ✨

The Internet Message Format (RFC 5322) lets "group" syntax show up in some email header fields, like "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to loosen that rule. Group syntax becomes allowed in those latter fields, plus "Resent-From:" and "Resent-Sender:", in certain situations. 🦋

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

Info about the current status of this document, any errata, and how to send feedback on it is at http://www.rfc-editor.org/info/rfc6854.

Copyright Notice 💅

Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) as in effect on the date of publication of this document. Please read these documents carefully, because 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 they're provided without warranty as described in the Simplified BSD License. 🔥

Table of Contents 🌸

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
  1.1.  Notational Conventions  . . . . . . . . . . . . . . . . . . 3
    1.1.1.  Requirements Notation . . . . . . . . . . . . . . . . . 3
    1.1.2.  Syntactic Notation  . . . . . . . . . . . . . . . . . . 3
2.  Allowing Group Syntax in "From:" and "Sender:"  . . . . . . . . 3
  2.1.  Replacement of RFC 5322, Section 3.6.2. Originator Fields . 4
  2.2.  Update to RFC 5322, Section 3.6.6. Resent Fields  . . . . . 5
3.  Applicability Statement . . . . . . . . . . . . . . . . . . . . 6
4.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
  7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
  7.2.  Informative References  . . . . . . . . . . . . . . . . . . 9

1. Introduction 💖

The Internet Message Format, going all the way back to RFC 822 [RFC0822], has always needed a usable address in the "From:" header field of a message so replies can be sent. That's why the syntax of messages, up to and including the current spec [RFC5322], has required the mailbox address form in the originator ("From:" and "Sender:") fields. It has also specifically forbidden the group address form, which allows an empty list of addresses (basically an address list with no address in it that could be used for a reply). 🌈

But the use cases for "From:" have evolved! 🍓 There are tons of automated systems that want to send email but can't handle replies, and a "From:" field with no usable addresses would be super useful for them. More recently, work on internationalized email addresses [RFC6530] creates a real need to take a message with an internationalized address and hand it to an older client. That client can't reply to the address, but it might still want to show the message contents. The group construct already gives us a syntax for unusable addresses (using the empty list of addresses), and it also lets you add a text label describing the originator. For example:

From: Automated System:;

A review of many current email programs found that every client reviewed will properly display a message with group syntax in the "From:" field. At worst, a program shows an error message when someone tries to reply. No other interoperability problems were found. ✨

So this document updates the Internet Message Format spec [RFC5322] to relax that restriction. Group syntax can now be used in the originator ("From:" and "Sender:") fields, and in their matching resent fields ("Resent-From:" and "Resent-Sender:"). This allows empty groups, as described above, and it also allows named groups of mailboxes (groups with non-empty lists of addresses; see Section 4). Even so, this document recommends against the general use of group syntax in these fields right now (see Section 3). 🙈

1.1. Notational Conventions 🎀

The notational conventions here are the same as RFC 5322's. The next two subsections are copied directly from that document.

1.1.1. Requirements Notation

This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD NOT", and "MAY" show up capitalized, they're being used to point out particular requirements of this spec. You can read about what these terms mean in the Key Words document [RFC2119]. 🔥

1.1.2. Syntactic Notation

This spec uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation for the formal definitions of message syntax. Characters are specified either by a decimal value (for example, %d65 for uppercase A and %d97 for lowercase A) or by a case-insensitive literal value in quotation marks (for example, "A" for either uppercase or lowercase A). 🧚

2. Allowing Group Syntax in "From:" and "Sender:" ✨

Section 3.6.2 of RFC 5322 defines the "From:" header field as containing a <mailbox-list> syntax element. This spec changes that definition to use the <address-list> syntax element, which is already used in other fields like "To:", "CC:", and "Reply-To:". This spec also changes the definition of the "Sender:" header field from the <mailbox> syntax element to the <address> syntax element. The <address> element already includes <mailbox>, but we chose to spell out both in the updated syntax to highlight how limited the intended use of this change is (see Section 3). 👑

Section 2.1 below is a full replacement for Section 3.6.2 of RFC 5322. It contains the new syntax along with a new description of the semantics for the "From:" and "Sender:" fields. Section 2.2 below only replaces the ABNF syntax for the "Resent-From:" and "Resent-Sender:" fields in Section 3.6.6 of RFC 5322. The rest of the syntax and the descriptive text of Section 3.6.6 of RFC 5322 stay the same. 💜

[The text in the following section is not consistent within itself nor with the rest of this document in how it refers to message header fields. Sometimes it puts the field name in quotation marks and sometimes it doesn't, sometimes it capitalizes the field name and sometimes it doesn't, and sometimes it includes the final colon and sometimes it doesn't. Because minimizing changes to the original text is more important in this case than attaining consistency, the text in Section 2.1, as well as that in Sections 1.1.1 and 1.1.2 above, is left as it was in RFC 5322.]

Part 1 of 2 down! 🌈 Part 2 is coming with the rest of Section 2 and everything after it. 🦋

3. Applicability Statement ✨

okay so, mailbox syntax is the normal, everyday syntax for the "From:" and "Sender:" header fields 💅. The address syntax from Section 2.1, which lets you write a group, is only for Limited Use (see RFC 2026 [RFC2026], Section 3.3, item (d)) and only for the reasons below 🫶.

Here's the tea. Lots of email procedures and software assume that the addresses in "From:" and "Sender:" can be replied to and are good for organizing and filtering mail 📬. Groups instead of mailboxes can mess that up 😭. So yes, this spec makes groups legit, but only for when you actually need them 🎀. Since this is brand new, it's important to keep its use limited and be careful with it 🌸. In particular, user agents SHOULD NOT permit the use of groups in those fields in outgoing messages 🙈.

4. Examples 🧚

First up, an email sent by an automated nightly monitor program, where replies should not be sent 🤖. These messages usually include a valid, replyable address that quietly throws away any replies, and people who reply might not know their reply is getting binned 💀. If the message is written like this instead, the recipients' email clients won't even let them reply in the first place 🙅‍♀️:

   From: Nightly Monitor Robot:;

Next, an email that's meant to be "from" the two managing partners of a business, Ben and Carol, but it's actually sent by their assistant, Dave 💼. This message could always have been written this way:

   From: ben@example.com,carol@example.com
   Sender: dave@example.com

With this change, it can be written this way instead 👑:

   From: Managing Partners:ben@example.com,carol@example.com;
   Sender: dave@example.com

5. Security Considerations 🔐

Okay, bestie, this part is serious 😤. See the Internet Message Format specification [RFC5322] for general discussion of security considerations related to the formatting of email messages 📜.

The "From:" address is extra special, because most user agents show it to the end user, or the "friendly" text attached to it, and label it so people know it's where the message came from (as implied in Section 3.6.2 of RFC 5322) 👀. Group syntax in the "From:" header field can be used to hide who the message originator is 🕵️‍♀️. BUT it's just as easy to fake a "From:" address to do the exact same thing, so allowing groups in this field does not make the security problem any worse 🤷‍♀️.

Some protocols try to validate the originator address by matching the "From:" address to a particular verified domain (for one such protocol, see the Author Domain Signing Practices (ADSP) document [RFC5617]) 🔍. Those protocols won't apply to messages that don't have an actual email address (real or fake) in the "From:" field 🚫. Local policy decides how these messages get handled, so senders need to be aware that using groups in the "From:" might hurt the message's deliverability 📉.

Because groups haven't been allowed in the "From:" and "Sender:" header fields before, some implementations that conform to RFC 5322 might not be ready to handle group syntax 😬. They might not even realize group syntax is being used at all 😵. Some of those implementations might, when they see group syntax in those header fields, behave in a way an attacker could exploit ⚠️. It's deemed unlikely that this will be a serious problem in practice, because address field parsing is generally an integral part of implementations, and address field parsers are required to understand group syntax 💅. Also, if any implementations are exploitable through this mechanism, attackers can already do it by violating RFC 5322, and other violations of RFC 5322 are commonly used by malefactors 🦹‍♀️.

6. IANA Considerations 📋

IANA has updated the "Permanent Message Header Field Names" registry to include this document as a reference, like this 🦋:

   OLD
   +----------------+--------+------------+--------------------------+
   |  From          |  mail  |  standard  |  [RFC5322]               |
   +----------------+--------+------------+--------------------------+

   +----------------+--------+------------+--------------------------+
   |  Sender        |  mail  |  standard  |  [RFC5322]               |
   +----------------+--------+------------+--------------------------+

   +----------------+--------+------------+--------------------------+
   |  Resent-From   |  mail  |  standard  |  [RFC5322]               |
   +----------------+--------+------------+--------------------------+

   +----------------+--------+------------+--------------------------+
   |  Resent-Sender |  mail  |  standard  |  [RFC5322]               |
   +----------------+--------+------------+--------------------------+

   NEW
   +----------------+--------+------------+--------------------------+
   |  From          |  mail  |  standard  |  [RFC5322] [RFC6854]     |
   +----------------+--------+------------+--------------------------+

   +----------------+--------+------------+--------------------------+
   |  Sender        |  mail  |  standard  |  [RFC5322] [RFC6854]     |
   +----------------+--------+------------+--------------------------+

   +----------------+--------+------------+--------------------------+
   |  Resent-From   |  mail  |  standard  |  [RFC5322] [RFC6854]     |
   +----------------+--------+------------+--------------------------+

   +----------------+--------+------------+--------------------------+
   |  Resent-Sender |  mail  |  standard  |  [RFC5322] [RFC6854]     |
   +----------------+--------+------------+--------------------------+

---

7. References 📚

7.1. Normative References

• [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 🌷
• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 💜
• [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. ✨
• [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. 💌

7.2. Informative References

• [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. 🕰️
• [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009. 🔏
• [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012. 🌍

Author's Address 💖

Barry Leiba Huawei Technologies

Phone: +1 646 827 0648 EMail: barryleiba@computer.org URI: http://internetmessagingtechnology.org/ 🦋