idnits 2.17.1 draft-leiba-5322upd-from-group-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (Using the creation date from RFC5322, updated by this document, for RFC5378 checks: 2006-06-20) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 5, 2012) is 4131 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAI Working Group B. Leiba 3 Internet-Draft Huawei Technologies 4 Updates: 5322 (if approved) December 5, 2012 5 Intended status: Standards Track 6 Expires: June 8, 2013 8 Update to Internet Message Format to Allow Group Syntax in the "From:" 9 and "Sender:" Header Fields 10 draft-leiba-5322upd-from-group-09 12 Abstract 14 The Internet Message Format (RFC 5322) allows "group" syntax in some 15 email header fields, such as "To:" and "CC:", but not in "From:" nor 16 "Sender:". This document updates RFC 5322 to relax that restriction, 17 allowing group syntax in those latter fields, as well as in "Resent- 18 From:" and "Resent-Sender:", in certain situations. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on June 8, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 56 1.1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 57 1.1.2. Syntactic Notation . . . . . . . . . . . . . . . . . . . . 4 59 2. Allowing Group Syntax in "From:" and "Sender:" . . . . . . 4 60 2.1. Replacement of RFC 5322, Section 3.6.2. Originator 61 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.2. Update to RFC 5322, Section 3.6.6. Resent Fields . . . . . 6 64 3. Applicability Statement . . . . . . . . . . . . . . . . . 6 66 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . 7 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . 8 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . 9 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 9 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Author's Address . . . . . . . . . . . . . . . . . . . . . 10 78 1. Introduction 80 The Internet Message Format, as far back as RFC 822 [RFC0822], has 81 always required a usable address to appear in the "From:" header 82 field of messages in order to allow replies to be sent. To this end, 83 the syntax of messages, up to and including the current specification 84 [RFC5322], has required the use of the mailbox address form in the 85 originator ("From:" and "Sender:") fields of messages and has 86 specifically forbidden the use of the group address form, which 87 permits an empty list of addresses (that is, an address list with no 88 address included that might be used for a reply). 90 However, the use cases for the "From:" field have evolved. There are 91 numerous instances of automated systems that wish to send email but 92 cannot handle replies, and a "From:" field with no usable addresses 93 would be extremely useful for that purpose. More recently, work with 94 internationalized email addresses [RFC6530] creates the real need to 95 take a message with an internationalized email address and hand it to 96 an older client that would have no ability to reply to such an 97 address but might still wish to display the contents of the message. 98 The group construct provides an existing syntax for unusable 99 addresses (using the empty list of addresses) and also allows for a 100 text label that describes the originator. For example: 102 From: Automated System:; 104 A review of many current email programs finds that all reviewed 105 clients will properly display a message with group syntax in the 106 "From:" field. At worst, such programs generate an error message 107 when an attempt is made to reply to such a message. No other 108 interoperability problems have been discovered. 110 This document therefore updates the Internet Message Format 111 specification [RFC5322] to relax that restriction, allowing group 112 syntax to be used in the originator ("From:" and "Sender:") fields, 113 as well as in their corresponding resent ("Resent-From:" and "Resent- 114 Sender:") fields. This change permits empty groups, as described 115 above, and also permits named groups of mailboxes (groups with non- 116 empty lists of addresses; see Section 4). Nevertheless, this 117 document recommends against the general use of group syntax in these 118 fields at this time (see Section 3). 120 1.1. Notational Conventions 122 The notational conventions here are the same as those in RFC 5322, 123 and the following two subsections are copied directly from that 124 document. 126 1.1.1. Requirements Notation 128 This document occasionally uses terms that appear in capital letters. 129 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 130 NOT", and "MAY" appear capitalized, they are being used to indicate 131 particular requirements of this specification. A discussion of the 132 meanings of these terms appears in [RFC2119]. 134 1.1.2. Syntactic Notation 136 This specification uses the Augmented Backus-Naur Form (ABNF) 137 [RFC5234] notation for the formal definitions of the syntax of 138 messages. Characters will be specified either by a decimal value 139 (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by 140 a case-insensitive literal value enclosed in quotation marks (e.g., 141 "A" for either uppercase or lowercase A). 143 2. Allowing Group Syntax in "From:" and "Sender:" 145 Section 3.6.2 of RFC 5322 defines the "From:" header field as 146 containing a syntax element. This specification 147 changes that definition to use the syntax element, as 148 is used in other fields, such as "To:", "CC:", and "Reply-To:". This 149 specification also changes the definition of the "Sender:" header 150 field from the syntax element to the
syntax 151 element. While the
element includes the element 152 already, we have chosen to specify both in the updated syntax as a 153 way of highlighting the limited use intended for the change (see 154 Section 3). 156 Section 2.1 below is a full replacement for Section 3.6.2 of RFC 157 5322, containing the new syntax as well as a new description of the 158 semantics for the "From:" and "Sender:" fields. Section 2.2 below is 159 a replacement of only the ABNF syntax for the "Resent-From:" and 160 "Resent-Sender:" fields in section 3.6.6 of RFC 5322; the rest of the 161 syntax as well as the descriptive text of section 3.6.6 of RFC 5322 162 remains unchanged. 164 [The text in the following section is not consistent within itself 165 nor with the rest of this document in how it refers to message header 166 fields, sometimes putting the field name in quotation marks and 167 sometimes not, sometimes capitalizing the field name and sometimes 168 not, and sometimes including the final colon and sometimes not. 169 Because minimizing changes to the original text is more important, in 170 this case, than attaining consistency, the text in Section 2.1, as 171 well as that in Section 1.1.1 and Section 1.1.2 above, is left as it 172 was in RFC 5322.] 174 [[RFC Editor (please remove this paragraph before publication): 175 Please, therefore, hold back edits to Section 1.1.1, Section 1.1.2, 176 and Section 2.1. If you think there are editorial changes that you 177 must make, let's please discuss them explicitly during AUTH48.]] 179 2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields 181 The originator fields of a message consist of the from field, the 182 sender field (when applicable), and optionally the reply-to field. 183 The from field consists of the field name "From" and a comma- 184 separated list of one or more addresses (either mailbox or group 185 syntax). If the from field contains more than one mailbox 186 specification (including all mailboxes included in any groups), then 187 the sender field, containing the field name "Sender" and a single 188 address, MUST appear in the message. The from field and the sender 189 field SHOULD NOT use group syntax; rather, the from field SHOULD use 190 only the mailbox-list syntax and the sender field SHOULD use only 191 mailbox syntax (see Section 3). If the sender field uses group 192 syntax, the group MUST NOT contain more than one mailbox. In either 193 case, an optional reply-to field MAY also be included, which contains 194 the field name "Reply-To" and a comma-separated list of one or more 195 addresses. 197 from = "From:" (mailbox-list / address-list) CRLF 199 sender = "Sender:" (mailbox / address) CRLF 201 reply-to = "Reply-To:" address-list CRLF 203 The originator fields indicate the mailbox(es) of the source of the 204 message. The "From:" field specifies the author(s) of the message, 205 that is, the mailbox(es) of the person(s) or system(s) responsible 206 for the writing of the message. The "Sender:" field specifies the 207 mailbox of the agent responsible for the actual transmission of the 208 message. For example, if a secretary were to send a message for 209 another person, the mailbox of the secretary would appear in the 210 "Sender:" field and the mailbox of the actual author would appear in 211 the "From:" field. If the originator of the message can be indicated 212 by a single mailbox and the author and transmitter are identical, the 213 "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD 214 appear. 216 Note: The transmitter information is always present. The absence 217 of the "Sender:" field is sometimes mistakenly taken to mean that 218 the agent responsible for transmission of the message has not been 219 specified. This absence merely means that the transmitter is 220 identical to the author and is therefore not redundantly placed 221 into the "Sender:" field. 223 The originator fields also provide the information required when 224 replying to a message. When the "Reply-To:" field is present, it 225 indicates the address(es) to which the author of the message suggests 226 that replies be sent. In the absence of the "Reply-To:" field, 227 replies SHOULD by default be sent to the mailbox(es) specified in the 228 "From:" field unless otherwise specified by the person composing the 229 reply. 231 In all cases, the "From:" field SHOULD NOT contain any mailbox that 232 does not belong to the author(s) of the message. See also [RFC5322] 233 Section 3.6.3 for more information on forming the destination 234 addresses for a reply. 236 2.2. Update to RFC 5322, Section 3.6.6. Resent Fields 238 This updates RFC 5322, Section 3.6.6, to allow groups (via the 239 address-list ABNF production) in the "Resent-From:" and "Resent- 240 Sender:" fields, to parallel the change to "From:" and "Sender:" 241 above. The ABNF for those fields is changed as follows: 243 resent-from = "Resent-From:" (mailbox-list / address-list) CRLF 245 resent-sender = "Resent-Sender:" (mailbox / address) CRLF 247 3. Applicability Statement 249 Mailbox syntax is the normal use in the "From:" and "Sender:" header 250 fields; the address syntax defined in Section 2.1, which allows the 251 specification of a group, is only for Limited Use (see [RFC2026], 252 Section 3.3, item (d)) for the reasons described below. 254 Very many Internet email procedures and software assume that the 255 addresses in "From:" and "Sender:" fields can be replied to and are 256 suitable for use in mail organizing and filtering. The use of groups 257 instead of mailboxes can disrupt those uses. Consequently, while 258 this specification legitimizes the use of groups, it does so only to 259 enable circumstances when that use is necessary, and because the use 260 of this mechanism is new it is important that its use be limited to 261 those circumstances and that it be used with caution. In particular, 262 user agents SHOULD NOT permit the use of groups in those fields in 263 outgoing messages. 265 4. Examples 267 First, consider an email message that is sent by an automated nightly 268 monitor program, to which replies should not be sent. Such messages 269 commonly include a valid, replyable address that will discard any 270 replies that are sent to it, but recipients who do reply might be 271 unaware that their replies will be discarded. If the message is 272 instead presented this way, the recipients' email clients will not 273 allow them to reply in the first place: 275 From: Nightly Monitor Robot:; 277 Second, consider an email message that is meant to be "from" the two 278 managing partners of a business, Ben, and Carol, and that is sent by 279 their assistant, Dave. That could always have been presented this 280 way: 282 From: ben@example.com,carol@example.com 283 Sender: dave@example.com 285 This change allows that to be represented this way: 287 From: Managing Partners:ben@example.com,carol@example.com; 288 Sender: dave@example.com 290 5. Security Considerations 292 See the Internet Message Format specification [RFC5322] for general 293 discussion of security considerations related to the formatting of 294 email messages. 296 The "From:" address is special, in that most user agents display that 297 address, or the "friendly" text associated with it, to the end user, 298 and label that so as to identify it as the origin of the message (as 299 implied in Section 3.6.2 of RFC 5322). Group syntax in the "From:" 300 header field can be used to hide the identity of the message 301 originator. It is as easy to use a fabricated "From:" address to 302 accomplish the same thing, so allowing groups there does not 303 exacerbate the security problem. 305 Some protocols attempt to validate the originator address by matching 306 the "From:" address to a particular verified domain (see Author 307 Domain Signing Practices (ADSP) [RFC5617] for one such protocol). 308 Such protocols will not be applicable to messages that lack an actual 309 email address (whether real or fake) in the "From:" field. Local 310 policy will determine how such messages are handled, and senders, 311 therefore, need to be aware that using groups in the "From:" might 312 adversely affect deliverability of the message. 314 Because groups have previously not been allowed in the "From:" and 315 "Sender:" header fields, it is possible that some implementations 316 that conform to RFC 5322 might not be prepared to handle that syntax, 317 and, indeed, might not even recognize that group syntax is being 318 used. Of those implementations, some subset might, when presented 319 with group syntax in those header fields, behave in a way that is 320 exploitable by an attacker. It is deemed unlikely that this will be 321 a serious problem in practice: address field parsing is generally an 322 integral component of implementations, and address field parsers are 323 required to understand group syntax. In addition, if any 324 implementations should be exploitable through this mechanism, it is 325 already possible for attackers to do it by violating RFC 5322, and 326 other RFC 5322 violations are commonly used by malefactors. 328 6. IANA Considerations 330 IANA is asked to update the Permanent Message Header Field Names 331 registry ( 332 http://www.iana.org/assignments/message-headers/perm-headers.html ) 333 as follows: 335 OLD 336 +----------------+--------+------------+--------------------------+ 337 | From | mail | standard | [RFC5322] | 338 +----------------+--------+------------+--------------------------+ 340 +----------------+--------+------------+--------------------------+ 341 | Sender | mail | standard | [RFC5322] | 342 +----------------+--------+------------+--------------------------+ 344 +----------------+--------+------------+--------------------------+ 345 | Resent-From | mail | standard | [RFC5322] | 346 +----------------+--------+------------+--------------------------+ 348 +----------------+--------+------------+--------------------------+ 349 | Resent-Sender | mail | standard | [RFC5322] | 350 +----------------+--------+------------+--------------------------+ 352 NEW 353 +----------------+--------+------------+--------------------------+ 354 | From | mail | standard | [RFC5322] [[this RFC]] | 355 +----------------+--------+------------+--------------------------+ 357 +----------------+--------+------------+--------------------------+ 358 | Sender | mail | standard | [RFC5322] [[this RFC]] | 359 +----------------+--------+------------+--------------------------+ 361 +----------------+--------+------------+--------------------------+ 362 | Resent-From | mail | standard | [RFC5322] [[this RFC]] | 363 +----------------+--------+------------+--------------------------+ 365 +----------------+--------+------------+--------------------------+ 366 | Resent-Sender | mail | standard | [RFC5322] [[this RFC]] | 367 +----------------+--------+------------+--------------------------+ 369 7. References 371 7.1. Normative References 373 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 374 3", BCP 9, RFC 2026, October 1996. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, March 1997. 379 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 380 Specifications: ABNF", STD 68, RFC 5234, January 2008. 382 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 383 October 2008. 385 7.2. Informative References 387 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet 388 text messages", STD 11, RFC 822, August 1982. 390 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 391 "DomainKeys Identified Mail (DKIM) Author Domain Signing 392 Practices (ADSP)", RFC 5617, August 2009. 394 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 395 Internationalized Email", RFC 6530, February 2012. 397 Author's Address 399 Barry Leiba 400 Huawei Technologies 402 Phone: +1 646 827 0648 403 Email: barryleiba@computer.org 404 URI: http://internetmessagingtechnology.org/