idnits 2.17.1 draft-ietf-eai-rfc5337bis-dsn-06.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 (November 14, 2011) is 4544 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) ** Obsolete normative reference: RFC 3462 (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) -- Obsolete informational reference (is this intentional?): RFC 5337 (Obsoleted by RFC 6533) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 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 Oracle 6 (if approved) A. Melnikov 7 Intended status: Standards Track Isode Ltd 8 Expires: May 17, 2012 November 14, 2011 10 Internationalized Delivery Status and Disposition Notifications 11 draft-ietf-eai-rfc5337bis-dsn-06 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 May 17, 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 . . . . . . . . . . . . . 6 67 4.1. The message/global-delivery-status Media Type . . . . . . 6 68 4.2. The message/global Media Type . . . . . . . . . . . . . . 9 69 4.3. The message/global-headers Media Type . . . . . . . . . . 9 70 4.4. Using These Media Types with multipart/report . . . . . . 9 71 4.5. Additional Requirements on SMTP Servers . . . . . . . . . 9 72 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 10 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 11 75 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11 76 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 12 77 6.4. message/global-delivery-status . . . . . . . . . . . . . . 13 78 6.5. message/global-disposition-notification . . . . . . . . . 14 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 82 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Changes Since RFC 5337 . . . . . . . . . . . . . . . 18 84 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 86 1. Introduction 88 When an email message is transmitted using the UTF8SMTP 89 [I-D.ietf-eai-rfc5336bis] extension and Internationalized Email 90 Headers [I-D.ietf-eai-rfc5335bis], it is sometimes necessary to 91 return that message or generate a Message Disposition Notification 92 (MDN) [RFC3798]. As a message sent to multiple recipients can 93 generate a status and disposition notification for each recipient, it 94 is helpful if a client can correlate these notifications based on the 95 recipient address it provided; thus, preservation of the original 96 recipient is important. This specification describes how to preserve 97 the original recipient and updates the MDN and DSN formats to support 98 the new address types. 100 NOTE: While this specification updates the experimental versions of 101 this protocol by removing certain constructs (e.g., the ">" address syntax is no longer permitted), the name of the 103 Address Type "UTF-8" and the media type names message/global, 104 message/global-delivery-status and message/global-headers have not 105 been changed. 107 This specification is a revision of and replacement for [RFC5337]. 108 Section 6 of [I-D.ietf-eai-frmwrk-4952bis] describes the change in 109 approach between this specification and the previous version. 111 2. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 118 [RFC5234] notation including the core rules defined in Appendix B of 119 RFC 5234 [RFC5234] and the UTF-8 syntax rules in Section 4 of 120 [RFC3629]. 122 3. UTF-8 Address Type 124 An Extensible Message Format for Delivery Status Notifications 125 [RFC3464] defines the concept of an address type. The address format 126 introduced in Internationalized Email Headers 127 [I-D.ietf-eai-rfc5335bis] is a new address type. The syntax for the 128 new address type in the context of status notifications is specified 129 at the end of this section. 131 An SMTP [RFC5321] server that advertises both the UTF8SMTP extension 132 [I-D.ietf-eai-rfc5336bis] and the DSN extension [RFC3461] MUST accept 133 a UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 134 characters. This address type also includes a 7-bit encoding 135 suitable for use in a message/delivery-status body part or an ORCPT 136 parameter sent to an SMTP server that does not advertise UTF8SMTP. 138 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, 139 and utf-8-address. Only the first form is 7-bit safe (only uses US- 140 ASCII characters). 142 The utf-8-address form is only suitable for use in newly defined 143 protocols capable of native representation of 8-bit characters. That 144 is, the utf-8-address form MUST NOT be used: 146 1. in the ORCPT parameter when the SMTP server doesn't advertise 147 support for UTF8SMTP (utf-8-addr-xtext MUST be used instead); or 149 2. the SMTP server supports UTF8SMTP, but the address contains US- 150 ASCII characters not permitted in the ORCPT parameter (e.g., the 151 ORCPT parameter forbids unencoded SP and the = character), 152 (either utf-8-addr-unitext or utf-8-addr-xtext MUST be used 153 instead); or 155 3. in a 7-bit transport environment including a message/ 156 delivery-status Original-Recipient or Final-Recipient field, 157 (utf-8-addr-xtext MUST be used instead). 159 The utf-8-address form MAY be used in the ORCPT parameter when the 160 SMTP server also advertises support for UTF8SMTP and the address 161 doesn't contain any US-ASCII characters not permitted in the ORCPT 162 parameter. It SHOULD be used in a message/global-delivery-status 163 Original-Recipient or Final-Recipient DSN field, or in an Original- 164 Recipient header field [RFC3798] if the message is a UTF8SMTP 165 message. 167 In addition, the utf-8-addr-unitext form can be used anywhere where 168 the utf-8-address form is allowed. 170 When used in the ORCPT parameter, the UTF-8 address type requires 171 that US-ASCII CTLs, SP, \, +, and = be encoded using 'unitext' 172 encoding (see below). This is described by the utf-8-addr-xtext and 173 utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding 174 uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below) 175 for encoding any Unicode character outside of US-ASCII range, as well 176 as for encoding CTLs, SP, \, +, and =. HEXPOINT is 2 to 6 177 hexadecimal digits. This encoding avoids the need to use the xtext 178 encoding described in [RFC3461], as any US-ASCII characters that 179 needs to be escaped using xtext encoding never appear in any unitext 180 encoded string. When sending data to a UTF8SMTP capable server, 181 native UTF-8 characters SHOULD be used instead of the 182 EmbeddedUnicodeChar syntax described in details below. When sending 183 data to an SMTP server that does not advertise UTF8SMTP, then the 184 EmbeddedUnicodeChar syntax MUST be used instead of UTF-8. 186 When the ORCPT parameter is placed in a message/ 187 global-delivery-status Original-Recipient field, the 'utf-8-addr- 188 xtext' form of the UTF-8 address type SHOULD be converted to the 189 'utf-8-address' form (see the ABNF below) by removing the 'unitext' 190 encoding. However, if an address is labeled with the UTF-8 address 191 type but does not conform to utf-8 syntax, then it MUST be copied 192 into the message/global-delivery-status field without alteration. 194 The ability to encode characters with the EmbeddedUnicodeChar 195 encodings should be viewed as a transitional mechanism and avoided 196 when possible. It is hoped that as systems lacking support for 197 UTF8SMTP become less common over time, these encodings can eventually 198 be phased out. 200 In the ABNF below, all productions not defined in this document are 201 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 202 [RFC3464]. 204 utf-8-type-addr = "utf-8;" utf-8-enc-addr 206 utf-8-address = Mailbox 207 ; Mailbox as defined in [I-D.ietf-eai-rfc5336bis]. 209 utf-8-enc-addr = utf-8-addr-xtext / 210 utf-8-addr-unitext / 211 utf-8-address 213 utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar) 214 ; 7bit form of utf-8-addr-unitext. 215 ; Safe for use in the ORCPT [RFC3461] 216 ; parameter even when UTF8SMTP SMTP 217 ; extension is not advertised. 219 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 220 ; MUST follow utf-8-address ABNF when 221 ; dequoted. 222 ; Safe for using in the ORCPT [RFC3461] 223 ; parameter when UTF8SMTP SMTP extension 224 ; is also advertised. 226 QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e 227 ; US-ASCII printable characters except 228 ; CTLs, SP, '\', '+', '='. 230 QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4 231 ; US-ASCII printable characters except 232 ; CTLs, SP, '\', '+' and '=', plus 233 ; other Unicode characters encoded in UTF-8 235 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 236 ; starts with "\x" 238 HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" / 239 "2B" / "3D" / "7F" / ; all xtext-specials 240 "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 241 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 242 ( NZDHEXDIG 3(HEXDIG) ) / ; 4 digit forms excluding 243 ( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate 244 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 245 ( "10" 4*HEXDIG ) ; 6 digit forms 246 ; represents either "\" or a Unicode code point outside 247 ; the US-ASCII repertoire 249 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 250 ; HEXDIG excluding 0-7 251 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 252 ; HEXDIG excluding "0" 253 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 254 ; HEXDIG excluding "0" and "D" 256 4. UTF-8 Delivery Status Notifications 258 A traditional delivery status notification [RFC3464] comes in a 259 three-part multipart/report [RFC3462] container, where the first part 260 is human-readable text describing the error, the second part is a 261 7-bit-only message/delivery-status, and the optional third part is 262 used for content (message/rfc822) or header (text/rfc822-headers) 263 return. As the present standard DSN format does not permit the 264 return of undeliverable UTF8SMTP messages, three new media types are 265 needed. ([RFC5337] introduced experimental versions of these media 266 types.) 268 4.1. The message/global-delivery-status Media Type 270 The first type, message/global-delivery-status, has the syntax of 271 message/delivery-status with three modifications. First, the charset 272 for message/global-delivery-status is UTF-8, and thus any field MAY 273 contain UTF-8 characters when appropriate (see the ABNF below). In 274 particular, the Diagnostic-Code field MAY contain UTF-8 as described 275 in UTF8SMTP [I-D.ietf-eai-rfc5336bis]; the Diagnostic-Code field 276 SHOULD be in i-default language [RFC2277]. Second, systems 277 generating a message/global-delivery-status body part SHOULD use the 278 utf-8-address form of the UTF-8 address type for all addresses 279 containing characters outside the US-ASCII repertoire. These systems 280 SHOULD up-convert the utf-8-addr-xtext or the utf-8-addr-unitext form 281 of a UTF-8 address type in the ORCPT parameter to the utf-8-address 282 form of a UTF-8 address type in the Original-Recipient field. Third, 283 an optional field called Localized-Diagnostic is added. Each 284 instance includes a language tag [RFC5646] and contains text in the 285 specified language. This is equivalent to the text part of the 286 Diagnostic-Code field. All instances of Localized-Diagnostic MUST 287 use different language tags. The ABNF for message/ 288 global-delivery-status is specified below. 290 In the ABNF below, all productions not defined in this document are 291 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 292 [RFC3464]. Note that is the same as from 293 [RFC5322], but without . If or when RFC 5322 is updated to 294 disallow , this should become just . Also, if or 295 when RFC 5322 is updated to disallow control characters in , 296 this should become a reference to that update instead. 298 utf-8-delivery-status-content = per-message-fields 299 1*( CRLF utf-8-per-recipient-fields ) 300 ; "per-message-fields" remains unchanged from the definition 301 ; in RFC 3464, except for the "extension-field" 302 ; which is updated below. 304 utf-8-per-recipient-fields = 305 [ original-recipient-field CRLF ] 306 final-recipient-field CRLF 307 action-field CRLF 308 status-field CRLF 309 [ remote-mta-field CRLF ] 310 [ diagnostic-code-field CRLF 311 *(localized-diagnostic-text-field CRLF) ] 312 [ last-attempt-date-field CRLF ] 313 [ final-log-id-field CRLF ] 314 [ will-retry-until-field CRLF ] 315 *( extension-field CRLF ) 316 ; All fields except for "original-recipient-field", 317 ; "final-recipient-field", "diagnostic-code-field" 318 ; and "extension-field" remain unchanged from 319 ; the definition in RFC 3464. 321 generic-address =/ utf-8-enc-addr 322 ; Only allowed with the "utf-8" address-type. 323 ; Updates Section 3.2.3 of RFC3798 324 ; 325 ; This indirectly updates "original-recipient-field" 326 ; and "final-recipient-field" 328 diagnostic-code-field = 329 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed 331 localized-diagnostic-text-field = 332 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 333 ; "Language-Tag" is a language tag as defined in [RFC5646]. 335 extension-field =/ extension-field-name ":" *utf8-text 336 ; Updates Section 7 of RFC3798 338 text-fixed = %d1-9 / ; Any US-ASCII character except for NUL, 339 %d11 / ; CR and LF 340 %d12 / ; See note above about 341 %d14-127 343 utf8-text = text-fixed / UTF8-non-ascii 345 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 347 4.2. The message/global Media Type 349 The second type, used for returning the content, is message/global 350 which is similar to message/rfc822, except it contains a message with 351 UTF-8 headers. This media type is described in 352 [I-D.ietf-eai-rfc5335bis]. 354 4.3. The message/global-headers Media Type 356 The third type, used for returning the headers, is message/ 357 global-headers and contains only the UTF-8 header fields of a message 358 (all lines prior to the first blank line in a UTF8SMTP message). 359 Unlike message/global, this body part provides no difficulties for 360 the present infrastructure. 362 4.4. Using These Media Types with multipart/report 364 Note that as far as a multipart/report [RFC3462] container is 365 concerned, message/global-delivery-status, message/global, and 366 message/global-headers MUST be treated as equivalent to message/ 367 delivery-status, message/rfc822, and text/rfc822-headers. That is, 368 implementations processing multipart/report MUST expect any 369 combinations of the 6 media types mentioned above inside a multipart/ 370 report media type. 372 All three new types will typically use the "8bit" Content-Transfer- 373 Encoding. (In the event all content is 7-bit, the equivalent 374 traditional types for delivery status notifications MAY be used. For 375 example, if information in message/global-delivery-status part can be 376 represented without any loss of information as message/ 377 delivery-status, then the message/delivery-status body part may be 378 used.) Note that [I-D.ietf-eai-rfc5335bis] relaxed a restriction 379 from MIME [RFC2046] regarding the use of Content-Transfer-Encoding in 380 new "message" subtypes. This specification explicitly allows the use 381 of Content-Transfer-Encoding in message/global-headers and message/ 382 global-delivery-status. This is not believed to be problematic as 383 these new media types are intended primarily for use by newer systems 384 with full support for 8-bit MIME and UTF-8 headers. 386 4.5. Additional Requirements on SMTP Servers 388 If an SMTP server that advertises both UTF8SMTP and DSN needs to 389 return an undeliverable UTF8SMTP message, then it has two choices for 390 encapsulating the UTF8SMTP message when generating the corresponding 391 multipart/report: 393 If the return path SMTP server does not support UTF8SMTP, then the 394 undeliverable body part and headers MUST be encoded using a 7-bit 395 Content-Transfer-Encoding such as "base64" or "quoted-printable" 396 [RFC2045], as detailed in Section 4. 398 Otherwise, "8bit" Content-Transfer-Encoding can be used. 400 5. UTF-8 Message Disposition Notifications 402 Message Disposition Notifications [RFC3798] have a similar design and 403 structure to DSNs. As a result, they use the same basic return 404 format. When generating an MDN for a UTF-8 header message, the third 405 part of the multipart/report contains the returned content (message/ 406 global) or header (message/global-headers), same as for DSNs. The 407 second part of the multipart/report uses a new media type, message/ 408 global-disposition-notification, which has the syntax of message/ 409 disposition-notification with two modifications. First, the charset 410 for message/global-disposition-notification is UTF-8, and thus any 411 field MAY contain UTF-8 characters when appropriate (see the ABNF 412 below). (In particular, the failure-field, the error-field, and the 413 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 414 language [RFC2277].) Second, systems generating a message/ 415 global-disposition-notification body part (typically a mail user 416 agent) SHOULD use the UTF-8 address type for all addresses containing 417 characters outside the US-ASCII repertoire. 419 The MDN specification also defines the Original-Recipient header 420 field, which is added with a copy of the contents of ORCPT at 421 delivery time. When generating an Original-Recipient header field, a 422 delivery agent writing a UTF-8 header message in native format SHOULD 423 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 424 UTF-8 address type in the ORCPT parameter to the corresponding utf-8- 425 address form. 427 The MDN specification also defines the Disposition-Notification-To 428 header field, which is an address header field and thus follows the 429 same 8-bit rules as other address header fields such as "From" and 430 "To" when used in a UTF-8 header message. 432 ; ABNF for "original-recipient-header", "original-recipient-field", 433 ; and "final-recipient-field" from RFC 3798 is implicitly updated 434 ; as they use the updated "generic-address" as defined in 435 ; Section 4 of this document. 437 failure-field = "Failure" ":" *utf8-text 438 ; "utf8-text" is defined in Section 4 of this document. 440 error-field = "Error" ":" *utf8-text 441 ; "utf8-text" is defined in Section 4 of this document. 443 warning-field = "Warning" ":" *utf8-text 444 ; "utf8-text" is defined in Section 4 of this document. 446 6. IANA Considerations 448 This specification does not create any new IANA registries. However, 449 the following items are registered as a result of this document. 451 6.1. UTF-8 Mail Address Type Registration 453 The mail address type registry was created by [RFC3464]. The 454 registration template response follows: 456 (a) The proposed address-type name. 458 UTF-8 460 (b) The syntax for mailbox addresses of this type, specified using 461 BNF, regular expressions, ASN.1, or other non-ambiguous language. 463 See Section 3. 465 (c) If addresses of this type are not composed entirely of graphic 466 characters from the US-ASCII repertoire, a specification for how 467 they are to be encoded as graphic US-ASCII characters in a DSN 468 Original-Recipient or Final-Recipient DSN field. 470 This address type has 3 forms (as defined in Section 3): utf-8- 471 addr-xtext, utf-8-addr-unitext, and utf-8-address. Only the 472 first form is 7-bit safe. 474 6.2. Update to 'smtp' Diagnostic Type Registration 476 The mail diagnostic type registry was created by [RFC3464] and 477 updated by [RFC5337] and this specification. The registration for 478 the 'smtp' diagnostic type should be updated to reference RFC XXXX in 479 addition to [RFC3464] and [RFC5337]. 481 When the 'smtp' diagnostic type is used in the context of a message/ 482 delivery-status body part, it remains as presently defined. When the 483 'smtp' diagnostic type is used in the context of a message/ 484 global-delivery-status body part, the codes remain the same, but the 485 text portion MAY contain UTF-8 characters. 487 6.3. message/global-headers 489 Type name: message 491 Subtype name: global-headers 493 Required parameters: none 495 Optional parameters: none 497 Encoding considerations: This media type contains Internationalized 498 Email Headers [I-D.ietf-eai-rfc5335bis] with no message body. 499 Whenever possible, the 8-bit content transfer encoding SHOULD be 500 used. When this media type passes through a 7-bit-only SMTP 501 infrastructure it MAY be encoded with the base64 or quoted- 502 printable content transfer encoding. 504 Security considerations: See Section 7. 506 Interoperability considerations: It is important that this media 507 type is not converted to a charset other than UTF-8. As a result, 508 implementations MUST NOT include a charset parameter with this 509 media type. Although it might be possible to downconvert this 510 media type to the text/rfc822-header media type, such conversion 511 is discouraged as it loses information. 513 Published specification: RFC XXXX 515 Applications that use this media type: UTF8SMTP servers and email 516 clients that support multipart/report generation or parsing. 518 Additional information: 520 Magic number(s): none 522 File extension(s): In the event this is saved to a file, the 523 extension ".u8hdr" is suggested. 525 Macintosh file type code(s): The 'TEXT' type code is suggested as 526 files of this type are typically used for diagnostic purposes and 527 suitable for analysis in a UTF-8 aware text editor. A uniform 528 type identifier (UTI) of "public.utf8-email-message-header" is 529 suggested. This type conforms to "public.utf8-plain-text" and 530 "public.plain-text". 532 Person & email address to contact for further information: See the 533 Authors' Addresses section of this document. 535 Intended usage: COMMON 537 Restrictions on usage: This media type contains textual data in the 538 UTF-8 charset. It typically contains octets with the 8th bit set. 539 As a result, a transfer encoding is required when a 7-bit 540 transport is used. 542 Author: See the Authors' Addresses section of this document. 544 Change controller: IETF Standards Process 546 6.4. message/global-delivery-status 548 Type name: message 550 Subtype name: global-delivery-status 552 Required parameters: none 554 Optional parameters: none 556 Encoding considerations: This media type contains delivery status 557 notification attributes in the UTF-8 charset. The 8-bit content 558 transfer encoding MUST be used with this content-type, unless it 559 is sent over a 7-bit transport environment in which case quoted- 560 printable or base64 may be necessary. 562 Security considerations: See Section 7 564 Interoperability considerations: This media type provides 565 functionality similar to the message/delivery-status content-type 566 for email message return information. Clients of the previous 567 format will need to be upgraded to interpret the new format; 568 however, the new media type makes it simple to identify the 569 difference. 571 Published specification: RFC XXXX 573 Applications that use this media type: SMTP servers and email 574 clients that support delivery status notification generation or 575 parsing. 577 Additional information: 579 Magic number(s): none 581 File extension(s): The extension ".u8dsn" is suggested. 583 Macintosh file type code(s): A uniform type identifier (UTI) of 584 "public.utf8-email-message-delivery-status" is suggested. This 585 type conforms to "public.utf8-plain-text". 587 Person & email address to contact for further information: See the 588 Authors' Addresses section of this document. 590 Intended usage: COMMON 592 Restrictions on usage: This is expected to be the second part of a 593 multipart/report. 595 Author: See the Authors' Addresses section of this document. 597 Change controller: IETF Standards Process 599 6.5. message/global-disposition-notification 601 Type name: message 603 Subtype name: global-disposition-notification 605 Required parameters: none 607 Optional parameters: none 609 Encoding considerations: This media type contains disposition 610 notification attributes in the UTF-8 charset. The 8-bit content 611 transfer encoding MUST be used with this content-type, unless it 612 is sent over a 7-bit transport environment in which case quoted- 613 printable or base64 may be necessary. 615 Security considerations: See Section 7. 617 Interoperability considerations: This media type provides 618 functionality similar to the message/disposition-notification 619 content-type for email message disposition information. Clients 620 of the previous format will need to be upgraded to interpret the 621 new format; however, the new media type makes it simple to 622 identify the difference. 624 Published specification: RFC XXXX 626 Applications that use this media type: Email clients or servers that 627 support message disposition notification generation or parsing. 629 Additional information: 631 Magic number(s): none 633 File extension(s): The extension ".u8mdn" is suggested. 635 Macintosh file type code(s): A uniform type identifier (UTI) of 636 "public.utf8-email-message-disposition-notification" is suggested. 637 This type conforms to "public.utf8-plain-text". 639 Person & email address to contact for further information: See the 640 Authors' Addresses section of this document. 642 Intended usage: COMMON 644 Restrictions on usage: This is expected to be the second part of a 645 multipart/report. 647 Author: See the Authors' Addresses section of this document. 649 Change controller: IETF Standards Process 651 7. Security Considerations 653 Automated use of report types without authentication presents several 654 security issues. Forging negative reports presents the opportunity 655 for denial-of-service attacks when the reports are used for automated 656 maintenance of directories or mailing lists. Forging positive 657 reports may cause the sender to incorrectly believe a message was 658 delivered when it was not. 660 Malicious users can generate report structures designed to trigger 661 coding flaws in report parsers. Report parsers need to use secure 662 coding techniques to avoid the risk of buffer overflow or denial-of- 663 service attacks against parser coding mistakes. Code reviews of such 664 parsers are also recommended. 666 Malicious users of the email system regularly send messages with 667 forged envelope return paths, and these messages trigger delivery 668 status reports that result in a large amount of unwanted traffic on 669 the Internet. Many users choose to ignore delivery status 670 notifications because they are usually the result of "blowback" from 671 forged messages and thus never notice when messages they sent go 672 undelivered. As a result, support for correlation of delivery status 673 and message disposition notification messages with sent-messages has 674 become a critical feature of mail clients and possibly mail stores if 675 the email infrastructure is to remain reliable. In the short term, 676 simply correlating message-IDs may be sufficient to distinguish true 677 status notifications from those resulting from forged originator 678 addresses. But in the longer term, including cryptographic signature 679 material that can securely associate the status notification with the 680 original message is advisable. 682 As this specification permits UTF-8 in additional fields, the 683 security considerations of UTF-8 [RFC3629] apply. 685 8. References 687 8.1. Normative References 689 [RFC2119] Bradner, S., "Key words for use in 690 RFCs to Indicate Requirement Levels", 691 BCP 14, RFC 2119, March 1997. 693 [RFC2277] Alvestrand, H., "IETF Policy on 694 Character Sets and Languages", BCP 18, 695 RFC 2277, January 1998. 697 [RFC3461] Moore, K., "Simple Mail Transfer 698 Protocol (SMTP) Service Extension for 699 Delivery Status Notifications (DSNs)", 700 RFC 3461, January 2003. 702 [RFC3462] Vaudreuil, G., "The Multipart/Report 703 Content Type for the Reporting of Mail 704 System Administrative Messages", 705 RFC 3462, January 2003. 707 [RFC3464] Moore, K. and G. Vaudreuil, "An 708 Extensible Message Format for Delivery 709 Status Notifications", RFC 3464, 710 January 2003. 712 [RFC3629] Yergeau, F., "UTF-8, a transformation 713 format of ISO 10646", STD 63, 714 RFC 3629, November 2003. 716 [RFC3798] Hansen, T. and G. Vaudreuil, "Message 717 Disposition Notification", RFC 3798, 718 May 2004. 720 [RFC5646] Phillips, A. and M. Davis, "Tags for 721 Identifying Languages", BCP 47, 722 RFC 5646, September 2009. 724 [RFC5321] Klensin, J., "Simple Mail Transfer 725 Protocol", RFC 5321, October 2008. 727 [RFC5322] Resnick, P., Ed., "Internet Message 728 Format", RFC 5322, October 2008. 730 [RFC5234] Crocker, D. and P. Overell, "Augmented 731 BNF for Syntax Specifications: ABNF", 732 STD 68, RFC 5234, January 2008. 734 [I-D.ietf-eai-rfc5335bis] Yang, A., Steele, S., and N. Freed, 735 "Internationalized Email Headers", 736 draft-ietf-eai-rfc5335bis-13 (work in 737 progress), October 2011. 739 [I-D.ietf-eai-rfc5336bis] Yao, J. and W. MAO, "SMTP Extension 740 for Internationalized Email", 741 draft-ietf-eai-rfc5336bis-16 (work in 742 progress), November 2011. 744 [I-D.ietf-eai-frmwrk-4952bis] Klensin, J. and Y. Ko, "Overview and 745 Framework for Internationalized 746 Email", 747 draft-ietf-eai-frmwrk-4952bis-12 (work 748 in progress), October 2011. 750 8.2. Informative References 752 [RFC2045] Freed, N. and N. Borenstein, 753 "Multipurpose Internet Mail Extensions 754 (MIME) Part One: Format of Internet 755 Message Bodies", RFC 2045, 756 November 1996. 758 [RFC2046] Freed, N. and N. Borenstein, 759 "Multipurpose Internet Mail Extensions 760 (MIME) Part Two: Media Types", 761 RFC 2046, November 1996. 763 [RFC5337] Newman, C. and A. Melnikov, 764 "Internationalized Delivery Status and 765 Disposition Notifications", RFC 5337, 766 September 2008. 768 Appendix A. Changes Since RFC 5337 770 Made changes to move from Experimental to Standards Track. The most 771 significant was the removal of an embedded alternative ASCII address 772 within a utf-8-address, and reflections of the ABNF changes in 773 [I-D.ietf-eai-rfc5336bis]. 775 Fixed description of utf-8-addr-xtext and utf-8-addr-unitext. 777 References to Downgrade and uMailbox removed/fixed. 779 ABNF changes and errata suggested by Alfred Hoenes. 781 Minor changes to MIME type references. 783 Other minor corrections. 785 Appendix B. Acknowledgements 787 Many thanks for input provided by Pete Resnick, James Galvin, Ned 788 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred 789 Hoenes, Kazunori Fujiwara, and members of the EAI WG to help solidify 790 this proposal. 792 Authors' Addresses 794 Tony Hansen (editor) 795 AT&T Laboratories 796 200 Laurel Ave. 797 Middletown, NJ 07748 798 USA 800 EMail: tony+eaidsn@maillennium.att.com 802 Chris Newman 803 Oracle 804 800 Royal Oaks 805 Monrovia, CA 91016-6347 806 US 808 EMail: chris.newman@oracle.com 809 Alexey Melnikov 810 Isode Ltd 811 5 Castle Business Village 812 36 Station Road 813 Hampton, Middlesex TW12 2BX 814 UK 816 EMail: Alexey.Melnikov@isode.com