idnits 2.17.1 draft-leiba-5322upd-from-group-07.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 6, 2012) is 4188 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 6, 2012 5 Intended status: Standards Track 6 Expires: May 10, 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-07 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 10, 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:" . . . . . . 3 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 . . . . . 5 64 3. Applicability Statement . . . . . . . . . . . . . . . . . . 6 66 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 74 Author's Address . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 The Internet Message Format [RFC5322] allows "group" syntax in some 79 email header fields, such as "To:" and "CC:", but not in "From:" nor 80 "Sender:". As use cases for group syntax evolve, particularly with 81 respect to email address internationalization issues, it is becoming 82 clear that there is little value in forbidding that usage completely, 83 and significant value in allowing it in certain situations: 84 o There are times when it is desirable to represent the creator of a 85 message as a group or role designation, rather than as one or more 86 mailboxes. 87 o There are times when it is desirable to represent the creator 88 and/or sender of a message in a manner that is specifically not 89 valid in a reply. 91 The requirement to represent these identities as replyable mailboxes 92 has thus become unnecessarily restrictive, and this document updates 93 RFC 5322 to relax that restriction, allowing group syntax in "From:", 94 "Sender:", "Resent-From:", and "Resent-Sender:" for limited use (see 95 Section 3). 97 1.1. Notational Conventions 99 The notational conventions here are the same as those in RFC 5322, 100 and the following two subsections are copied directly from that 101 document. 103 1.1.1. Requirements Notation 105 This document occasionally uses terms that appear in capital letters. 106 When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD 107 NOT", and "MAY" appear capitalized, they are being used to indicate 108 particular requirements of this specification. A discussion of the 109 meanings of these terms appears in [RFC2119]. 111 1.1.2. Syntactic Notation 113 This specification uses the Augmented Backus-Naur Form (ABNF) 114 [RFC5234] notation for the formal definitions of the syntax of 115 messages. Characters will be specified either by a decimal value 116 (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by 117 a case-insensitive literal value enclosed in quotation marks (e.g., 118 "A" for either uppercase or lowercase A). 120 2. Allowing Group Syntax in "From:" and "Sender:" 122 Section 3.6.2 of RFC 5322 defines the "From:" header field as 123 containing a syntax element. This changes that 124 definition to use the syntax element, as is used in 125 other fields, such as "To:", "CC:", and "Reply-To:". This also 126 changes the definition of the "Sender:" header field from the 127 syntax element to the
syntax element. While the 128
element includes the element already, we have 129 chosen to specify both in the updated syntax as a way of highlighting 130 the limited use intended for the change (see Section 3). 132 Section 2.1 below is a full replacement for Section 3.6.2 of RFC 133 5322, containing the new syntax as well as a new description of the 134 semantics for the "From:" and "Sender:" fields. Section 2.2 below is 135 a replacement of only the ABNF syntax for the "Resent-From:" and 136 "Resent-Sender:" fields in section 3.6.6 of RFC 5322; the rest of the 137 syntax as well as the descriptive text of section 3.6.6 of RFC 5322 138 remains unchanged. 140 [[anchor5: RFC Editor (please remove this paragraph before 141 publication): I know that the text in the following section is not 142 consistent within itself nor with the rest of this document in how it 143 refers to message header fields, sometimes putting the field name in 144 quotation marks and sometimes not, sometimes capitalizing the field 145 name and sometimes not, and sometimes including the final colon and 146 sometimes not. It's the document editor's judgment that minimizing 147 changes to the original text is more important, in this case, than 148 attaining consistency. Please, therefore, hold back edits to the 149 following section, 2.1, as well as to Sections 1.1.1 and 1.1.2 above. 150 If you think there are editorial changes that you must make, let's 151 please discuss them explicitly during AUTH48.]] 153 2.1. Replacement of RFC 5322, Section 3.6.2. Originator Fields 155 In version -00, this section is unchanged from RFC 5322, to make it 156 easier to use DIFF to see the actual changes that this version 157 contains. Compare this version with version -00. [[anchor6: RFC 158 Editor: Please remove this paragraph before publication.]] 160 The originator fields of a message consist of the from field, the 161 sender field (when applicable), and optionally the reply-to field. 162 The from field consists of the field name "From" and a comma- 163 separated list of one or more addresses (either mailbox or group 164 syntax). If the from field contains more than one mailbox 165 specification (including all mailboxes included in any groups), then 166 the sender field, containing the field name "Sender" and a single 167 address, MUST appear in the message. The from field and the sender 168 field SHOULD NOT use group syntax; rather, the from field SHOULD use 169 only the mailbox-list syntax and the sender field SHOULD use only 170 mailbox syntax (see Section 3). If the sender field uses group 171 syntax, the group MUST NOT contain more than one mailbox. In either 172 case, an optional reply-to field MAY also be included, which contains 173 the field name "Reply-To" and a comma-separated list of one or more 174 addresses. 176 from = "From:" (mailbox-list / address-list) CRLF 178 sender = "Sender:" (mailbox / address) CRLF 180 reply-to = "Reply-To:" address-list CRLF 182 The originator fields indicate the mailbox(es) of the source of the 183 message. The "From:" field specifies the author(s) of the message, 184 that is, the mailbox(es) of the person(s) or system(s) responsible 185 for the writing of the message. The "Sender:" field specifies the 186 mailbox of the agent responsible for the actual transmission of the 187 message. For example, if a secretary were to send a message for 188 another person, the mailbox of the secretary would appear in the 189 "Sender:" field and the mailbox of the actual author would appear in 190 the "From:" field. If the originator of the message can be indicated 191 by a single mailbox and the author and transmitter are identical, the 192 "Sender:" field SHOULD NOT be used. Otherwise, both fields SHOULD 193 appear. 195 Note: The transmitter information is always present. The absence 196 of the "Sender:" field is sometimes mistakenly taken to mean that 197 the agent responsible for transmission of the message has not been 198 specified. This absence merely means that the transmitter is 199 identical to the author and is therefore not redundantly placed 200 into the "Sender:" field. 202 The originator fields also provide the information required when 203 replying to a message. When the "Reply-To:" field is present, it 204 indicates the address(es) to which the author of the message suggests 205 that replies be sent. In the absence of the "Reply-To:" field, 206 replies SHOULD by default be sent to the mailbox(es) specified in the 207 "From:" field unless otherwise specified by the person composing the 208 reply. 210 In all cases, the "From:" field SHOULD NOT contain any mailbox that 211 does not belong to the author(s) of the message. See also [RFC5322] 212 Section 3.6.3 for more information on forming the destination 213 addresses for a reply. 215 2.2. Update to RFC 5322, Section 3.6.6. Resent Fields 217 This updates RFC 5322, Section 3.6.6, to allow groups (via the 218 address-list ABNF production) in the "Resent-From:" and "Resent- 219 Sender:" fields, to parallel the change to "From:" and "Sender:" 220 above. The ABNF for those fields is changed as follows: 222 resent-from = "Resent-From:" (mailbox-list / address-list) CRLF 224 resent-sender = "Resent-Sender:" (mailbox / address) CRLF 226 3. Applicability Statement 228 Mailbox syntax is the normal use in the "From:" and "Sender:" header 229 fields; the address syntax defined in Section 2.1, which allows the 230 specification of a group, is only for Limited Use (see [RFC2026], 231 Section 3.3, item (d)) for the reasons described below. 233 Very many Internet email procedures and software assume that the 234 addresses in "From:" and "Sender:" fields can be replied to and are 235 suitable for use in mail organizing and filtering. The use of groups 236 instead of mailboxes can disrupt those uses. Consequently, while 237 this specification legitimizes the use of groups, it does so only to 238 enable circumstances when that use is necessary, and it is important 239 that its use be limited to those circumstances and that it be used 240 with caution. In particular, user agents SHOULD NOT permit the use 241 of groups in those fields in outgoing messages. 243 4. Security Considerations 245 See the Internet Message Format specification [RFC5322] for general 246 discussion of security considerations related to the formatting of 247 email messages. 249 The "From:" address is special, in that most user agents display that 250 address, or the "friendly" text associated with it, to the end user, 251 and label that so as to identify it as the origin of the message (as 252 implied in Section 3.6.2 of RFC 5322). Group syntax in the "From:" 253 header field can be used to hide the identity of the message 254 originator. It is as easy to use a fabricated "From:" address to 255 accomplish the same thing, so allowing groups there does not 256 exacerbate the security problem. 258 Some protocols attempt to validate the originator address by matching 259 the "From:" address to a particular verified domain (see Author 260 Domain Signing Practices (ADSP) [RFC5617] for one such protocol). 261 Such protocols will not be applicable to messages that lack an actual 262 email address (whether real or fake) in the "From:" field. Local 263 policy will determine how such messages are handled, and senders, 264 therefore, need to be aware that using groups in the "From:" might 265 adversely affect deliverability of the message. 267 Because groups have previously not been allowed in the "From:" and 268 "Sender:" header fields, it is possible that some implementations 269 that conform to RFC 5322 might not be prepared to handle that syntax, 270 and, indeed, might not even recognize that group syntax is being 271 used. Of those implementations, some subset might, when presented 272 with group syntax in those header fields, behave in a way that is 273 exploitable by an attacker. It is deemed unlikely that this will be 274 a serious problem in practice: address field parsing is generally an 275 integral component of implementations, and address field parsers are 276 required to understand group syntax. In addition, if any 277 implementations should be exploitable through this mechanism, it is 278 already possible for attackers to do it by violating RFC 5322, and 279 other RFC 5322 violations are commonly used by malefactors. 281 5. IANA Considerations 283 IANA is asked to update the Permanent Message Header Field Names 284 registry ( 285 http://www.iana.org/assignments/message-headers/perm-headers.html ) 286 as follows: 288 OLD 289 +----------------+--------+------------+--------------------------+ 290 | From | mail | standard | [RFC5322] | 291 +----------------+--------+------------+--------------------------+ 293 +----------------+--------+------------+--------------------------+ 294 | Sender | mail | standard | [RFC5322] | 295 +----------------+--------+------------+--------------------------+ 297 +----------------+--------+------------+--------------------------+ 298 | Resent-From | mail | standard | [RFC5322] | 299 +----------------+--------+------------+--------------------------+ 301 +----------------+--------+------------+--------------------------+ 302 | Resent-Sender | mail | standard | [RFC5322] | 303 +----------------+--------+------------+--------------------------+ 305 NEW 306 +----------------+--------+------------+--------------------------+ 307 | From | mail | standard | [RFC5322] [[this RFC]] | 308 +----------------+--------+------------+--------------------------+ 310 +----------------+--------+------------+--------------------------+ 311 | Sender | mail | standard | [RFC5322] [[this RFC]] | 312 +----------------+--------+------------+--------------------------+ 314 +----------------+--------+------------+--------------------------+ 315 | Resent-From | mail | standard | [RFC5322] [[this RFC]] | 316 +----------------+--------+------------+--------------------------+ 318 +----------------+--------+------------+--------------------------+ 319 | Resent-Sender | mail | standard | [RFC5322] [[this RFC]] | 320 +----------------+--------+------------+--------------------------+ 322 6. References 324 6.1. Normative References 326 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 327 3", BCP 9, RFC 2026, October 1996. 329 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 330 Requirement Levels", BCP 14, RFC 2119, March 1997. 332 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 333 Specifications: ABNF", STD 68, RFC 5234, January 2008. 335 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 336 October 2008. 338 6.2. Informative References 340 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 341 "DomainKeys Identified Mail (DKIM) Author Domain Signing 342 Practices (ADSP)", RFC 5617, August 2009. 344 Author's Address 346 Barry Leiba 347 Huawei Technologies 349 Phone: +1 646 827 0648 350 Email: barryleiba@computer.org 351 URI: http://internetmessagingtechnology.org/