idnits 2.17.1 draft-ietf-eai-rfc5337bis-dsn-03.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 (July 12, 2011) is 4664 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 370, but not defined == Unused Reference: 'RFC5504' is defined on line 825, but no explicit reference was found in the text ** 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-11 == Outdated reference: A later version (-16) exists of draft-ietf-eai-rfc5336bis-11 -- 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 (~~), 5 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: January 13, 2012 July 12, 2011 10 Internationalized Delivery Status and Disposition Notifications 11 draft-ietf-eai-rfc5337bis-dsn-03 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 January 13, 2012. 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 . . . . . . . . . . . . . 7 67 4.1. Additional Requirements on SMTP Servers . . . . . . . . . 10 68 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 11 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 12 71 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 13 72 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 14 73 6.4. message/global-delivery-status . . . . . . . . . . . . . . 15 74 6.5. message/global-disposition-notification . . . . . . . . . 16 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 79 Appendix A. Changes Since ... . . . . . . . . . . . . . . . . . . 19 80 A.1. Changes Since -00 . . . . . . . . . . . . . . . . . . . . 20 81 A.2. Changes Since RFC 5337 . . . . . . . . . . . . . . . . . . 20 82 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 20 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) 112 [RFC5234] notation including the core rules defined in Appendix B of 113 RFC 5234 [RFC5234] and the UTF-8 syntax rules in Section 4 of 114 [RFC3629]. 116 3. UTF-8 Address Type 118 An Extensible Message Format for Delivery Status Notifications 119 [RFC3464] defines the concept of an address type. The address format 120 introduced in Internationalized Email Headers 121 [I-D.ietf-eai-rfc5335bis] is a new address type. The syntax for the 122 new address type in the context of status notifications is specified 123 at the end of this section. 125 An SMTP [RFC5321] server that advertises both the UTF8SMTP extension 126 [I-D.ietf-eai-rfc5336bis] and the DSN extension [RFC3461] MUST accept 127 a UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 128 characters. This address type also includes a 7-bit encoding 129 suitable for use in a message/delivery-status body part or an ORCPT 130 parameter sent to an SMTP server that does not advertise UTF8SMTP. 132 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, 133 and utf-8-address. Only the first form is 7-bit safe. 135 The utf-8-address form is only suitable for use in newly defined 136 protocols capable of native representation of 8-bit characters. That 137 is, the utf-8-address form MUST NOT be used in the ORCPT parameter 138 when the SMTP server doesn't advertise support for UTF8SMTP, or the 139 SMTP server supports UTF8SMTP, but the address contains US-ASCII 140 characters not permitted in the ORCPT parameter (e.g., the ORCPT 141 parameter forbids unencoded SP and the = character), or in a 7-bit 142 transport environment including a message/delivery-status Original- 143 Recipient or Final-Recipient field. In the first and third case, the 144 utf-8-addr-xtext form (see below) MUST be used instead; in the second 145 case, either the utf-8-addr-unitext or the utf-8-addr-xtext form MUST 146 be used. The utf-8-address form MAY be used in the ORCPT parameter 147 when the SMTP server also advertises support for UTF8SMTP and the 148 address doesn't contain any US-ASCII characters not permitted in the 149 ORCPT parameter. It SHOULD be used in a message/ 150 global-delivery-status Original-Recipient or Final-Recipient DSN 151 field, or in an Original-Recipient header field [RFC3798] if the 152 message is a UTF8SMTP message. 154 In addition, the utf-8-addr-unitext form can be used anywhere where 155 the utf-8-address form is allowed. 157 When used in the ORCPT parameter, the UTF-8 address type requires 158 that US-ASCII CTLs, SP, \, +, and = be encoded using 'unitext' 159 encoding (see below). This is described by the utf-8-addr-xtext and 160 utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding 161 uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below) 162 for encoding any Unicode character outside of US-ASCII range, as well 163 as for encoding CTLs, SP, \, +, and =. HEXPOINT is 2 to 6 164 hexadecimal digits. This encoding avoids the need to use the xtext 165 encoding described in [RFC3461], as any US-ASCII characters that 166 needs to be escaped using xtext encoding never appear in any unitext 167 encoded string. When sending data to a UTF8SMTP capable server, 168 native UTF-8 characters SHOULD be used instead of the 169 EmbeddedUnicodeChar syntax described in details below. When sending 170 data to an SMTP server that does not advertise UTF8SMTP, then the 171 EmbeddedUnicodeChar syntax MUST be used instead of UTF-8. 173 When the ORCPT parameter is placed in a message/ 174 global-delivery-status Original-Recipient field, the 'utf-8-addr- 175 xtext' form of the UTF-8 address type SHOULD be converted to the 176 'utf-8-address' form (see the ABNF below) by removing the 'unitext' 177 encoding. However, if an address is labeled with the UTF-8 address 178 type but does not conform to utf-8 syntax, then it MUST be copied 179 into the message/global-delivery-status field without alteration. 181 The ability to encode characters with the EmbeddedUnicodeChar 182 encodings should be viewed as a transitional mechanism and avoided 183 when possible. It is hoped that as systems lacking support for 184 UTF8SMTP become less common over time, these encodings can eventually 185 be phased out. 187 In the ABNF below, all productions not defined in this document are 188 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 189 [RFC3464]. 191 utf-8-type-addr = "utf-8;" utf-8-enc-addr 193 utf-8-address = Mailbox 195 ; Mailbox as defined in [I-D.ietf-eai-rfc5336bis]. 197 utf-8-enc-addr = utf-8-addr-xtext / 199 utf-8-addr-unitext / 201 utf-8-address 203 utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar) 205 ; 7bit form of utf-8-addr-unitext. 207 ; Safe for use in the ORCPT [RFC3461] 209 ; parameter even when UTF8SMTP SMTP 211 ; extension is not advertised. 213 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 215 ; MUST follow utf-8-address ABNF when 217 ; dequoted. 219 ; Safe for using in the ORCPT [RFC3461] 220 ; parameter when UTF8SMTP SMTP extension 222 ; is also advertised. 224 QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e 226 ; US-ASCII printable characters except 228 ; CTLs, SP, '\', '+', '='. 230 QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4 232 ; US-ASCII printable characters except 234 ; CTLs, SP, '\', '+' and '=', plus 236 ; other Unicode characters encoded in UTF-8 238 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 240 ; starts with "\x" 242 HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" / 244 "2B" / "3D" / "7F" / ; all xtext-specials 246 "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 248 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 250 ( NZDHEXDIG 3(HEXDIG) ) / ; 4 digit forms excluding 252 ( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate 254 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 256 ( "10" 4*HEXDIG ) ; 6 digit forms 258 ; represents either "\" or a Unicode code point outside 259 ; the US-ASCII repertoire 261 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 263 ; HEXDIG excluding 0-7 265 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 267 ; HEXDIG excluding "0" 269 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 271 ; HEXDIG excluding "0" and "D" 273 4. UTF-8 Delivery Status Notifications 275 A traditional delivery status notification [RFC3464] comes in a 276 three-part multipart/report [RFC3462] container, where the first part 277 is human-readable text describing the error, the second part is a 278 7-bit-only message/delivery-status, and the optional third part is 279 used for content (message/rfc822) or header (text/rfc822-headers) 280 return. As the present DSN format does not permit returning of 281 undeliverable UTF8SMTP messages, three new media types are needed. 283 The first type, message/global-delivery-status, has the syntax of 284 message/delivery-status with three modifications. First, the charset 285 for message/global-delivery-status is UTF-8, and thus any field MAY 286 contain UTF-8 characters when appropriate (see the ABNF below). In 287 particular, the Diagnostic-Code field MAY contain UTF-8 as described 288 in UTF8SMTP [I-D.ietf-eai-rfc5336bis]; the Diagnostic-Code field 289 SHOULD be in i-default language [RFC2277]. Second, systems 290 generating a message/global-delivery-status body part SHOULD use the 291 utf-8-address form of the UTF-8 address type for all addresses 292 containing characters outside the US-ASCII repertoire. These systems 293 SHOULD up-convert the utf-8-addr-xtext or the utf-8-addr-unitext form 294 of a UTF-8 address type in the ORCPT parameter to the utf-8-address 295 form of a UTF-8 address type in the Original-Recipient field. Third, 296 a new optional field called Localized-Diagnostic is added. Each 297 instance includes a language tag [RFC5646] and contains text in the 298 specified language. This is equivalent to the text part of the 299 Diagnostic-Code field. All instances of Localized-Diagnostic MUST 300 use different language tags. The ABNF for message/ 301 global-delivery-status is specified below. 303 In the ABNF below, all productions not defined in this document are 304 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 305 [RFC3464]. Note that is the same as from 306 [RFC5322], but without . If or when RFC 5322 is updated to 307 disallow , this should become just Also, if or when 308 RFC 5322 is updated to disallow control characters in , this 309 should become a reference to that update instead. 311 utf-8-delivery-status-content = per-message-fields 313 1*( CRLF utf-8-per-recipient-fields ) 315 ; "per-message-fields" remains unchanged from the definition 317 ; in RFC 3464, except for the "extension-field" 319 ; which is updated below. 321 utf-8-per-recipient-fields = 323 [ original-recipient-field CRLF ] 325 final-recipient-field CRLF 327 action-field CRLF 329 status-field CRLF 331 [ remote-mta-field CRLF ] 333 [ diagnostic-code-field CRLF 335 *(localized-diagnostic-text-field CRLF) ] 337 [ last-attempt-date-field CRLF ] 339 [ will-retry-until-field CRLF ] 341 *( extension-field CRLF ) 343 ; All fields except for "original-recipient-field", 345 ; "final-recipient-field", "diagnostic-code-field" 347 ; and "extension-field" remain unchanged from 348 ; the definition in RFC 3464. 350 generic-address =/ utf-8-enc-addr 352 ; Only allowed with the "utf-8" address-type. 354 ; Updates Section 3.2.3 of RFC3798 356 ; 358 ; This indirectly updates "original-recipient-field" 360 ; and "final-recipient-field" 362 diagnostic-code-field = 364 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed 366 localized-diagnostic-text-field = 368 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 370 ; "Language-Tag" is a language tag as defined in [LANGTAGS]. 372 extension-field =/ extension-field-name ":" *utf8-text 374 ; Updates Section 7 of RFC3798 376 text-fixed = %d1-9 / ; Any US-ASCII character except for NUL, 378 %d11 / ; CR and LF 380 %d12 / ; See note above about 382 %d14-127 384 utf8-text = text-fixed / UTF8-non-ascii 386 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 388 The second type, used for returning the content, is message/global 389 which is similar to message/rfc822, except it contains a message with 390 UTF-8 headers. This media type is described in 391 [I-D.ietf-eai-rfc5335bis]. 393 The third type, used for returning the headers, is message/ 394 global-headers and contains only the UTF-8 header fields of a message 395 (all lines prior to the first blank line in a UTF8SMTP message). 396 Unlike message/global, this body part provides no difficulties for 397 the present infrastructure. 399 Note that as far as multipart/report [RFC3462] container is 400 concerned, message/global-delivery-status, message/global, and 401 message/global-headers MUST be treated as equivalent to message/ 402 delivery-status, message/rfc822, and text/rfc822-headers. That is, 403 implementations processing multipart/report MUST expect any 404 combinations of the 6 media types mentioned above inside a multipart/ 405 report media type. 407 All three new types will typically use the "8bit" Content-Transfer- 408 Encoding. (In the event all content is 7-bit, the equivalent 409 traditional types for delivery status notifications MAY be used. For 410 example, if information in message/global-delivery-status part can be 411 represented without any loss of information as message/ 412 delivery-status, then the message/delivery-status body part may be 413 used.) Note that [I-D.ietf-eai-rfc5335bis] relaxed restriction from 414 MIME [RFC2046] regarding use of Content-Transfer-Encoding in new 415 "message" subtypes. This specification explicitly allows use of 416 Content-Transfer-Encoding in message/global-headers and message/ 417 global-delivery-status. This is not believed to be problematic as 418 these new media types are intended primarily for use by newer systems 419 with full support for 8-bit MIME and UTF-8 headers. 421 4.1. Additional Requirements on SMTP Servers 423 If an SMTP server that advertises both UTF8SMTP and DSN needs to 424 return an undeliverable UTF8SMTP message, then it has two choices for 425 encapsulating the UTF8SMTP message when generating the corresponding 426 multipart/report: 428 If the return path SMTP server does not support UTF8SMTP, then the 429 undeliverable body part and headers MUST be encoded using a 7-bit 430 Content-Transfer-Encoding such as "base64" or "quoted-printable" 431 [RFC2045], as detailed in Section 4. 433 Otherwise, "8bit" Content-Transfer-Encoding can be used. 435 5. UTF-8 Message Disposition Notifications 437 Message Disposition Notifications [RFC3798] have a similar design and 438 structure to DSNs. As a result, they use the same basic return 439 format. When generating an MDN for a UTF-8 header message, the third 440 part of the multipart/report contains the returned content (message/ 441 global) or header (message/global-headers), same as for DSNs. The 442 second part of the multipart/report uses a new media type, message/ 443 global-disposition-notification, which has the syntax of message/ 444 disposition-notification with two modifications. First, the charset 445 for message/global-disposition-notification is UTF-8, and thus any 446 field MAY contain UTF-8 characters when appropriate (see the ABNF 447 below). (In particular, the failure-field, the error-field, and the 448 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 449 language [RFC2277].) Second, systems generating a message/ 450 global-disposition-notification body part (typically a mail user 451 agent) SHOULD use the UTF-8 address type for all addresses containing 452 characters outside the US-ASCII repertoire. 454 The MDN specification also defines the Original-Recipient header 455 field, which is added with a copy of the contents of ORCPT at 456 delivery time. When generating an Original-Recipient header field, a 457 delivery agent writing a UTF-8 header message in native format SHOULD 458 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 459 UTF-8 address type in the ORCPT parameter to the corresponding utf-8- 460 address form. 462 The MDN specification also defines the Disposition-Notification-To 463 header field, which is an address header field and thus follows the 464 same 8-bit rules as other address header fields such as "From" and 465 "To" when used in a UTF-8 header message. 467 ; ABNF for "original-recipient-header", "original-recipient-field", 469 ; and "final-recipient-field" from RFC 3798 is implicitly updated 471 ; as they use the updated "generic-address" as defined in 473 ; Section 4 of this document. 475 failure-field = "Failure" ":" *utf8-text 477 ; "utf8-text" is defined in Section 4 of this document. 479 error-field = "Error" ":" *utf8-text 481 ; "utf8-text" is defined in Section 4 of this document. 483 warning-field = "Warning" ":" *utf8-text 485 ; "utf8-text" is defined in Section 4 of this document. 487 6. IANA Considerations 489 This specification does not create any new IANA registries. However, 490 the following items are registered as a result of this document. 492 6.1. UTF-8 Mail Address Type Registration 494 The mail address type registry was created by [RFC3464]. The 495 registration template response follows: 497 (a) The proposed address-type name. 499 UTF-8 501 (b) The syntax for mailbox addresses of this type, specified using 502 BNF, regular expressions, ASN.1, or other non-ambiguous language. 504 See Section 3. 506 (c) If addresses of this type are not composed entirely of graphic 507 characters from the US-ASCII repertoire, a specification for how 508 they are to be encoded as graphic US-ASCII characters in a DSN 509 Original-Recipient or Final-Recipient DSN field. 511 This address type has 3 forms (as defined in Section 3): utf-8- 512 addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the 513 first form is 7-bit safe. 515 The utf-8-address form MUST NOT be used: 517 1. in the ORCPT parameter when the SMTP server doesn't advertise 518 support for UTF8SMTP; 520 2. or the SMTP server supports UTF8SMTP, but the address contains 521 US-ASCII characters not permitted in the ORCPT parameter (e.g., 522 the ORCPT parameter forbids SP and the = characters); 524 3. or in a 7-bit transport environment including a message/ 525 delivery-status Original-Recipient or Final-Recipient field. 527 The utf-8-addr-xtext form MUST be used instead in the first and the 528 third case; the utf-8-addr-unitext form MUST be used in the second 529 case. 530 The utf-8-address form MAY be used in the ORCPT parameter when the 531 SMTP server also advertises support for UTF8SMTP and the address 532 doesn't contain any US-ASCII characters not permitted in the ORCPT 533 parameter; in a message/global-delivery-status Original-Recipient or 534 Final-Recipient DSN field; or in an Original-Recipient header field 535 [RFC3798] if the message is a UTF8SMTP message. 537 In addition, the utf-8-addr-unitext form can be used anywhere where 538 the utf-8-address form is allowed. 540 6.2. Update to 'smtp' Diagnostic Type Registration 542 The mail diagnostic type registry was created by [RFC3464] and 543 updated by [RFC5337]. The registration for the 'smtp' diagnostic 544 type should be updated to reference RFC XXXX in addition to [RFC3464] 545 and [RFC5337]. 547 When the 'smtp' diagnostic type is used in the context of a message/ 548 delivery-status body part, it remains as presently defined. When the 549 'smtp' diagnostic type is used in the context of a message/ 550 global-delivery-status body part, the codes remain the same, but the 551 text portion MAY contain UTF-8 characters. 553 6.3. message/global-headers 555 Type name: message 557 Subtype name: global-headers 559 Required parameters: none 561 Optional parameters: none 563 Encoding considerations: This media type contains Internationalized 564 Email Headers [I-D.ietf-eai-rfc5335bis] with no message body. 565 Whenever possible, the 8-bit content transfer encoding SHOULD be 566 used. When this media type passes through a 7-bit-only SMTP 567 infrastructure it MAY be encoded with the base64 or quoted- 568 printable content transfer encoding. 570 Security considerations: See Section 7. 572 Interoperability considerations: It is important that this media 573 type is not converted to a charset other than UTF-8. As a result, 574 implementations MUST NOT include a charset parameter with this 575 media type. Although it might be possible to downconvert this 576 media type to the text/rfc822-header media type, such conversion 577 is discouraged as it loses information. 579 Published specification: RFC XXXX 581 Applications that use this media type: UTF8SMTP servers and email 582 clients that support multipart/report generation or parsing. 584 Additional information: 586 Magic number(s): none 588 File extension(s): In the event this is saved to a file, the 589 extension ".u8hdr" is suggested. 591 Macintosh file type code(s): The 'TEXT' type code is suggested as 592 files of this type are typically used for diagnostic purposes and 593 suitable for analysis in a UTF-8 aware text editor. A uniform 594 type identifier (UTI) of "public.utf8-email-message-header" is 595 suggested. This type conforms to "public.utf8-plain-text" and 596 "public.plain-text". 598 Person & email address to contact for further information: See the 599 Authors' Addresses section of this document. 601 Intended usage: COMMON 603 Restrictions on usage: This media type contains textual data in the 604 UTF-8 charset. It typically contains octets with the 8th bit set. 605 As a result, a transfer encoding is required when a 7-bit 606 transport is used. 608 Author: See the Authors' Addresses section of this document. 610 Change controller: IETF Standards Process 612 6.4. message/global-delivery-status 614 Type name: message 616 Subtype name: global-delivery-status 618 Required parameters: none 620 Optional parameters: none 622 Encoding considerations: This media type contains delivery status 623 notification attributes in the UTF-8 charset. The 8-bit content 624 transfer encoding MUST be used with this content-type, unless it 625 is sent over a 7-bit transport environment in which case quoted- 626 printable or base64 may be necessary. 628 Security considerations: See Section 7 630 Interoperability considerations: This media type provides 631 functionality similar to the message/delivery-status content-type 632 for email message return information. Clients of the previous 633 format will need to be upgraded to interpret the new format; 634 however, the new media type makes it simple to identify the 635 difference. 637 Published specification: RFC XXXX 639 Applications that use this media type: SMTP servers and email 640 clients that support delivery status notification generation or 641 parsing. 643 Additional information: 645 Magic number(s): none 647 File extension(s): The extension ".u8dsn" is suggested. 649 Macintosh file type code(s): A uniform type identifier (UTI) of 650 "public.utf8-email-message-delivery-status" is suggested. This 651 type conforms to "public.utf8-plain-text". 653 Person & email address to contact for further information: See the 654 Authors' Addresses section of this document. 656 Intended usage: COMMON 658 Restrictions on usage: This is expected to be the second part of a 659 multipart/report. 661 Author: See the Authors' Addresses section of this document. 663 Change controller: IETF Standards Process 665 6.5. message/global-disposition-notification 667 Type name: message 669 Subtype name: global-disposition-notification 671 Required parameters: none 673 Optional parameters: none 675 Encoding considerations: This media type contains disposition 676 notification attributes in the UTF-8 charset. The 8-bit content 677 transfer encoding MUST be used with this content-type, unless it 678 is sent over a 7-bit transport environment in which case quoted- 679 printable or base64 may be necessary. 681 Security considerations: See Section 7. 683 Interoperability considerations: This media type provides 684 functionality similar to the message/disposition-notification 685 content-type for email message disposition information. Clients 686 of the previous format will need to be upgraded to interpret the 687 new format; however, the new media type makes it simple to 688 identify the difference. 690 Published specification: RFC XXXX 692 Applications that use this media type: Email clients or servers that 693 support message disposition notification generation or parsing. 695 Additional information: 697 Magic number(s): none 699 File extension(s): The extension ".u8mdn" is suggested. 701 Macintosh file type code(s): A uniform type identifier (UTI) of 702 "public.utf8-email-message-disposition-notification" is suggested. 703 This type conforms to "public.utf8-plain-text". 705 Person & email address to contact for further information: See the 706 Authors' Addresses section of this document. 708 Intended usage: COMMON 710 Restrictions on usage: This is expected to be the second part of a 711 multipart/report. 713 Author: See the Authors' Addresses section of this document. 715 Change controller: IETF Standards Process 717 7. Security Considerations 719 Automated use of report types without authentication presents several 720 security issues. Forging negative reports presents the opportunity 721 for denial-of-service attacks when the reports are used for automated 722 maintenance of directories or mailing lists. Forging positive 723 reports may cause the sender to incorrectly believe a message was 724 delivered when it was not. 726 Malicious users can generate report structures designed to trigger 727 coding flaws in report parsers. Report parsers need to use secure 728 coding techniques to avoid the risk of buffer overflow or denial-of- 729 service attacks against parser coding mistakes. Code reviews of such 730 parsers are also recommended. 732 Malicious users of the email system regularly send messages with 733 forged envelope return paths, and these messages trigger delivery 734 status reports that result in a large amount of unwanted traffic on 735 the Internet. Many users choose to ignore delivery status 736 notifications because they are usually the result of "blowback" from 737 forged messages and thus never notice when messages they sent go 738 undelivered. As a result, support for correlation of delivery status 739 and message disposition notification messages with sent-messages has 740 become a critical feature of mail clients and possibly mail stores if 741 the email infrastructure is to remain reliable. In the short term, 742 simply correlating message-IDs may be sufficient to distinguish true 743 status notifications from those resulting from forged originator 744 addresses. But in the longer term, including cryptographic signature 745 material that can securely associate the status notification with the 746 original message is advisable. 748 As this specification permits UTF-8 in additional fields, the 749 security considerations of UTF-8 [RFC3629] apply. 751 8. References 753 8.1. Normative References 755 [RFC2119] Bradner, S., "Key words for use in RFCs to 756 Indicate Requirement Levels", BCP 14, 757 RFC 2119, March 1997. 759 [RFC2277] Alvestrand, H., "IETF Policy on Character 760 Sets and Languages", BCP 18, RFC 2277, 761 January 1998. 763 [RFC3461] Moore, K., "Simple Mail Transfer Protocol 764 (SMTP) Service Extension for Delivery 765 Status Notifications (DSNs)", RFC 3461, 766 January 2003. 768 [RFC3462] Vaudreuil, G., "The Multipart/Report 769 Content Type for the Reporting of Mail 770 System Administrative Messages", RFC 3462, 771 January 2003. 773 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible 774 Message Format for Delivery Status 775 Notifications", RFC 3464, January 2003. 777 [RFC3629] Yergeau, F., "UTF-8, a transformation 778 format of ISO 10646", STD 63, RFC 3629, 779 November 2003. 781 [RFC3798] Hansen, T. and G. Vaudreuil, "Message 782 Disposition Notification", RFC 3798, 783 May 2004. 785 [RFC5646] Phillips, A. and M. Davis, "Tags for 786 Identifying Languages", BCP 47, RFC 5646, 787 September 2009. 789 [RFC5321] Klensin, J., "Simple Mail Transfer 790 Protocol", RFC 5321, October 2008. 792 [RFC5322] Resnick, P., Ed., "Internet Message 793 Format", RFC 5322, October 2008. 795 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF 796 for Syntax Specifications: ABNF", STD 68, 797 RFC 5234, January 2008. 799 [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed, 800 "Internationalized Email Headers", 801 draft-ietf-eai-rfc5335bis-11 (work in 802 progress), July 2011. 804 [I-D.ietf-eai-rfc5336bis] Yao, J. and W. Mao, "SMTP Extension for 805 Internationalized Email", 806 draft-ietf-eai-rfc5336bis-11 (work in 807 progress), July 2011. 809 8.2. Informative References 811 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose 812 Internet Mail Extensions (MIME) Part One: 813 Format of Internet Message Bodies", 814 RFC 2045, November 1996. 816 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose 817 Internet Mail Extensions (MIME) Part Two: 818 Media Types", RFC 2046, November 1996. 820 [RFC5337] Newman, C. and A. Melnikov, 821 "Internationalized Delivery Status and 822 Disposition Notifications", RFC 5337, 823 September 2008. 825 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading 826 Mechanism for Email Address 827 Internationalization", RFC 5504, 828 March 2009. 830 Appendix A. Changes Since ... 832 A.1. Changes Since -00 834 NOTE TO RFC EDITOR: Remove this section for publication. 836 Incorporated changes from draft-ietf-eai-dsnbis-01. 838 Fixed description of utf-8-addr-xtext and utf-8-addr-unitext. 840 Other minor corrections. 842 Incorporated comments by Apps Area reviewers. 844 References to Downgrade and uMailbox removed/fixed. 846 A.2. Changes Since RFC 5337 848 Made changes to move from Experimental to Standards Track. The most 849 significant was the removal of an embedded alternative ASCII address 850 within a utf-8-address, and reflections of the ABNF changes in 851 [I-D.ietf-eai-rfc5336bis]. 853 ABNF changes and errata suggested by Alfred Hoenes. 855 Minor changes to MIME type references. 857 Other minor corrections. 859 Appendix B. Acknowledgements 861 Many thanks for input provided by Pete Resnick, James Galvin, Ned 862 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred 863 Hoenes, Kazunori Fujiwara, and members of the EAI WG to help solidify 864 this proposal. 866 Authors' Addresses 868 Tony Hansen (editor) 869 AT&T Laboratories 870 200 Laurel Ave. 871 Middletown, NJ 07748 872 USA 874 EMail: tony+eaidsn@maillennium.att.com 875 Chris Newman 876 Sun Microsystems 877 800 Royal Oaks 878 Monrovia, CA 91016-6347 879 US 881 EMail: chris.newman@oracle.com 883 Alexey Melnikov 884 Isode Ltd 885 5 Castle Business Village 886 36 Station Road 887 Hampton, Middlesex TW12 2BX 888 UK 890 EMail: Alexey.Melnikov@isode.com