idnits 2.17.1 draft-ietf-eai-dsnbis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 mention this, which it should. -- 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 13, 2009) is 5402 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3462 (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) == Outdated reference: A later version (-12) exists of draft-ietf-eai-utf8headers-08 == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-10 ** Obsolete normative reference: RFC 4646 (ref. 'LANGTAGS') (Obsoleted by RFC 5646) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-05 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet-Draft Sun Microsystems 4 Obsoletes: 5337 (if approved) A. Melnikov, Ed. 5 Updates: 3461,3462,3464,3798 Isode Ltd 6 (if approved) July 13, 2009 7 Intended status: Experimental 8 Expires: January 14, 2010 10 Internationalized Delivery Status and Disposition Notifications 11 draft-ietf-eai-dsnbis-01.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 14, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 Delivery status notifications (DSNs) are critical to the correct 50 operation of an email system. However, the existing Draft Standards 51 (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text 52 in the machine-readable portions of the protocol. This specification 53 adds a new address type for international email addresses so an 54 original recipient address with non-US-ASCII characters can be 55 correctly preserved even after downgrading. This also provides 56 updated content return media types for delivery status notifications 57 and message disposition notifications to support use of the new 58 address type. 60 This document experimentally extends RFC 3461, RFC 3464, and RFC 61 3798. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 67 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3 68 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6 69 4.1. Additional Requirements on SMTP Servers . . . . . . . . . 8 70 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 8 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 10 73 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11 74 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 11 75 6.4. message/global-delivery-status . . . . . . . . . . . . . . 12 76 6.5. message/global-disposition-notification . . . . . . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 82 Appendix B. Changes from RFC 5337 . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 85 1. Introduction 87 When an email message is transmitted using the UTF8SMTP 88 [I-D.ietf-eai-smtpext] extension and Internationalized Email Headers 89 [I-D.ietf-eai-utf8headers], it is sometimes necessary to return that 90 message or generate a Message Disposition Notification (MDN) 91 [RFC3798]. As a message sent to multiple recipients can generate a 92 status and disposition notification for each recipient, it is helpful 93 if a client can correlate these notifications based on the recipient 94 address it provided; thus, preservation of the original recipient is 95 important. This specification describes how to preserve the original 96 recipient and updates the MDN and DSN formats to support the new 97 address types. 99 2. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 106 notation including the core rules defined in Appendix B of RFC 5234 107 [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629]. 109 3. UTF-8 Address Type 111 An Extensible Message Format for Delivery Status Notifications 112 [RFC3464] defines the concept of an address type. The address format 113 introduced in Internationalized Email Headers 114 [I-D.ietf-eai-utf8headers] is a new address type. The syntax for the 115 new address type in the context of status notifications is specified 116 at the end of this section. 118 An SMTP [RFC5321] server that advertises both the UTF8SMTP extension 119 [I-D.ietf-eai-smtpext] and the DSN extension [RFC3461] MUST accept a 120 UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 121 characters. This address type also includes a 7-bit encoding 122 suitable for use in a message/delivery-status body part or an ORCPT 123 parameter sent to an SMTP server that does not advertise UTF8SMTP. 125 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, 126 and utf-8-address. Only the first form is 7-bit safe. 128 The utf-8-address form is only suitable for use in newly defined 129 protocols capable of native representation of 8-bit characters. That 130 is, the utf-8-address form MUST NOT be used in the ORCPT parameter 131 when the SMTP server doesn't advertise support for UTF8SMTP, or the 132 SMTP server supports UTF8SMTP, but the address contains US-ASCII 133 characters not permitted in the ORCPT parameter (e.g., the ORCPT 134 parameter forbids unencoded SP and the = character), or in a 7-bit 135 transport environment including a message/delivery-status Original- 136 Recipient or Final-Recipient field. In the first and the third case 137 the utf-8-addr-xtext form (see below) MUST be used instead; in the 138 second case the utf-8-addr-unitext (or the utf-8-addr-xtext) form 139 MUST be used. The utf-8-address form MAY be used in the ORCPT 140 parameter when the SMTP server also advertises support for UTF8SMTP 141 and the address doesn't contain any US-ASCII characters not permitted 142 in the ORCPT parameter. It SHOULD be used in a message/ 143 global-delivery-status Original-Recipient or Final-Recipient DSN 144 field, or in an Original-Recipient header field [RFC3798] if the 145 message is a UTF8SMTP message. 147 In addition, the utf-8-addr-unitext form can be used anywhere where 148 the utf-8-address form is allowed. 150 When using in the ORCPT parameter, the UTF-8 address type requires 151 that US-ASCII CTLs, SP, \, +, and = be encoded using 'unitext' 152 encoding (see below). This is described by the utf-8-addr-xtext and 153 utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding 154 uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below) 155 for encoding any Unicode character outside of US-ASCII range, as well 156 as for encoding CTLs, SP, \, +, and =. HEXPOINT is 2 to 6 157 hexadecimal digits. This encoding avoids the need to use the xtext 158 encoding described in [RFC3461], as any US-ASCII characters that 159 needs to be escaped using xtext encoding never appear in any unitext 160 encoded string. When sending data to a UTF8SMTP capable server, 161 native UTF-8 characters SHOULD be used instead of the 162 EmbeddedUnicodeChar syntax described in details below. When sending 163 data to an SMTP server which does not advertise UTF8SMTP, then the 164 EmbeddedUnicodeChar syntax MUST be used instead of UTF-8. 166 When the ORCPT parameter is placed in a message/ 167 global-delivery-status Original-Recipient field, the utf-8-addr-xtext 168 form of the UTF-8 address type SHOULD be converted to the 'utf-8- 169 address' form (see the ABNF below) by removing the 'unitext' 170 encoding. However, if an address is labeled with the UTF-8 address 171 type but does not conform to utf-8 syntax, then it MUST be copied 172 into the message/global-delivery-status field without alteration. 174 The ability to encode characters with the EmbeddedUnicodeChar 175 encodings should be viewed as a transitional mechanism. It is hoped 176 that as systems lacking support for UTF8SMTP become less common over 177 time, these encodings can eventually be phased out. 179 In the ABNF below, all productions not defined in this document are 180 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 181 [RFC3464]. 183 utf-8-type-addr = "utf-8;" utf-8-enc-addr 185 utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ] 186 ; 'uMailbox' is defined in [I-D.ietf-eai-smtpext]. 187 ; 'Mailbox' is defined in [RFC5321]. 189 utf-8-enc-addr = utf-8-addr-xtext / 190 utf-8-addr-unitext / 191 utf-8-address 193 utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar) 194 ; 7bit form of utf-8-addr-unitext. 195 ; Safe for using in the ORCPT [RFC3461] 196 ; parameter even when UTF8SMTP SMTP 197 ; extension is not advertised. 199 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 200 ; MUST follow 'utf-8-address' ABNF when 201 ; dequoted. 202 ; Safe for using in the ORCPT [RFC3461] 203 ; parameter when UTF8SMTP SMTP extension 204 ; is also advertised. 206 QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e 207 ; US-ASCII printable characters except 208 ; CTLs, SP, '\', '+', '='. 210 QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4 211 ; US-ASCII printable characters except 212 ; CTLs, SP, '\', '+' and '=', 213 ; plus other Unicode characters 214 ; encoded in UTF-8 216 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 217 ; starts with "\x" 219 HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" / 220 "2B" / "3D" / "7F" / ;; all xtext-specials 221 "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 222 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 223 ( NZDHEXDIG 3(HEXDIG) ) / 224 ( "D" %x30-37 2(HEXDIG) ) / 225 ; 4 digit forms excluding surrogate 226 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 227 ( "10" 4*HEXDIG ) ; 6 digit forms 228 ; represents either "\" or a Unicode code point outside the 229 ; US-ASCII repertoire 231 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 232 ; HEXDIG excluding 0-7 233 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 234 ; HEXDIG excluding "0" 235 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 236 ; HEXDIG excluding "0" and "D" 238 4. UTF-8 Delivery Status Notifications 240 A traditional delivery status notification [RFC3464] comes in a 241 three-part multipart/report [RFC3462] container, where the first part 242 is human-readable text describing the error, the second part is a 243 7-bit-only message/delivery-status, and the optional third part is 244 used for content (message/rfc822) or header (text/rfc822-headers) 245 return. As the present DSN format does not permit returning of 246 undeliverable UTF8SMTP messages, three new media types are needed. 248 The first type, message/global-delivery-status, has the syntax of 249 message/delivery-status with three modifications. First, the charset 250 for message/global-delivery-status is UTF-8, and thus any field MAY 251 contain UTF-8 characters when appropriate (see the ABNF below). In 252 particular, the Diagnostic-Code field MAY contain UTF-8 as described 253 in UTF8SMTP [I-D.ietf-eai-smtpext]; the Diagnostic-Code field SHOULD 254 be in i-default language [DEFAULTLANG]. Second, systems generating a 255 message/global-delivery-status body part SHOULD use the utf-8-address 256 form of the UTF-8 address type for all addresses containing 257 characters outside the US-ASCII repertoire. These systems SHOULD up- 258 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 259 UTF-8 address type in the ORCPT parameter to the utf-8-address form 260 of a UTF-8 address type in the Original-Recipient field. Third, a 261 new optional field called Localized-Diagnostic is added. Each 262 instance includes a language tag [LANGTAGS] and contains text in the 263 specified language. This is equivalent to the text part of the 264 Diagnostic-Code field. All instances of Localized-Diagnostic MUST 265 use different language tags. The ABNF for message/ 266 global-delivery-status is specified below. 268 In the ABNF below, all productions not defined in this document are 269 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 270 [RFC3464]. 272 utf-8-delivery-status-content = per-message-fields 273 1*( CRLF utf-8-per-recipient-fields ) 275 ; "per-message-fields" remains unchanged from the definition 276 ; in RFC 3464, except for the "extension-field" 277 ; which is updated below. 279 utf-8-per-recipient-fields = 280 [ original-recipient-field CRLF ] 281 final-recipient-field CRLF 282 action-field CRLF 283 status-field CRLF 284 [ remote-mta-field CRLF ] 285 [ diagnostic-code-field CRLF 286 *(localized-diagnostic-text-field CRLF) ] 287 [ last-attempt-date-field CRLF ] 288 [ will-retry-until-field CRLF ] 289 *( extension-field CRLF ) 290 ; All fields except for "original-recipient-field", 291 ; "final-recipient-field", "diagnostic-code-field" 292 ; and "extension-field" remain unchanged from 293 ; the definition in RFC 3464. 295 generic-address =/ utf-8-enc-addr 296 ; Only allowed with the "utf-8" address-type. 297 ; 298 ; This indirectly updates "original-recipient-field" 299 ; and "final-recipient-field" 301 diagnostic-code-field = 302 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed 304 localized-diagnostic-text-field = 305 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 306 ; "Language-Tag" is a language tag as defined in [LANGTAGS]. 308 extension-field =/ extension-field-name ":" *utf8-text 310 text-fixed = %d1-9 / ; Any US-ASCII character except for NUL, 311 %d11 / ; CR and LF 312 %d12 / 313 %d14-127 314 ; Same as from [RFC5322], but without . 315 ; If/when RFC 2822 is updated to disallow , 316 ; this should become just 317 ; Also, if/when RFC 2822 is updated to disallow control characters 318 ; this should become a reference to RFC 2822upd instead. 320 utf8-text = text-fixed / UTF8-non-ascii 322 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 323 The second type, used for returning the content, is message/global 324 which is similar to message/rfc822, except it contains a message with 325 UTF-8 headers. This media type is described in 326 [I-D.ietf-eai-utf8headers]. 328 The third type, used for returning the headers, is message/ 329 global-headers and contains only the UTF-8 header fields of a message 330 (all lines prior to the first blank line in a UTF8SMTP message). 331 Unlike message/global, this body part provides no difficulties for 332 the present infrastructure. 334 Note that as far as multipart/report [RFC3462] container is 335 concerned, message/global-delivery-status, message/global, and 336 message/global-headers MUST be treated as equivalent to message/ 337 delivery-status, message/rfc822, and text/rfc822-headers. That is, 338 implementations processing multipart/report MUST expect any 339 combinations of the 6 media types mentioned above inside a multipart/ 340 report media type. 342 All three new types will typically use the "8bit" Content-Transfer- 343 Encoding. (In the event all content is 7-bit, the equivalent 344 traditional types for delivery status notifications MAY be used. For 345 example, if information in message/global-delivery-status part can be 346 represented without any loss of information as message/ 347 delivery-status, then the message/delivery-status body part may be 348 used.) Note that [I-D.ietf-eai-utf8headers] relaxed restriction from 349 MIME [RFC2046] regarding use of Content-Transfer-Encoding in new 350 "message" subtypes. This specification explicitly allows use of 351 Content-Transfer-Encoding in message/global-headers and message/ 352 global-delivery-status. This is not believed to be problematic as 353 these new media types are intended primarily for use by newer systems 354 with full support for 8-bit MIME and UTF-8 headers. 356 4.1. Additional Requirements on SMTP Servers 358 If an SMTP server that advertises both UTF8SMTP and DSN needs to 359 return an undeliverable UTF8SMTP message, then it MUST NOT downgrade 360 [I-D.ietf-eai-downgrade] the UTF8SMTP message when generating the 361 corresponding multipart/report. If the return path SMTP server does 362 not support UTF8SMTP, then the undeliverable body part and headers 363 MUST be encoded using a 7-bit Content-Transfer-Encoding such as 364 "base64" or "quoted-printable" [RFC2045], as detailed in Section 4. 365 Otherwise, "8bit" Content-Transfer-Encoding can be used. 367 5. UTF-8 Message Disposition Notifications 369 Message Disposition Notifications [RFC3798] have a similar design and 370 structure to DSNs. As a result, they use the same basic return 371 format. When generating an MDN for a UTF-8 header message, the third 372 part of the multipart/report contains the returned content (message/ 373 global) or header (message/global-headers), same as for DSNs. The 374 second part of the multipart/report uses a new media type, message/ 375 global-disposition-notification, which has the syntax of message/ 376 disposition-notification with two modifications. First, the charset 377 for message/global-disposition-notification is UTF-8, and thus any 378 field MAY contain UTF-8 characters when appropriate (see the ABNF 379 below). (In particular, the failure-field, the error-field, and the 380 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 381 language [DEFAULTLANG].) Second, systems generating a message/ 382 global-disposition-notification body part (typically a mail user 383 agent) SHOULD use the UTF-8 address type for all addresses containing 384 characters outside the US-ASCII repertoire. 386 The MDN specification also defines the Original-Recipient header 387 field, which is added with a copy of the contents of ORCPT at 388 delivery time. When generating an Original-Recipient header field, a 389 delivery agent writing a UTF-8 header message in native format SHOULD 390 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 391 UTF-8 address type in the ORCPT parameter to the corresponding utf-8- 392 address form. 394 The MDN specification also defines the Disposition-Notification-To 395 header field, which is an address header field and thus follows the 396 same 8-bit rules as other address header fields such as "From" and 397 "To" when used in a UTF-8 header message. 399 ; ABNF for "original-recipient-header", "original-recipient-field", 400 ; and "final-recipient-field" from RFC 3798 is implicitly updated 401 ; as they use the updated "generic-address" as defined in 402 ; Section 4 of this document. 404 failure-field = "Failure" ":" *utf8-text 405 ; "utf8-text" is defined in Section 4 of this document. 407 error-field = "Error" ":" *utf8-text 408 ; "utf8-text" is defined in Section 4 of this document. 410 warning-field = "Warning" ":" *utf8-text 411 ; "utf8-text" is defined in Section 4 of this document. 413 6. IANA Considerations 415 This specification does not create any new IANA registries. However, 416 the following items are registered as a result of this document. 418 6.1. UTF-8 Mail Address Type Registration 420 The mail address type registry was created by RFC 3464. The 421 registration template response follows: 423 (a) The proposed address-type name. 425 UTF-8 427 (b) The syntax for mailbox addresses of this type, specified using 428 BNF, regular expressions, ASN.1, or other non-ambiguous language. 430 See Section 3. 432 (c) If addresses of this type are not composed entirely of graphic 433 characters from the US-ASCII repertoire, a specification for how they 434 are to be encoded as graphic US-ASCII characters in a DSN Original- 435 Recipient or Final-Recipient DSN field. 437 This address type has 3 forms (as defined in Section 3): utf-8-addr- 438 xtext, utf-8-addr-unitext and utf-8-address. Only the first form is 439 7-bit safe. 441 The utf-8-address form MUST NOT be used 443 1. in the ORCPT parameter when the SMTP server doesn't advertise 444 support for UTF8SMTP; 446 2. or the SMTP server supports UTF8SMTP, but the address contains 447 US-ASCII characters not permitted in the ORCPT parameter (e.g., 448 the ORCPT parameter forbids SP and the = characters); 450 3. or in a 7-bit transport environment including a message/ 451 delivery-status Original-Recipient or Final-Recipient field. 453 The utf-8-addr-xtext form MUST be used instead in the first and the 454 third case; the utf-8-addr-unitext form MUST be used in the second 455 case. The utf-8-address form MAY be used in the ORCPT parameter when 456 the SMTP server also advertises support for UTF8SMTP and the address 457 doesn't contain any US-ASCII characters not permitted in the ORCPT 458 parameter; in a message/global-delivery-status Original-Recipient or 459 Final-Recipient DSN field; or in an Original-Recipient header field 460 [RFC3798] if the message is a UTF8SMTP message. 462 In addition, the utf-8-addr-unitext form can be used anywhere where 463 the utf-8-address form is allowed. 465 6.2. Update to 'smtp' Diagnostic Type Registration 467 The mail diagnostic type registry was created by RFC 3464. The 468 registration for the 'smtp' diagnostic type should be updated to 469 reference RFC XXXX in addition to RFC 3464. 471 When the 'smtp' diagnostic type is used in the context of a message/ 472 delivery-status body part, it remains as presently defined. When the 473 'smtp' diagnostic type is used in the context of a message/ 474 global-delivery-status body part, the codes remain the same, but the 475 text portion MAY contain UTF-8 characters. 477 6.3. message/global-headers 479 Type name: message 481 Subtype name: global-headers 483 Required parameters: none 485 Optional parameters: none 487 Encoding considerations: This media type contains Internationalized 488 Email Headers [I-D.ietf-eai-utf8headers] with no message body. 489 Whenever possible, the 8-bit content transfer encoding SHOULD be 490 used. When this media type passes through a 7-bit-only SMTP 491 infrastructure it MAY be encoded with the base64 or quoted- 492 printable content transfer encoding. 494 Security considerations: See Section 7. 496 Interoperability considerations: It is important that this media 497 type is not converted to a charset other than UTF-8. As a result, 498 implementations MUST NOT include a charset parameter with this 499 media type. Although it might be possible to downconvert this 500 media type to the text/rfc822-header media type, such conversion 501 is discouraged as it loses information. 503 Published specification: RFC XXXX 505 Applications that use this media type: UTF8SMTP servers and email 506 clients that support multipart/report generation or parsing. 508 Additional information: 510 Magic number(s): none 512 File extension(s): In the event this is saved to a file, the 513 extension ".u8hdr" is suggested. 515 Macintosh file type code(s): The 'TEXT' type code is suggested as 516 files of this type are typically used for diagnostic purposes and 517 suitable for analysis in a UTF-8 aware text editor. A uniform 518 type identifier (UTI) of "public.utf8-email-message-header" is 519 suggested. This type conforms to "public.utf8-plain-text" and 520 "public.plain-text". 522 Person & email address to contact for further information: See the 523 Authors' Addresses section of this document. 525 Intended usage: COMMON 527 Restrictions on usage: This media type contains textual data in the 528 UTF-8 charset. It typically contains octets with the 8th bit set. 529 As a result, a transfer encoding is required when a 7-bit 530 transport is used. 532 Author: See the Authors' Addresses section of this document. 534 Change controller: IETF Standards Process 536 6.4. message/global-delivery-status 538 Type name: message 540 Subtype name: global-delivery-status 542 Required parameters: none 544 Optional parameters: none 546 Encoding considerations: This media type contains delivery status 547 notification attributes in the UTF-8 charset. The 8-bit content 548 transfer encoding MUST be used with this content-type, unless it 549 is sent over a 7-bit transport environment in which case quoted- 550 printable or base64 may be necessary. 552 Security considerations: See Section 7 553 Interoperability considerations: This media type provides 554 functionality similar to the message/delivery-status content-type 555 for email message return information. Clients of the previous 556 format will need to be upgraded to interpret the new format; 557 however, the new media type makes it simple to identify the 558 difference. 560 Published specification: RFC XXXX 562 Applications that use this media type: SMTP servers and email 563 clients that support delivery status notification generation or 564 parsing. 566 Additional information: 568 Magic number(s): none 570 File extension(s): The extension ".u8dsn" is suggested. 572 Macintosh file type code(s): A uniform type identifier (UTI) of 573 "public.utf8-email-message-delivery-status" is suggested. This 574 type conforms to "public.utf8-plain-text". 576 Person & email address to contact for further information: See the 577 Authors' Addresses section of this document. 579 Intended usage: COMMON 581 Restrictions on usage: This is expected to be the second part of a 582 multipart/report. 584 Author: See the Authors' Addresses section of this document. 586 Change controller: IETF Standards Process 588 6.5. message/global-disposition-notification 590 Type name: message 592 Subtype name: global-disposition-notification 594 Required parameters: none 596 Optional parameters: none 597 Encoding considerations: This media type contains disposition 598 notification attributes in the UTF-8 charset. The 8-bit content 599 transfer encoding MUST be used with this content-type, unless it 600 is sent over a 7-bit transport environment in which case quoted- 601 printable or base64 may be necessary. 603 Security considerations: See Section 7. 605 Interoperability considerations: This media type provides 606 functionality similar to the message/disposition-notification 607 content-type for email message disposition information. Clients 608 of the previous format will need to be upgraded to interpret the 609 new format; however, the new media type makes it simple to 610 identify the difference. 612 Published specification: RFC XXXX 614 Applications that use this media type: Email clients or servers that 615 support message disposition notification generation or parsing. 617 Additional information: 619 Magic number(s): none 621 File extension(s): The extension ".u8mdn" is suggested. 623 Macintosh file type code(s): A uniform type identifier (UTI) of 624 "public.utf8-email-message-disposition-notification" is suggested. 625 This type conforms to "public.utf8-plain-text". 627 Person & email address to contact for further information: See the 628 Authors' Addresses section of this document. 630 Intended usage: COMMON 632 Restrictions on usage: This is expected to be the second part of a 633 multipart/report. 635 Author: See the Authors' Addresses section of this document. 637 Change controller: IETF Standards Process 639 7. Security Considerations 641 Automated use of report types without authentication presents several 642 security issues. Forging negative reports presents the opportunity 643 for denial-of-service attacks when the reports are used for automated 644 maintenance of directories or mailing lists. Forging positive 645 reports may cause the sender to incorrectly believe a message was 646 delivered when it was not. 648 Malicious users can generate report structures designed to trigger 649 coding flaws in report parsers. Report parsers need to use secure 650 coding techniques to avoid the risk of buffer overflow or denial-of- 651 service attacks against parser coding mistakes. Code reviews of such 652 parsers are also recommended. 654 Malicious users of the email system regularly send messages with 655 forged envelope return paths, and these messages trigger delivery 656 status reports that result in a large amount of unwanted traffic on 657 the Internet. Many users choose to ignore delivery status 658 notifications because they are usually the result of "blowback" from 659 forged messages and thus never notice when messages they sent go 660 undelivered. As a result, support for correlation of delivery status 661 and message disposition notification messages with sent-messages has 662 become a critical feature of mail clients and possibly mail stores if 663 the email infrastructure is to remain reliable. In the short term, 664 simply correlating message-IDs may be sufficient to distinguish true 665 status notifications from those resulting from forged originator 666 addresses. But in the longer term, including cryptographic signature 667 material that can securely associate the status notification with the 668 original message is advisable. 670 As this specification permits UTF-8 in additional fields, the 671 security considerations of UTF-8 [RFC3629] apply. 673 8. References 675 8.1. Normative References 677 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 678 Requirement Levels", BCP 14, RFC 2119, March 1997. 680 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 681 October 2008. 683 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 684 October 2008. 686 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 687 Extension for Delivery Status Notifications (DSNs)", 688 RFC 3461, January 2003. 690 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 691 Reporting of Mail System Administrative Messages", 692 RFC 3462, January 2003. 694 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 695 for Delivery Status Notifications", RFC 3464, 696 January 2003. 698 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 699 10646", STD 63, RFC 3629, November 2003. 701 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 702 Notification", RFC 3798, May 2004. 704 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 705 Specifications: ABNF", STD 68, RFC 5234, January 2008. 707 [I-D.ietf-eai-utf8headers] 708 Yang, A., "Internationalized Email Headers", 709 draft-ietf-eai-utf8headers-08 (work in progress), 710 April 2007. 712 [I-D.ietf-eai-smtpext] 713 Yao, J. and W. Mao, "SMTP extension for internationalized 714 email address", draft-ietf-eai-smtpext-10 (work in 715 progress), November 2007. 717 [LANGTAGS] 718 Phillips, A. and M. Davis, "Tags for Identifying 719 Languages", RFC 4646, September 2006. 721 [DEFAULTLANG] 722 Alvestrand, H., "IETF Policy on Character Sets and 723 Languages", RFC 2277, January 1998. 725 8.2. Informative References 727 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 728 Extensions (MIME) Part One: Format of Internet Message 729 Bodies", RFC 2045, November 1996. 731 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 732 Extensions (MIME) Part Two: Media Types", RFC 2046, 733 November 1996. 735 [I-D.ietf-eai-downgrade] 736 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 737 Email Address Internationalization (EAI)", 738 draft-ietf-eai-downgrade-05 (work in progress), Mar 2007. 740 Appendix A. Acknowledgements 742 Many thanks for input provided by Pete Resnick, James Galvin, Ned 743 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred 744 Hoenes, Kazunori Fujiwara and members of the EAI WG to help solidify 745 this proposal. 747 Appendix B. Changes from RFC 5337 749 Applied errata suggested by Alfred Hoenes. 751 Fixed ABNF and description of utf-8-addr-xtext and utf-8-addr- 752 unitext. 754 Authors' Addresses 756 Chris Newman 757 Sun Microsystems 758 800 Royal Oaks 759 Monrovia, CA 91016-6347 760 US 762 Email: chris.newman@sun.com 764 Alexey Melnikov (editor) 765 Isode Ltd 766 5 Castle Business Village 767 36 Station Road 768 Hampton, Middlesex TW12 2BX 769 UK 771 Email: Alexey.Melnikov@isode.com