7Internet Engineering Task Force (IETF) B. Leiba
8Request for Comments: 6854 Huawei Technologies
9Updates: 5322 March 2013
10Category: Standards Track
14 Update to Internet Message Format to Allow Group Syntax in
15 the "From:" and "Sender:" Header Fields
19 The Internet Message Format (RFC 5322) allows "group" syntax in some
20 email header fields, such as "To:" and "CC:", but not in "From:" or
21 "Sender:". This document updates RFC 5322 to relax that restriction,
22 allowing group syntax in those latter fields, as well as in
23 "Resent-From:" and "Resent-Sender:", in certain situations.
27 This is an Internet Standards Track document.
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 5741.
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 http://www.rfc-editor.org/info/rfc6854.
41 Copyright (c) 2013 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (http://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Simplified BSD License text as described in Section 4.e of
51 the Trust Legal Provisions and are provided without warranty as
52 described in the Simplified BSD License.
58Leiba Standards Track [Page 1]
60RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
67 1.1.1. Requirements Notation . . . . . . . . . . . . . . . . . 3
68 1.1.2. Syntactic Notation . . . . . . . . . . . . . . . . . . 3
69 2. Allowing Group Syntax in "From:" and "Sender:" . . . . . . . . 3
70 2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields . 4
71 2.2. Update to RFC 5322, Section 3.6.6. Resent Fields . . . . . 5
72 3. Applicability Statement . . . . . . . . . . . . . . . . . . . . 6
73 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
74 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
77 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9
78 7.2. Informative References . . . . . . . . . . . . . . . . . . 9
82 The Internet Message Format, as far back as RFC 822 [RFC0822], has
83 always required a usable address to appear in the "From:" header
84 field of messages in order to allow replies to be sent. To this end,
85 the syntax of messages, up to and including the current specification
86 [RFC5322], has required the use of the mailbox address form in the
87 originator ("From:" and "Sender:") fields of messages and has
88 specifically forbidden the use of the group address form, which
89 permits an empty list of addresses (that is, an address list with no
90 address included that might be used for a reply).
92 However, the use cases for the "From:" field have evolved. There are
93 numerous instances of automated systems that wish to send email but
94 cannot handle replies, and a "From:" field with no usable addresses
95 would be extremely useful for that purpose. More recently, work with
96 internationalized email addresses [RFC6530] creates a real need to
97 take a message with an internationalized email address and hand it to
98 an older client that would have no ability to reply to such an
99 address but might still wish to display the contents of the message.
100 The group construct provides an existing syntax for unusable
101 addresses (using the empty list of addresses) and also allows for a
102 text label that describes the originator. For example:
104 From: Automated System:;
106 A review of many current email programs finds that all reviewed
107 clients will properly display a message with group syntax in the
108 "From:" field. At worst, such programs generate an error message
109 when an attempt is made to reply to such a message. No other
110 interoperability problems have been discovered.
114Leiba Standards Track [Page 2]
116RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
119 This document therefore updates the Internet Message Format
120 specification [RFC5322] to relax that restriction, allowing group
121 syntax to be used in the originator ("From:" and "Sender:") fields,
122 as well as in their corresponding resent ("Resent-From:" and
123 "Resent-Sender:") fields. This change permits empty groups, as
124 described above, and also permits named groups of mailboxes (groups
125 with non-empty lists of addresses; see Section 4). Nevertheless,
126 this document recommends against the general use of group syntax in
127 these fields at this time (see Section 3).
1291.1. Notational Conventions
131 The notational conventions here are the same as those in RFC 5322,
132 and the following two subsections are copied directly from that
1351.1.1. Requirements Notation
137 This document occasionally uses terms that appear in capital letters.
138 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
139 NOT", and "MAY" appear capitalized, they are being used to indicate
140 particular requirements of this specification. A discussion of the
141 meanings of these terms appears in the Key Words document [RFC2119].
1431.1.2. Syntactic Notation
145 This specification uses the Augmented Backus-Naur Form (ABNF)
146 [RFC5234] notation for the formal definitions of the syntax of
147 messages. Characters will be specified either by a decimal value
148 (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
149 a case-insensitive literal value enclosed in quotation marks (e.g.,
150 "A" for either uppercase or lowercase A).
1522. Allowing Group Syntax in "From:" and "Sender:"
154 Section 3.6.2 of RFC 5322 defines the "From:" header field as
155 containing a <mailbox-list> syntax element. This specification
156 changes that definition to use the <address-list> syntax element, as
157 is used in other fields, such as "To:", "CC:", and "Reply-To:". This
158 specification also changes the definition of the "Sender:" header
159 field from the <mailbox> syntax element to the <address> syntax
160 element. While the <address> element includes the <mailbox> element
161 already, we have chosen to specify both in the updated syntax as a
162 way of highlighting the limited use intended for the change (see
170Leiba Standards Track [Page 3]
172RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
175 Section 2.1 below is a full replacement for Section 3.6.2 of RFC
176 5322, containing the new syntax as well as a new description of the
177 semantics for the "From:" and "Sender:" fields. Section 2.2 below is
178 a replacement of only the ABNF syntax for the "Resent-From:" and
179 "Resent-Sender:" fields in Section 3.6.6 of RFC 5322; the rest of the
180 syntax as well as the descriptive text of Section 3.6.6 of RFC 5322
183 [The text in the following section is not consistent within itself
184 nor with the rest of this document in how it refers to message header
185 fields, sometimes putting the field name in quotation marks and
186 sometimes not, sometimes capitalizing the field name and sometimes
187 not, and sometimes including the final colon and sometimes not.
188 Because minimizing changes to the original text is more important, in
189 this case, than attaining consistency, the text in Section 2.1, as
190 well as that in Sections 1.1.1 and 1.1.2 above, is left as it was in
1932.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields
195 The originator fields of a message consist of the from field, the
196 sender field (when applicable), and optionally the reply-to field.
197 The from field consists of the field name "From" and a
198 comma-separated list of one or more addresses (either mailbox or
199 group syntax). If the from field contains more than one mailbox
200 specification (including all mailboxes included in any groups), then
201 the sender field, containing the field name "Sender" and a single
202 address, MUST appear in the message. The from field and the sender
203 field SHOULD NOT use group syntax; rather, the from field SHOULD use
204 only the mailbox-list syntax and the sender field SHOULD use only
205 mailbox syntax (see RFC 6854, Section 3). If the sender field uses
206 group syntax, the group MUST NOT contain more than one mailbox. In
207 either case, an optional reply-to field MAY also be included, which
208 contains the field name "Reply-To" and a comma-separated list of one
211 from = "From:" (mailbox-list / address-list) CRLF
213 sender = "Sender:" (mailbox / address) CRLF
215 reply-to = "Reply-To:" address-list CRLF
217 The originator fields indicate the mailbox(es) of the source of the
218 message. The "From:" field specifies the author(s) of the message,
219 that is, the mailbox(es) of the person(s) or system(s) responsible
220 for the writing of the message. The "Sender:" field specifies the
221 mailbox of the agent responsible for the actual transmission of the
222 message. For example, if a secretary were to send a message for
226Leiba Standards Track [Page 4]
228RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
231 another person, the mailbox of the secretary would appear in the
232 "Sender:" field and the mailbox of the actual author would appear in
233 the "From:" field. If the originator of the message can be indicated
234 by a single mailbox and the author and transmitter are identical, the
235 "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
238 Note: The transmitter information is always present. The absence
239 of the "Sender:" field is sometimes mistakenly taken to mean that
240 the agent responsible for transmission of the message has not been
241 specified. This absence merely means that the transmitter is
242 identical to the author and is therefore not redundantly placed
243 into the "Sender:" field.
245 The originator fields also provide the information required when
246 replying to a message. When the "Reply-To:" field is present, it
247 indicates the address(es) to which the author of the message suggests
248 that replies be sent. In the absence of the "Reply-To:" field,
249 replies SHOULD by default be sent to the mailbox(es) specified in the
250 "From:" field unless otherwise specified by the person composing the
253 In all cases, the "From:" field SHOULD NOT contain any mailbox that
254 does not belong to the author(s) of the message. See also Section
255 3.6.3 of RFC 5322 [RFC5322] for more information on forming the
256 destination addresses for a reply.
2582.2. Update to RFC 5322, Section 3.6.6. Resent Fields
260 This section updates RFC 5322, Section 3.6.6, to allow groups (via
261 the address-list ABNF production) in the "Resent-From:" and
262 "Resent-Sender:" fields, to parallel the change to "From:" and
263 "Sender:" above. The ABNF for these fields is changed as follows:
265 resent-from = "Resent-From:" (mailbox-list / address-list) CRLF
267 resent-sender = "Resent-Sender:" (mailbox / address) CRLF
282Leiba Standards Track [Page 5]
284RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
2873. Applicability Statement
289 Mailbox syntax is the normal syntax to use in the "From:" and
290 "Sender:" header fields; the address syntax defined in Section 2.1,
291 which allows the specification of a group, is only for Limited Use
292 (see RFC 2026 [RFC2026], Section 3.3, item (d)) for the reasons
295 Many Internet email procedures and much software assumes that the
296 addresses in the "From:" and "Sender:" fields can be replied to and
297 are suitable for use in organizing and filtering mail. The use of
298 groups instead of mailboxes can disrupt these uses. Consequently,
299 while this specification legitimizes the use of groups, it does so
300 only to enable circumstances when that use is necessary. Because the
301 use of this mechanism is new, it is important that its use be limited
302 to these circumstances and that it be used with caution. In
303 particular, user agents SHOULD NOT permit the use of groups in those
304 fields in outgoing messages.
308 First, consider an email message that is sent by an automated nightly
309 monitor program, to which replies should not be sent. Such messages
310 commonly include a valid, replyable address that will discard any
311 replies that are sent to it, but recipients who do reply might be
312 unaware that their replies will be discarded. If the message is
313 instead presented as follows, the recipients' email clients will not
314 allow them to reply in the first place:
316 From: Nightly Monitor Robot:;
318 Second, consider an email message that is meant to be "from" the two
319 managing partners of a business, Ben and Carol, and that is sent by
320 their assistant, Dave. This message could always have been presented
323 From: ben@example.com,carol@example.com
324 Sender: dave@example.com
326 This change allows it to be represented this way:
328 From: Managing Partners:ben@example.com,carol@example.com;
329 Sender: dave@example.com
338Leiba Standards Track [Page 6]
340RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
3435. Security Considerations
345 See the Internet Message Format specification [RFC5322] for general
346 discussion of security considerations related to the formatting of
349 The "From:" address is special, in that most user agents display this
350 address, or the "friendly" text associated with it, to the end user,
351 and label it so as to identify it as the origin of the message (as
352 implied in Section 3.6.2 of RFC 5322). Group syntax in the "From:"
353 header field can be used to hide the identity of the message
354 originator. It is just as easy to use a fabricated "From:" address
355 to accomplish the same thing, so allowing groups in this field does
356 not exacerbate the security problem.
358 Some protocols attempt to validate the originator address by matching
359 the "From:" address to a particular verified domain (for one such
360 protocol, see the Author Domain Signing Practices (ADSP) document
361 [RFC5617]). Such protocols will not be applicable to messages that
362 lack an actual email address (whether real or fake) in the "From:"
363 field. Local policy will determine how such messages are handled,
364 and senders, therefore, need to be aware that using groups in the
365 "From:" might adversely affect deliverability of the message.
367 Because groups have previously not been allowed in the "From:" and
368 "Sender:" header fields, it is possible that some implementations
369 that conform to RFC 5322 might not be prepared to handle the group
370 syntax, and, indeed, might not even recognize that group syntax is
371 being used. Of those implementations, some subset might, when
372 presented with group syntax in those header fields, behave in a way
373 that is exploitable by an attacker. It is deemed unlikely that this
374 will be a serious problem in practice: address field parsing is
375 generally an integral component of implementations, and address field
376 parsers are required to understand group syntax. In addition, if any
377 implementations should be exploitable through this mechanism, it is
378 already possible for attackers to do it by violating RFC 5322. Other
379 violations of RFC 5322 are commonly used by malefactors.
394Leiba Standards Track [Page 7]
396RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
3996. IANA Considerations
401 IANA has updated the "Permanent Message Header Field Names" registry
402 to include this document as a reference as follows:
405 +----------------+--------+------------+--------------------------+
406 | From | mail | standard | [RFC5322] |
407 +----------------+--------+------------+--------------------------+
409 +----------------+--------+------------+--------------------------+
410 | Sender | mail | standard | [RFC5322] |
411 +----------------+--------+------------+--------------------------+
413 +----------------+--------+------------+--------------------------+
414 | Resent-From | mail | standard | [RFC5322] |
415 +----------------+--------+------------+--------------------------+
417 +----------------+--------+------------+--------------------------+
418 | Resent-Sender | mail | standard | [RFC5322] |
419 +----------------+--------+------------+--------------------------+
422 +----------------+--------+------------+--------------------------+
423 | From | mail | standard | [RFC5322] [RFC6854] |
424 +----------------+--------+------------+--------------------------+
426 +----------------+--------+------------+--------------------------+
427 | Sender | mail | standard | [RFC5322] [RFC6854] |
428 +----------------+--------+------------+--------------------------+
430 +----------------+--------+------------+--------------------------+
431 | Resent-From | mail | standard | [RFC5322] [RFC6854] |
432 +----------------+--------+------------+--------------------------+
434 +----------------+--------+------------+--------------------------+
435 | Resent-Sender | mail | standard | [RFC5322] [RFC6854] |
436 +----------------+--------+------------+--------------------------+
450Leiba Standards Track [Page 8]
452RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
4577.1. Normative References
459 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
460 3", BCP 9, RFC 2026, October 1996.
462 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
463 Requirement Levels", BCP 14, RFC 2119, March 1997.
465 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
466 Specifications: ABNF", STD 68, RFC 5234, January 2008.
468 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
4717.2. Informative References
473 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet
474 text messages", STD 11, RFC 822, August 1982.
476 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine,
477 "DomainKeys Identified Mail (DKIM) Author Domain Signing
478 Practices (ADSP)", RFC 5617, August 2009.
480 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
481 Internationalized Email", RFC 6530, February 2012.
488 Phone: +1 646 827 0648
489 EMail: barryleiba@computer.org
490 URI: http://internetmessagingtechnology.org/
506Leiba Standards Track [Page 9]