idnits 2.17.1 draft-ietf-eai-rfc5337bis-dsn-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC5337, but the abstract doesn't seem to directly say this. It does mention RFC5337 though, so this could be OK. -- The draft header indicates that this document updates RFC3798, but the abstract doesn't seem to directly say this. It does mention RFC3798 though, so this could be OK. -- The draft header indicates that this document updates RFC3461, but the abstract doesn't seem to directly say this. It does mention RFC3461 though, so this could be OK. -- The draft header indicates that this document updates RFC3462, but the abstract doesn't seem to directly say this. It does mention RFC3462 though, so this could be OK. -- The draft header indicates that this document updates RFC3464, but the abstract doesn't seem to directly say this. It does mention RFC3464 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3461, updated by this document, for RFC5378 checks: 2001-06-21) (Using the creation date from RFC3462, updated by this document, for RFC5378 checks: 2001-06-19) -- 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 (April 1, 2011) is 4766 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) == Missing Reference: 'LANGTAGS' is mentioned on line 316, but not defined ** Obsolete normative reference: RFC 3462 (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) == Outdated reference: A later version (-13) exists of draft-ietf-eai-rfc5335bis-10 == Outdated reference: A later version (-16) exists of draft-ietf-eai-rfc5336bis-08 -- Obsolete informational reference (is this intentional?): RFC 5337 (Obsoleted by RFC 6533) -- Obsolete informational reference (is this intentional?): RFC 5504 (Obsoleted by RFC 6530) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen, Ed. 3 Internet-Draft AT&T Laboratories 4 Obsoletes: 5337 (if approved) C. Newman 5 Updates: 3461, 3462, 3464, 3798 Sun Microsystems 6 (if approved) A. Melnikov 7 Intended status: Standards Track Isode Ltd 8 Expires: October 3, 2011 April 1, 2011 10 Internationalized Delivery Status and Disposition Notifications 11 draft-ietf-eai-rfc5337bis-dsn-02 13 Abstract 15 Delivery status notifications (DSNs) are critical to the correct 16 operation of an email system. However, the existing Draft Standards 17 (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text 18 in the machine-readable portions of the protocol. This specification 19 adds a new address type for international email addresses so an 20 original recipient address with non-US-ASCII characters can be 21 correctly preserved even after downgrading. This also provides 22 updated content return media types for delivery status notifications 23 and message disposition notifications to support use of the new 24 address type. 26 This document extends RFC 3461, RFC 3462, RFC 3464, and RFC 3798. It 27 replaces the experimental RFC 5337. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 3, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 65 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3 66 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6 67 4.1. Additional Requirements on SMTP Servers . . . . . . . . . 9 68 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 11 71 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 12 72 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 12 73 6.4. message/global-delivery-status . . . . . . . . . . . . . . 13 74 6.5. message/global-disposition-notification . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Appendix A. Changes Since ... . . . . . . . . . . . . . . . . . . 18 80 A.1. Changes Since -00 . . . . . . . . . . . . . . . . . . . . 18 81 A.2. Changes Since RFC 5337 . . . . . . . . . . . . . . . . . . 18 82 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 84 1. Introduction 86 When an email message is transmitted using the UTF8SMTP 87 [I-D.ietf-eai-rfc5336bis] extension and Internationalized Email 88 Headers [I-D.ietf-eai-rfc5335bis], it is sometimes necessary to 89 return that message or generate a Message Disposition Notification 90 (MDN) [RFC3798]. As a message sent to multiple recipients can 91 generate a status and disposition notification for each recipient, it 92 is helpful if a client can correlate these notifications based on the 93 recipient address it provided; thus, preservation of the original 94 recipient is important. This specification describes how to preserve 95 the original recipient and updates the MDN and DSN formats to support 96 the new address types. 98 NOTE: While this specification updates the experimental versions of 99 this protocol by removing certain constructs (e.g., the ">" address syntax is no longer permitted), the name of the 101 Address Type "UTF-8" and the media type names message/global, 102 message/global-delivery-status and message/global-headers have not 103 been changed. 105 2. Conventions Used in This Document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 112 notation including the core rules defined in Appendix B of RFC 5234 113 [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629]. 115 3. UTF-8 Address Type 117 An Extensible Message Format for Delivery Status Notifications 118 [RFC3464] defines the concept of an address type. The address format 119 introduced in Internationalized Email Headers 120 [I-D.ietf-eai-rfc5335bis] is a new address type. The syntax for the 121 new address type in the context of status notifications is specified 122 at the end of this section. 124 An SMTP [RFC5321] server that advertises both the UTF8SMTP extension 125 [I-D.ietf-eai-rfc5336bis] and the DSN extension [RFC3461] MUST accept 126 a UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 127 characters. This address type also includes a 7-bit encoding 128 suitable for use in a message/delivery-status body part or an ORCPT 129 parameter sent to an SMTP server that does not advertise UTF8SMTP. 131 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, 132 and utf-8-address. Only the first form is 7-bit safe. 134 The utf-8-address form is only suitable for use in newly defined 135 protocols capable of native representation of 8-bit characters. That 136 is, the utf-8-address form MUST NOT be used in the ORCPT parameter 137 when the SMTP server doesn't advertise support for UTF8SMTP, or the 138 SMTP server supports UTF8SMTP, but the address contains US-ASCII 139 characters not permitted in the ORCPT parameter (e.g., the ORCPT 140 parameter forbids unencoded SP and the = character), or in a 7-bit 141 transport environment including a message/delivery-status Original- 142 Recipient or Final-Recipient field. In the first and third case, the 143 utf-8-addr-xtext form (see below) MUST be used instead; in the second 144 case, either the utf-8-addr-unitext or the utf-8-addr-xtext form MUST 145 be used. The utf-8-address form MAY be used in the ORCPT parameter 146 when the SMTP server also advertises support for UTF8SMTP and the 147 address doesn't contain any US-ASCII characters not permitted in the 148 ORCPT parameter. It SHOULD be used in a message/ 149 global-delivery-status Original-Recipient or Final-Recipient DSN 150 field, or in an Original-Recipient header field [RFC3798] if the 151 message is a UTF8SMTP message. 153 In addition, the utf-8-addr-unitext form can be used anywhere where 154 the utf-8-address form is allowed. 156 When used in the ORCPT parameter, the UTF-8 address type requires 157 that US-ASCII CTLs, SP, \, +, and = be encoded using 'unitext' 158 encoding (see below). This is described by the utf-8-addr-xtext and 159 utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding 160 uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below) 161 for encoding any Unicode character outside of US-ASCII range, as well 162 as for encoding CTLs, SP, \, +, and =. HEXPOINT is 2 to 6 163 hexadecimal digits. This encoding avoids the need to use the xtext 164 encoding described in [RFC3461], as any US-ASCII characters that 165 needs to be escaped using xtext encoding never appear in any unitext 166 encoded string. When sending data to a UTF8SMTP capable server, 167 native UTF-8 characters SHOULD be used instead of the 168 EmbeddedUnicodeChar syntax described in details below. When sending 169 data to an SMTP server that does not advertise UTF8SMTP, then the 170 EmbeddedUnicodeChar syntax MUST be used instead of UTF-8. 172 When the ORCPT parameter is placed in a message/ 173 global-delivery-status Original-Recipient field, the 'utf-8-addr- 174 xtext' form of the UTF-8 address type SHOULD be converted to the 175 'utf-8-address' form (see the ABNF below) by removing the 'unitext' 176 encoding. However, if an address is labeled with the UTF-8 address 177 type but does not conform to utf-8 syntax, then it MUST be copied 178 into the message/global-delivery-status field without alteration. 180 The ability to encode characters with the EmbeddedUnicodeChar 181 encodings should be viewed as a transitional mechanism and avoided 182 when possible. It is hoped that as systems lacking support for 183 UTF8SMTP become less common over time, these encodings can eventually 184 be phased out. 186 In the ABNF below, all productions not defined in this document are 187 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 188 [RFC3464]. 190 utf-8-type-addr = "utf-8;" utf-8-enc-addr 192 utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ] 193 ; uMailbox is defined in [I-D.ietf-eai-rfc5336bis]. 194 ; Mailbox is defined in [RFC5321]. 196 utf-8-enc-addr = utf-8-addr-xtext / 197 utf-8-addr-unitext / 198 utf-8-address 200 utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar) 201 ; 7bit form of utf-8-addr-unitext. 202 ; Safe for use in the ORCPT [RFC3461] 203 ; parameter even when UTF8SMTP SMTP 204 ; extension is not advertised. 206 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 207 ; MUST follow utf-8-address ABNF when 208 ; dequoted. 209 ; Safe for using in the ORCPT [RFC3461] 210 ; parameter when UTF8SMTP SMTP extension 211 ; is also advertised. 213 QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e 214 ; US-ASCII printable characters except 215 ; CTLs, SP, '\', '+', '='. 217 QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4 218 ; US-ASCII printable characters except 219 ; CTLs, SP, '\', '+' and '=', plus 220 ; other Unicode characters encoded in UTF-8 222 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 223 ; starts with "\x" 225 HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" / 226 "2B" / "3D" / "7F" / ; all xtext-specials 227 "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 228 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 229 ( NZDHEXDIG 3(HEXDIG) ) / ; 4 digit forms excluding 230 ( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate 231 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 232 ( "10" 4*HEXDIG ) ; 6 digit forms 233 ; represents either "\" or a Unicode code point outside 234 ; the US-ASCII repertoire 236 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 237 ; HEXDIG excluding 0-7 238 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 239 ; HEXDIG excluding "0" 240 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 241 ; HEXDIG excluding "0" and "D" 243 4. UTF-8 Delivery Status Notifications 245 A traditional delivery status notification [RFC3464] comes in a 246 three-part multipart/report [RFC3462] container, where the first part 247 is human-readable text describing the error, the second part is a 248 7-bit-only message/delivery-status, and the optional third part is 249 used for content (message/rfc822) or header (text/rfc822-headers) 250 return. As the present DSN format does not permit returning of 251 undeliverable UTF8SMTP messages, three new media types are needed. 253 The first type, message/global-delivery-status, has the syntax of 254 message/delivery-status with three modifications. First, the charset 255 for message/global-delivery-status is UTF-8, and thus any field MAY 256 contain UTF-8 characters when appropriate (see the ABNF below). In 257 particular, the Diagnostic-Code field MAY contain UTF-8 as described 258 in UTF8SMTP [I-D.ietf-eai-rfc5336bis]; the Diagnostic-Code field 259 SHOULD be in i-default language [RFC2277]. Second, systems 260 generating a message/global-delivery-status body part SHOULD use the 261 utf-8-address form of the UTF-8 address type for all addresses 262 containing characters outside the US-ASCII repertoire. These systems 263 SHOULD up-convert the utf-8-addr-xtext or the utf-8-addr-unitext form 264 of a UTF-8 address type in the ORCPT parameter to the utf-8-address 265 form of a UTF-8 address type in the Original-Recipient field. Third, 266 a new optional field called Localized-Diagnostic is added. Each 267 instance includes a language tag [RFC5646] and contains text in the 268 specified language. This is equivalent to the text part of the 269 Diagnostic-Code field. All instances of Localized-Diagnostic MUST 270 use different language tags. The ABNF for message/ 271 global-delivery-status is specified below. 273 In the ABNF below, all productions not defined in this document are 274 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 275 [RFC3464]. Note that is the same as from 277 [RFC5322], but without . If or when RFC 5322 is updated to 278 disallow , this should become just Also, if or when 279 RFC 5322 is updated to disallow control characters in , this 280 should become a reference to that update instead. 282 utf-8-delivery-status-content = per-message-fields 283 1*( CRLF utf-8-per-recipient-fields ) 284 ; "per-message-fields" remains unchanged from the definition 285 ; in RFC 3464, except for the "extension-field" 286 ; which is updated below. 288 utf-8-per-recipient-fields = 289 [ original-recipient-field CRLF ] 290 final-recipient-field CRLF 291 action-field CRLF 292 status-field CRLF 293 [ remote-mta-field CRLF ] 294 [ diagnostic-code-field CRLF 295 *(localized-diagnostic-text-field CRLF) ] 296 [ last-attempt-date-field CRLF ] 297 [ will-retry-until-field CRLF ] 298 *( extension-field CRLF ) 299 ; All fields except for "original-recipient-field", 300 ; "final-recipient-field", "diagnostic-code-field" 301 ; and "extension-field" remain unchanged from 302 ; the definition in RFC 3464. 304 generic-address =/ utf-8-enc-addr 305 ; Only allowed with the "utf-8" address-type. 306 ; Updates Section 3.2.3 of RFC3798 307 ; 308 ; This indirectly updates "original-recipient-field" 309 ; and "final-recipient-field" 311 diagnostic-code-field = 312 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed 314 localized-diagnostic-text-field = 315 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 316 ; "Language-Tag" is a language tag as defined in [LANGTAGS]. 318 extension-field =/ extension-field-name ":" *utf8-text 319 ; Updates Section 7 of RFC3798 321 text-fixed = %d1-9 / ; Any US-ASCII character except for NUL, 322 %d11 / ; CR and LF 323 %d12 / ; See note above about 324 %d14-127 326 utf8-text = text-fixed / UTF8-non-ascii 328 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 329 The second type, used for returning the content, is message/global 330 which is similar to message/rfc822, except it contains a message with 331 UTF-8 headers. This media type is described in 332 [I-D.ietf-eai-rfc5335bis]. 334 The third type, used for returning the headers, is message/ 335 global-headers and contains only the UTF-8 header fields of a message 336 (all lines prior to the first blank line in a UTF8SMTP message). 337 Unlike message/global, this body part provides no difficulties for 338 the present infrastructure. 340 Note that as far as multipart/report [RFC3462] container is 341 concerned, message/global-delivery-status, message/global, and 342 message/global-headers MUST be treated as equivalent to message/ 343 delivery-status, message/rfc822, and text/rfc822-headers. That is, 344 implementations processing multipart/report MUST expect any 345 combinations of the 6 media types mentioned above inside a multipart/ 346 report media type. 348 All three new types will typically use the "8bit" Content-Transfer- 349 Encoding. (In the event all content is 7-bit, the equivalent 350 traditional types for delivery status notifications MAY be used. For 351 example, if information in message/global-delivery-status part can be 352 represented without any loss of information as message/ 353 delivery-status, then the message/delivery-status body part may be 354 used.) Note that [I-D.ietf-eai-rfc5335bis] relaxed restriction from 355 MIME [RFC2046] regarding use of Content-Transfer-Encoding in new 356 "message" subtypes. This specification explicitly allows use of 357 Content-Transfer-Encoding in message/global-headers and message/ 358 global-delivery-status. This is not believed to be problematic as 359 these new media types are intended primarily for use by newer systems 360 with full support for 8-bit MIME and UTF-8 headers. 362 4.1. Additional Requirements on SMTP Servers 364 If an SMTP server that advertises both UTF8SMTP and DSN needs to 365 return an undeliverable UTF8SMTP message, then it MUST NOT downgrade 366 [RFC5504] the UTF8SMTP message when generating the corresponding 367 multipart/report. If the return path SMTP server does not support 368 UTF8SMTP, then the undeliverable body part and headers MUST be 369 encoded using a 7-bit Content-Transfer-Encoding such as "base64" or 370 "quoted-printable" [RFC2045], as detailed in Section 4. Otherwise, 371 "8bit" Content-Transfer-Encoding can be used. 373 5. UTF-8 Message Disposition Notifications 375 Message Disposition Notifications [RFC3798] have a similar design and 376 structure to DSNs. As a result, they use the same basic return 377 format. When generating an MDN for a UTF-8 header message, the third 378 part of the multipart/report contains the returned content (message/ 379 global) or header (message/global-headers), same as for DSNs. The 380 second part of the multipart/report uses a new media type, message/ 381 global-disposition-notification, which has the syntax of message/ 382 disposition-notification with two modifications. First, the charset 383 for message/global-disposition-notification is UTF-8, and thus any 384 field MAY contain UTF-8 characters when appropriate (see the ABNF 385 below). (In particular, the failure-field, the error-field, and the 386 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 387 language [RFC2277].) Second, systems generating a message/ 388 global-disposition-notification body part (typically a mail user 389 agent) SHOULD use the UTF-8 address type for all addresses containing 390 characters outside the US-ASCII repertoire. 392 The MDN specification also defines the Original-Recipient header 393 field, which is added with a copy of the contents of ORCPT at 394 delivery time. When generating an Original-Recipient header field, a 395 delivery agent writing a UTF-8 header message in native format SHOULD 396 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 397 UTF-8 address type in the ORCPT parameter to the corresponding utf-8- 398 address form. 400 The MDN specification also defines the Disposition-Notification-To 401 header field, which is an address header field and thus follows the 402 same 8-bit rules as other address header fields such as "From" and 403 "To" when used in a UTF-8 header message. 405 ; ABNF for "original-recipient-header", "original-recipient-field", 406 ; and "final-recipient-field" from RFC 3798 is implicitly updated 407 ; as they use the updated "generic-address" as defined in 408 ; Section 4 of this document. 410 failure-field = "Failure" ":" *utf8-text 411 ; "utf8-text" is defined in Section 4 of this document. 413 error-field = "Error" ":" *utf8-text 414 ; "utf8-text" is defined in Section 4 of this document. 416 warning-field = "Warning" ":" *utf8-text 417 ; "utf8-text" is defined in Section 4 of this document. 419 6. IANA Considerations 421 This specification does not create any new IANA registries. However, 422 the following items are registered as a result of this document. 424 6.1. UTF-8 Mail Address Type Registration 426 The mail address type registry was created by [RFC3464]. The 427 registration template response follows: 429 (a) The proposed address-type name. 431 UTF-8 433 (b) The syntax for mailbox addresses of this type, specified using 434 BNF, regular expressions, ASN.1, or other non-ambiguous language. 436 See Section 3. 438 (c) If addresses of this type are not composed entirely of graphic 439 characters from the US-ASCII repertoire, a specification for how 440 they are to be encoded as graphic US-ASCII characters in a DSN 441 Original-Recipient or Final-Recipient DSN field. 443 This address type has 3 forms (as defined in Section 3): utf-8- 444 addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the 445 first form is 7-bit safe. 447 The utf-8-address form MUST NOT be used: 449 1. in the ORCPT parameter when the SMTP server doesn't advertise 450 support for UTF8SMTP; 452 2. or the SMTP server supports UTF8SMTP, but the address contains 453 US-ASCII characters not permitted in the ORCPT parameter (e.g., 454 the ORCPT parameter forbids SP and the = characters); 456 3. or in a 7-bit transport environment including a message/ 457 delivery-status Original-Recipient or Final-Recipient field. 459 The utf-8-addr-xtext form MUST be used instead in the first and the 460 third case; the utf-8-addr-unitext form MUST be used in the second 461 case. 462 The utf-8-address form MAY be used in the ORCPT parameter when the 463 SMTP server also advertises support for UTF8SMTP and the address 464 doesn't contain any US-ASCII characters not permitted in the ORCPT 465 parameter; in a message/global-delivery-status Original-Recipient or 466 Final-Recipient DSN field; or in an Original-Recipient header field 468 [RFC3798] if the message is a UTF8SMTP message. 470 In addition, the utf-8-addr-unitext form can be used anywhere where 471 the utf-8-address form is allowed. 473 6.2. Update to 'smtp' Diagnostic Type Registration 475 The mail diagnostic type registry was created by [RFC3464] and 476 updated by [RFC5337]. The registration for the 'smtp' diagnostic 477 type should be updated to reference RFC XXXX in addition to [RFC3464] 478 and [RFC5337]. 480 When the 'smtp' diagnostic type is used in the context of a message/ 481 delivery-status body part, it remains as presently defined. When the 482 'smtp' diagnostic type is used in the context of a message/ 483 global-delivery-status body part, the codes remain the same, but the 484 text portion MAY contain UTF-8 characters. 486 6.3. message/global-headers 488 Type name: message 490 Subtype name: global-headers 492 Required parameters: none 494 Optional parameters: none 496 Encoding considerations: This media type contains Internationalized 497 Email Headers [I-D.ietf-eai-rfc5335bis] with no message body. 498 Whenever possible, the 8-bit content transfer encoding SHOULD be 499 used. When this media type passes through a 7-bit-only SMTP 500 infrastructure it MAY be encoded with the base64 or quoted- 501 printable content transfer encoding. 503 Security considerations: See Section 7. 505 Interoperability considerations: It is important that this media 506 type is not converted to a charset other than UTF-8. As a result, 507 implementations MUST NOT include a charset parameter with this 508 media type. Although it might be possible to downconvert this 509 media type to the text/rfc822-header media type, such conversion 510 is discouraged as it loses information. 512 Published specification: RFC XXXX 513 Applications that use this media type: UTF8SMTP servers and email 514 clients that support multipart/report generation or parsing. 516 Additional information: 518 Magic number(s): none 520 File extension(s): In the event this is saved to a file, the 521 extension ".u8hdr" is suggested. 523 Macintosh file type code(s): The 'TEXT' type code is suggested as 524 files of this type are typically used for diagnostic purposes and 525 suitable for analysis in a UTF-8 aware text editor. A uniform 526 type identifier (UTI) of "public.utf8-email-message-header" is 527 suggested. This type conforms to "public.utf8-plain-text" and 528 "public.plain-text". 530 Person & email address to contact for further information: See the 531 Authors' Addresses section of this document. 533 Intended usage: COMMON 535 Restrictions on usage: This media type contains textual data in the 536 UTF-8 charset. It typically contains octets with the 8th bit set. 537 As a result, a transfer encoding is required when a 7-bit 538 transport is used. 540 Author: See the Authors' Addresses section of this document. 542 Change controller: IETF Standards Process 544 6.4. message/global-delivery-status 546 Type name: message 548 Subtype name: global-delivery-status 550 Required parameters: none 552 Optional parameters: none 554 Encoding considerations: This media type contains delivery status 555 notification attributes in the UTF-8 charset. The 8-bit content 556 transfer encoding MUST be used with this content-type, unless it 557 is sent over a 7-bit transport environment in which case quoted- 558 printable or base64 may be necessary. 560 Security considerations: See Section 7 562 Interoperability considerations: This media type provides 563 functionality similar to the message/delivery-status content-type 564 for email message return information. Clients of the previous 565 format will need to be upgraded to interpret the new format; 566 however, the new media type makes it simple to identify the 567 difference. 569 Published specification: RFC XXXX 571 Applications that use this media type: SMTP servers and email 572 clients that support delivery status notification generation or 573 parsing. 575 Additional information: 577 Magic number(s): none 579 File extension(s): The extension ".u8dsn" is suggested. 581 Macintosh file type code(s): A uniform type identifier (UTI) of 582 "public.utf8-email-message-delivery-status" is suggested. This 583 type conforms to "public.utf8-plain-text". 585 Person & email address to contact for further information: See the 586 Authors' Addresses section of this document. 588 Intended usage: COMMON 590 Restrictions on usage: This is expected to be the second part of a 591 multipart/report. 593 Author: See the Authors' Addresses section of this document. 595 Change controller: IETF Standards Process 597 6.5. message/global-disposition-notification 599 Type name: message 601 Subtype name: global-disposition-notification 603 Required parameters: none 604 Optional parameters: none 606 Encoding considerations: This media type contains disposition 607 notification attributes in the UTF-8 charset. The 8-bit content 608 transfer encoding MUST be used with this content-type, unless it 609 is sent over a 7-bit transport environment in which case quoted- 610 printable or base64 may be necessary. 612 Security considerations: See Section 7. 614 Interoperability considerations: This media type provides 615 functionality similar to the message/disposition-notification 616 content-type for email message disposition information. Clients 617 of the previous format will need to be upgraded to interpret the 618 new format; however, the new media type makes it simple to 619 identify the difference. 621 Published specification: RFC XXXX 623 Applications that use this media type: Email clients or servers that 624 support message disposition notification generation or parsing. 626 Additional information: 628 Magic number(s): none 630 File extension(s): The extension ".u8mdn" is suggested. 632 Macintosh file type code(s): A uniform type identifier (UTI) of 633 "public.utf8-email-message-disposition-notification" is suggested. 634 This type conforms to "public.utf8-plain-text". 636 Person & email address to contact for further information: See the 637 Authors' Addresses section of this document. 639 Intended usage: COMMON 641 Restrictions on usage: This is expected to be the second part of a 642 multipart/report. 644 Author: See the Authors' Addresses section of this document. 646 Change controller: IETF Standards Process 648 7. Security Considerations 650 Automated use of report types without authentication presents several 651 security issues. Forging negative reports presents the opportunity 652 for denial-of-service attacks when the reports are used for automated 653 maintenance of directories or mailing lists. Forging positive 654 reports may cause the sender to incorrectly believe a message was 655 delivered when it was not. 657 Malicious users can generate report structures designed to trigger 658 coding flaws in report parsers. Report parsers need to use secure 659 coding techniques to avoid the risk of buffer overflow or denial-of- 660 service attacks against parser coding mistakes. Code reviews of such 661 parsers are also recommended. 663 Malicious users of the email system regularly send messages with 664 forged envelope return paths, and these messages trigger delivery 665 status reports that result in a large amount of unwanted traffic on 666 the Internet. Many users choose to ignore delivery status 667 notifications because they are usually the result of "blowback" from 668 forged messages and thus never notice when messages they sent go 669 undelivered. As a result, support for correlation of delivery status 670 and message disposition notification messages with sent-messages has 671 become a critical feature of mail clients and possibly mail stores if 672 the email infrastructure is to remain reliable. In the short term, 673 simply correlating message-IDs may be sufficient to distinguish true 674 status notifications from those resulting from forged originator 675 addresses. But in the longer term, including cryptographic signature 676 material that can securely associate the status notification with the 677 original message is advisable. 679 As this specification permits UTF-8 in additional fields, the 680 security considerations of UTF-8 [RFC3629] apply. 682 8. References 684 8.1. Normative References 686 [RFC2119] Bradner, S., "Key words for use in RFCs to 687 Indicate Requirement Levels", BCP 14, 688 RFC 2119, March 1997. 690 [RFC2277] Alvestrand, H., "IETF Policy on Character 691 Sets and Languages", BCP 18, RFC 2277, 692 January 1998. 694 [RFC3461] Moore, K., "Simple Mail Transfer Protocol 695 (SMTP) Service Extension for Delivery 696 Status Notifications (DSNs)", RFC 3461, 697 January 2003. 699 [RFC3462] Vaudreuil, G., "The Multipart/Report 700 Content Type for the Reporting of Mail 701 System Administrative Messages", RFC 3462, 702 January 2003. 704 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible 705 Message Format for Delivery Status 706 Notifications", RFC 3464, January 2003. 708 [RFC3629] Yergeau, F., "UTF-8, a transformation 709 format of ISO 10646", STD 63, RFC 3629, 710 November 2003. 712 [RFC3798] Hansen, T. and G. Vaudreuil, "Message 713 Disposition Notification", RFC 3798, 714 May 2004. 716 [RFC5646] Phillips, A. and M. Davis, "Tags for 717 Identifying Languages", BCP 47, RFC 5646, 718 September 2009. 720 [RFC5321] Klensin, J., "Simple Mail Transfer 721 Protocol", RFC 5321, October 2008. 723 [RFC5322] Resnick, P., Ed., "Internet Message 724 Format", RFC 5322, October 2008. 726 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF 727 for Syntax Specifications: ABNF", STD 68, 728 RFC 5234, January 2008. 730 [I-D.ietf-eai-rfc5335bis] Yang, A. and S. Steele, "Internationalized 731 Email Headers", 732 draft-ietf-eai-rfc5335bis-10 (work in 733 progress), March 2011. 735 [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension for 736 Internationalized Email Address", 737 draft-ietf-eai-rfc5336bis-08 (work in 738 progress), March 2011. 740 8.2. Informative References 742 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose 743 Internet Mail Extensions (MIME) Part One: 745 Format of Internet Message Bodies", 746 RFC 2045, November 1996. 748 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose 749 Internet Mail Extensions (MIME) Part Two: 750 Media Types", RFC 2046, November 1996. 752 [RFC5337] Newman, C. and A. Melnikov, 753 "Internationalized Delivery Status and 754 Disposition Notifications", RFC 5337, 755 September 2008. 757 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading 758 Mechanism for Email Address 759 Internationalization", RFC 5504, 760 March 2009. 762 Appendix A. Changes Since ... 764 A.1. Changes Since -00 766 Incorporated changes from draft-ietf-eai-dsnbis-01. 768 Fixed description of utf-8-addr-xtext and utf-8-addr-unitext. 770 Other minor corrections. 772 Incorporated comments by Apps Area reviewers. 774 A.2. Changes Since RFC 5337 776 Made changes to move from Experimental to Standards Track. The most 777 significant was the removal of an embedded alternative ASCII address 778 within a utf-8-address. 780 ABNF changes and errata suggested by Alfred Hoenes. 782 Minor changes to MIME type references. 784 Other minor corrections. 786 Appendix B. Acknowledgements 788 Many thanks for input provided by Pete Resnick, James Galvin, Ned 789 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred 790 Hoenes, Kazunori Fujiwara, and members of the EAI WG to help solidify 791 this proposal. 793 Authors' Addresses 795 Tony Hansen (editor) 796 AT&T Laboratories 797 200 Laurel Ave. 798 Middletown, NJ 07748 799 USA 801 EMail: tony+eaidsn@maillennium.att.com 803 Chris Newman 804 Sun Microsystems 805 800 Royal Oaks 806 Monrovia, CA 91016-6347 807 US 809 EMail: chris.newman@oracle.com 811 Alexey Melnikov 812 Isode Ltd 813 5 Castle Business Village 814 36 Station Road 815 Hampton, Middlesex TW12 2BX 816 UK 818 EMail: Alexey.Melnikov@isode.com