idnits 2.17.1 draft-leiba-5322upd-from-group-08.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 (November 26, 2012) is 4168 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 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) November 26, 2012 5 Intended status: Standards Track 6 Expires: May 30, 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-08 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 May 30, 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 . . . . . . . . . . . . . . . . . . . 3 57 1.1.2. Syntactic Notation . . . . . . . . . . . . . . . . . . . . 3 59 2. Allowing Group Syntax in "From:" and "Sender:" . . . . . . 4 60 2.1. Replacement of RFC 5322, Section 3.6.2. Originator 61 Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Update to RFC 5322, Section 3.6.6. Resent Fields . . . . . 6 64 3. Applicability Statement . . . . . . . . . . . . . . . . . . 6 66 4. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . 8 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 74 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 76 Author's Address . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 The Internet Message Format [RFC5322] allows "group" syntax in some 81 email header fields, such as "To:" and "CC:", but not in "From:" nor 82 "Sender:". While named groups were seen as useful in destination 83 fields their use in originator fields seemed unnecessary and was not 84 defined. Additionally, "group" syntax allows for empty groups (a 85 group name followed by no specified mailboxes) to support a "Bcc:" 86 function, and it was considered unnecessary to be able to have this 87 function for originator fields, because the message would then be 88 unreplyable. However, use cases for group syntax have evolved. The 89 concept of an originator as a group (a message "from the senior 90 partners", for example) is no longer considered unreasonable. And 91 there are instances, particularly with respect to new 92 internationalized email addresses, where a mail agent might need to 93 create an email message with no replyable addresses in the "From:" or 94 "Sender:" fields. Allowing group syntax in the "From:" and "Sender:" 95 fields makes that possible. Review of current email user agents 96 makes it clear that there is little interoperability risk in relaxing 97 the ban on that usage. 99 The requirement to represent these identities as replyable mailboxes 100 has thus become unnecessarily restrictive, and this document updates 101 RFC 5322 to relax that restriction, allowing group syntax in "From:", 102 "Sender:", "Resent-From:", and "Resent-Sender:" for limited use (see 103 Section 3). 105 1.1. Notational Conventions 107 The notational conventions here are the same as those in RFC 5322, 108 and the following two subsections are copied directly from that 109 document. 111 1.1.1. Requirements Notation 113 This document occasionally uses terms that appear in capital letters. 114 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 115 NOT", and "MAY" appear capitalized, they are being used to indicate 116 particular requirements of this specification. A discussion of the 117 meanings of these terms appears in [RFC2119]. 119 1.1.2. Syntactic Notation 121 This specification uses the Augmented Backus-Naur Form (ABNF) 122 [RFC5234] notation for the formal definitions of the syntax of 123 messages. Characters will be specified either by a decimal value 124 (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by 125 a case-insensitive literal value enclosed in quotation marks (e.g., 126 "A" for either uppercase or lowercase A). 128 2. Allowing Group Syntax in "From:" and "Sender:" 130 Section 3.6.2 of RFC 5322 defines the "From:" header field as 131 containing a syntax element. This specification 132 changes that definition to use the syntax element, as 133 is used in other fields, such as "To:", "CC:", and "Reply-To:". This 134 specification also changes the definition of the "Sender:" header 135 field from the syntax element to the
syntax 136 element. While the
element includes the element 137 already, we have chosen to specify both in the updated syntax as a 138 way of highlighting the limited use intended for the change (see 139 Section 3). 141 Section 2.1 below is a full replacement for Section 3.6.2 of RFC 142 5322, containing the new syntax as well as a new description of the 143 semantics for the "From:" and "Sender:" fields. Section 2.2 below is 144 a replacement of only the ABNF syntax for the "Resent-From:" and 145 "Resent-Sender:" fields in section 3.6.6 of RFC 5322; the rest of the 146 syntax as well as the descriptive text of section 3.6.6 of RFC 5322 147 remains unchanged. 149 [The text in the following section is not consistent within itself 150 nor with the rest of this document in how it refers to message header 151 fields, sometimes putting the field name in quotation marks and 152 sometimes not, sometimes capitalizing the field name and sometimes 153 not, and sometimes including the final colon and sometimes not. 154 Because minimizing changes to the original text is more important, in 155 this case, than attaining consistency, the text in Section 2.1, as 156 well as that in Section 1.1.1 and Section 1.1.2 above, is left as it 157 was in RFC 5322.] 159 [[RFC Editor (please remove this paragraph before publication): 160 Please, therefore, hold back edits to Section 1.1.1, Section 1.1.2, 161 and Section 2.1. If you think there are editorial changes that you 162 must make, let's please discuss them explicitly during AUTH48.]] 164 2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields 166 The originator fields of a message consist of the from field, the 167 sender field (when applicable), and optionally the reply-to field. 168 The from field consists of the field name "From" and a comma- 169 separated list of one or more addresses (either mailbox or group 170 syntax). If the from field contains more than one mailbox 171 specification (including all mailboxes included in any groups), then 172 the sender field, containing the field name "Sender" and a single 173 address, MUST appear in the message. The from field and the sender 174 field SHOULD NOT use group syntax; rather, the from field SHOULD use 175 only the mailbox-list syntax and the sender field SHOULD use only 176 mailbox syntax (see Section 3). If the sender field uses group 177 syntax, the group MUST NOT contain more than one mailbox. In either 178 case, an optional reply-to field MAY also be included, which contains 179 the field name "Reply-To" and a comma-separated list of one or more 180 addresses. 182 from = "From:" (mailbox-list / address-list) CRLF 184 sender = "Sender:" (mailbox / address) CRLF 186 reply-to = "Reply-To:" address-list CRLF 188 The originator fields indicate the mailbox(es) of the source of the 189 message. The "From:" field specifies the author(s) of the message, 190 that is, the mailbox(es) of the person(s) or system(s) responsible 191 for the writing of the message. The "Sender:" field specifies the 192 mailbox of the agent responsible for the actual transmission of the 193 message. For example, if a secretary were to send a message for 194 another person, the mailbox of the secretary would appear in the 195 "Sender:" field and the mailbox of the actual author would appear in 196 the "From:" field. If the originator of the message can be indicated 197 by a single mailbox and the author and transmitter are identical, the 198 "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD 199 appear. 201 Note: The transmitter information is always present. The absence 202 of the "Sender:" field is sometimes mistakenly taken to mean that 203 the agent responsible for transmission of the message has not been 204 specified. This absence merely means that the transmitter is 205 identical to the author and is therefore not redundantly placed 206 into the "Sender:" field. 208 The originator fields also provide the information required when 209 replying to a message. When the "Reply-To:" field is present, it 210 indicates the address(es) to which the author of the message suggests 211 that replies be sent. In the absence of the "Reply-To:" field, 212 replies SHOULD by default be sent to the mailbox(es) specified in the 213 "From:" field unless otherwise specified by the person composing the 214 reply. 216 In all cases, the "From:" field SHOULD NOT contain any mailbox that 217 does not belong to the author(s) of the message. See also [RFC5322] 218 Section 3.6.3 for more information on forming the destination 219 addresses for a reply. 221 2.2. Update to RFC 5322, Section 3.6.6. Resent Fields 223 This updates RFC 5322, Section 3.6.6, to allow groups (via the 224 address-list ABNF production) in the "Resent-From:" and "Resent- 225 Sender:" fields, to parallel the change to "From:" and "Sender:" 226 above. The ABNF for those fields is changed as follows: 228 resent-from = "Resent-From:" (mailbox-list / address-list) CRLF 230 resent-sender = "Resent-Sender:" (mailbox / address) CRLF 232 3. Applicability Statement 234 Mailbox syntax is the normal use in the "From:" and "Sender:" header 235 fields; the address syntax defined in Section 2.1, which allows the 236 specification of a group, is only for Limited Use (see [RFC2026], 237 Section 3.3, item (d)) for the reasons described below. 239 Very many Internet email procedures and software assume that the 240 addresses in "From:" and "Sender:" fields can be replied to and are 241 suitable for use in mail organizing and filtering. The use of groups 242 instead of mailboxes can disrupt those uses. Consequently, while 243 this specification legitimizes the use of groups, it does so only to 244 enable circumstances when that use is necessary, and it is important 245 that its use be limited to those circumstances and that it be used 246 with caution. In particular, user agents SHOULD NOT permit the use 247 of groups in those fields in outgoing messages. 249 4. Example 251 Consider an email message that is meant to be "from" the three 252 managing partners of a business, Alice, Ben, and Carol, and that is 253 sent by their assistant, Dave. That could always have been presented 254 this way: 255 From: alice@example.com,ben@example.com,carol@example.com Sender: 256 dave@example.com 258 This change allows that to be represented this way: 259 From: Managing 260 Partners:alice@example.com,ben@example.com,carol@example.com; 261 Sender: dave@example.com 263 5. Security Considerations 265 See the Internet Message Format specification [RFC5322] for general 266 discussion of security considerations related to the formatting of 267 email messages. 269 The "From:" address is special, in that most user agents display that 270 address, or the "friendly" text associated with it, to the end user, 271 and label that so as to identify it as the origin of the message (as 272 implied in Section 3.6.2 of RFC 5322). Group syntax in the "From:" 273 header field can be used to hide the identity of the message 274 originator. It is as easy to use a fabricated "From:" address to 275 accomplish the same thing, so allowing groups there does not 276 exacerbate the security problem. 278 Some protocols attempt to validate the originator address by matching 279 the "From:" address to a particular verified domain (see Author 280 Domain Signing Practices (ADSP) [RFC5617] for one such protocol). 281 Such protocols will not be applicable to messages that lack an actual 282 email address (whether real or fake) in the "From:" field. Local 283 policy will determine how such messages are handled, and senders, 284 therefore, need to be aware that using groups in the "From:" might 285 adversely affect deliverability of the message. 287 Because groups have previously not been allowed in the "From:" and 288 "Sender:" header fields, it is possible that some implementations 289 that conform to RFC 5322 might not be prepared to handle that syntax, 290 and, indeed, might not even recognize that group syntax is being 291 used. Of those implementations, some subset might, when presented 292 with group syntax in those header fields, behave in a way that is 293 exploitable by an attacker. It is deemed unlikely that this will be 294 a serious problem in practice: address field parsing is generally an 295 integral component of implementations, and address field parsers are 296 required to understand group syntax. In addition, if any 297 implementations should be exploitable through this mechanism, it is 298 already possible for attackers to do it by violating RFC 5322, and 299 other RFC 5322 violations are commonly used by malefactors. 301 6. IANA Considerations 303 IANA is asked to update the Permanent Message Header Field Names 304 registry ( 305 http://www.iana.org/assignments/message-headers/perm-headers.html ) 306 as follows: 308 OLD 309 +----------------+--------+------------+--------------------------+ 310 | From | mail | standard | [RFC5322] | 311 +----------------+--------+------------+--------------------------+ 313 +----------------+--------+------------+--------------------------+ 314 | Sender | mail | standard | [RFC5322] | 315 +----------------+--------+------------+--------------------------+ 317 +----------------+--------+------------+--------------------------+ 318 | Resent-From | mail | standard | [RFC5322] | 319 +----------------+--------+------------+--------------------------+ 321 +----------------+--------+------------+--------------------------+ 322 | Resent-Sender | mail | standard | [RFC5322] | 323 +----------------+--------+------------+--------------------------+ 325 NEW 326 +----------------+--------+------------+--------------------------+ 327 | From | mail | standard | [RFC5322] [[this RFC]] | 328 +----------------+--------+------------+--------------------------+ 330 +----------------+--------+------------+--------------------------+ 331 | Sender | mail | standard | [RFC5322] [[this RFC]] | 332 +----------------+--------+------------+--------------------------+ 334 +----------------+--------+------------+--------------------------+ 335 | Resent-From | mail | standard | [RFC5322] [[this RFC]] | 336 +----------------+--------+------------+--------------------------+ 338 +----------------+--------+------------+--------------------------+ 339 | Resent-Sender | mail | standard | [RFC5322] [[this RFC]] | 340 +----------------+--------+------------+--------------------------+ 342 7. References 344 7.1. Normative References 346 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 347 3", BCP 9, RFC 2026, October 1996. 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 353 Specifications: ABNF", STD 68, RFC 5234, January 2008. 355 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 356 October 2008. 358 7.2. Informative References 360 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 361 "DomainKeys Identified Mail (DKIM) Author Domain Signing 362 Practices (ADSP)", RFC 5617, August 2009. 364 Author's Address 366 Barry Leiba 367 Huawei Technologies 369 Phone: +1 646 827 0648 370 Email: barryleiba@computer.org 371 URI: http://internetmessagingtechnology.org/