1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
|
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 6854 Huawei Technologies
Updates: 5322 March 2013
Category: Standards Track
ISSN: 2070-1721
Update to Internet Message Format to Allow Group Syntax in
the "From:" and "Sender:" Header Fields
Abstract
The Internet Message Format (RFC 5322) allows "group" syntax in some
email header fields, such as "To:" and "CC:", but not in "From:" or
"Sender:". This document updates RFC 5322 to relax that restriction,
allowing group syntax in those latter fields, as well as in
"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). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained 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) 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Leiba Standards Track [Page 1]
^L
RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
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, as far back as RFC 822 [RFC0822], has
always required a usable address to appear in the "From:" header
field of messages in order to allow replies to be sent. To this end,
the syntax of messages, up to and including the current specification
[RFC5322], has required the use of the mailbox address form in the
originator ("From:" and "Sender:") fields of messages and has
specifically forbidden the use of the group address form, which
permits an empty list of addresses (that is, an address list with no
address included that might be used for a reply).
However, the use cases for the "From:" field have evolved. There are
numerous instances of automated systems that wish to send email but
cannot handle replies, and a "From:" field with no usable addresses
would be extremely useful for that purpose. More recently, work with
internationalized email addresses [RFC6530] creates a real need to
take a message with an internationalized email address and hand it to
an older client that would have no ability to reply to such an
address but might still wish to display the contents of the message.
The group construct provides an existing syntax for unusable
addresses (using the empty list of addresses) and also allows for a
text label that describes the originator. For example:
From: Automated System:;
A review of many current email programs finds that all reviewed
clients will properly display a message with group syntax in the
"From:" field. At worst, such programs generate an error message
when an attempt is made to reply to such a message. No other
interoperability problems have been discovered.
Leiba Standards Track [Page 2]
^L
RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
This document therefore updates the Internet Message Format
specification [RFC5322] to relax that restriction, allowing group
syntax to be used in the originator ("From:" and "Sender:") fields,
as well as in their corresponding resent ("Resent-From:" and
"Resent-Sender:") fields. This change permits empty groups, as
described above, and also permits named groups of mailboxes (groups
with non-empty lists of addresses; see Section 4). Nevertheless,
this document recommends against the general use of group syntax in
these fields at this time (see Section 3).
1.1. Notational Conventions
The notational conventions here are the same as those in RFC 5322,
and the following 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" appear capitalized, they are being used to indicate
particular requirements of this specification. A discussion of the
meanings of these terms appears in the Key Words document [RFC2119].
1.1.2. Syntactic Notation
This specification uses the Augmented Backus-Naur Form (ABNF)
[RFC5234] notation for the formal definitions of the syntax of
messages. Characters will be specified either by a decimal value
(e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by
a case-insensitive literal value enclosed in quotation marks (e.g.,
"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 specification
changes that definition to use the <address-list> syntax element, as
is used in other fields, such as "To:", "CC:", and "Reply-To:". This
specification also changes the definition of the "Sender:" header
field from the <mailbox> syntax element to the <address> syntax
element. While the <address> element includes the <mailbox> element
already, we have chosen to specify both in the updated syntax as a
way of highlighting the limited use intended for the change (see
Section 3).
Leiba Standards Track [Page 3]
^L
RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
Section 2.1 below is a full replacement for Section 3.6.2 of RFC
5322, containing the new syntax as well as a new description of the
semantics for the "From:" and "Sender:" fields. Section 2.2 below is
a replacement of only the ABNF syntax for the "Resent-From:" and
"Resent-Sender:" fields in Section 3.6.6 of RFC 5322; the rest of the
syntax as well as the descriptive text of Section 3.6.6 of RFC 5322
remains unchanged.
[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 putting the field name in quotation marks and
sometimes not, sometimes capitalizing the field name and sometimes
not, and sometimes including the final colon and sometimes not.
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.]
2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields
The originator fields of a message consist of the from field, the
sender field (when applicable), and optionally the reply-to field.
The from field consists of the field name "From" and a
comma-separated list of one or more addresses (either mailbox or
group syntax). If the from field contains more than one mailbox
specification (including all mailboxes included in any groups), then
the sender field, containing the field name "Sender" and a single
address, MUST appear in the message. The from field and the sender
field SHOULD NOT use group syntax; rather, the from field SHOULD use
only the mailbox-list syntax and the sender field SHOULD use only
mailbox syntax (see RFC 6854, Section 3). If the sender field uses
group syntax, the group MUST NOT contain more than one mailbox. In
either case, an optional reply-to field MAY also be included, which
contains the field name "Reply-To" and a comma-separated list of one
or more addresses.
from = "From:" (mailbox-list / address-list) CRLF
sender = "Sender:" (mailbox / address) CRLF
reply-to = "Reply-To:" address-list CRLF
The originator fields indicate the mailbox(es) of the source of the
message. The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message. The "Sender:" field specifies the
mailbox of the agent responsible for the actual transmission of the
message. For example, if a secretary were to send a message for
Leiba Standards Track [Page 4]
^L
RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
another person, the mailbox of the secretary would appear in the
"Sender:" field and the mailbox of the actual author would appear in
the "From:" field. If the originator of the message can be indicated
by a single mailbox and the author and transmitter are identical, the
"Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD
appear.
Note: The transmitter information is always present. The absence
of the "Sender:" field is sometimes mistakenly taken to mean that
the agent responsible for transmission of the message has not been
specified. This absence merely means that the transmitter is
identical to the author and is therefore not redundantly placed
into the "Sender:" field.
The originator fields also provide the information required when
replying to a message. When the "Reply-To:" field is present, it
indicates the address(es) to which the author of the message suggests
that replies be sent. In the absence of the "Reply-To:" field,
replies SHOULD by default be sent to the mailbox(es) specified in the
"From:" field unless otherwise specified by the person composing the
reply.
In all cases, the "From:" field SHOULD NOT contain any mailbox that
does not belong to the author(s) of the message. See also Section
3.6.3 of RFC 5322 [RFC5322] for more information on forming the
destination addresses for a reply.
2.2. Update to RFC 5322, Section 3.6.6. Resent Fields
This section updates RFC 5322, Section 3.6.6, to allow groups (via
the address-list ABNF production) in the "Resent-From:" and
"Resent-Sender:" fields, to parallel the change to "From:" and
"Sender:" above. The ABNF for these fields is changed as follows:
resent-from = "Resent-From:" (mailbox-list / address-list) CRLF
resent-sender = "Resent-Sender:" (mailbox / address) CRLF
Leiba Standards Track [Page 5]
^L
RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
3. Applicability Statement
Mailbox syntax is the normal syntax to use in the "From:" and
"Sender:" header fields; the address syntax defined in Section 2.1,
which allows the specification of a group, is only for Limited Use
(see RFC 2026 [RFC2026], Section 3.3, item (d)) for the reasons
described below.
Many Internet email procedures and much software assumes that the
addresses in the "From:" and "Sender:" fields can be replied to and
are suitable for use in organizing and filtering mail. The use of
groups instead of mailboxes can disrupt these uses. Consequently,
while this specification legitimizes the use of groups, it does so
only to enable circumstances when that use is necessary. Because the
use of this mechanism is new, it is important that its use be limited
to these circumstances and that it be used with caution. In
particular, user agents SHOULD NOT permit the use of groups in those
fields in outgoing messages.
4. Examples
First, consider an email message that is sent by an automated nightly
monitor program, to which replies should not be sent. Such messages
commonly include a valid, replyable address that will discard any
replies that are sent to it, but recipients who do reply might be
unaware that their replies will be discarded. If the message is
instead presented as follows, the recipients' email clients will not
allow them to reply in the first place:
From: Nightly Monitor Robot:;
Second, consider an email message that is meant to be "from" the two
managing partners of a business, Ben and Carol, and that is sent by
their assistant, Dave. This message could always have been presented
this way:
From: ben@example.com,carol@example.com
Sender: dave@example.com
This change allows it to be represented this way:
From: Managing Partners:ben@example.com,carol@example.com;
Sender: dave@example.com
Leiba Standards Track [Page 6]
^L
RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
5. Security Considerations
See the Internet Message Format specification [RFC5322] for general
discussion of security considerations related to the formatting of
email messages.
The "From:" address is special, in that most user agents display this
address, or the "friendly" text associated with it, to the end user,
and label it so as to identify it as the origin of the message (as
implied in Section 3.6.2 of RFC 5322). Group syntax in the "From:"
header field can be used to hide the identity of the message
originator. It is just as easy to use a fabricated "From:" address
to accomplish the same thing, so allowing groups in this field does
not exacerbate the security problem.
Some protocols attempt 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]). Such protocols will not be applicable to messages that
lack an actual email address (whether real or fake) in the "From:"
field. Local policy will determine how such messages are handled,
and senders, therefore, need to be aware that using groups in the
"From:" might adversely affect deliverability of the message.
Because groups have previously not been allowed in the "From:" and
"Sender:" header fields, it is possible that some implementations
that conform to RFC 5322 might not be prepared to handle the group
syntax, and, indeed, might not even recognize that group syntax is
being used. Of those implementations, some subset might, when
presented with group syntax in those header fields, behave in a way
that is exploitable by an attacker. It is deemed unlikely that this
will be a serious problem in practice: address field parsing is
generally an integral component of implementations, and address field
parsers are required to understand group syntax. In addition, if any
implementations should be exploitable through this mechanism, it is
already possible for attackers to do it by violating RFC 5322. Other
violations of RFC 5322 are commonly used by malefactors.
Leiba Standards Track [Page 7]
^L
RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
6. IANA Considerations
IANA has updated the "Permanent Message Header Field Names" registry
to include this document as a reference as follows:
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] |
+----------------+--------+------------+--------------------------+
Leiba Standards Track [Page 8]
^L
RFC 6854 Group Syntax in "From:" and "Sender:" March 2013
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/
Leiba Standards Track [Page 9]
^L
|