idnits 2.17.1 draft-ietf-eai-rfc5337bis-dsn-00.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 (October 18, 2010) is 4939 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 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 2822 (Obsoleted by RFC 5322) ** Obsolete normative reference: RFC 3462 (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5336 (Obsoleted by RFC 6531) ** Obsolete normative reference: RFC 4646 (ref. 'LANGTAGS') (Obsoleted by RFC 5646) -- Obsolete informational reference (is this intentional?): RFC 5337 (Obsoleted by RFC 6533) Summary: 7 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 Sun Microsystems 6 (if approved) A. Melnikov 7 Intended status: Standards Track Isode Ltd 8 Expires: April 21, 2011 October 18, 2010 10 Internationalized Delivery Status and Disposition Notifications 11 draft-ietf-eai-rfc5337bis-dsn-00 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 April 21, 2011. 46 Copyright Notice 48 Copyright (c) 2010 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 . . . . . . . . . 9 68 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 10 71 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11 72 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 12 73 6.4. message/global-delivery-status . . . . . . . . . . . . . . 13 74 6.5. message/global-disposition-notification . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 78 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 79 Appendix A. Changes Since RFC 5337 . . . . . . . . . . . . . . . 17 80 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 17 82 1. Introduction 84 When an email message is transmitted using the UTF8SMTP [RFC5336] 85 extension and Internationalized Email Headers [RFC5335], it is 86 sometimes necessary to return that message or generate a Message 87 Disposition Notification (MDN) [RFC3798]. As a message sent to 88 multiple recipients can generate a status and disposition 89 notification for each recipient, it is helpful if a client can 90 correlate these notifications based on the recipient address it 91 provided; thus, preservation of the original recipient is important. 92 This specification describes how to preserve the original recipient 93 and updates the MDN and DSN formats to support the new address types. 95 NOTE: The only issue for which there is (as yet) no consensus yet is 96 whether to change the name of the Address Type from "UTF-8" to 97 something different, such as "UTF8", to reflect the fact that the 98 ">" address syntax is no longer permitted. 100 NOTE: There was discussion of whether to change the media type names 101 from message/global, message/global-delivery-status and message/ 102 global-headers to something else. The apparent consensus was to not 103 change those names. 105 2. Conventions Used in This Document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234] 112 notation including the core rules defined in Appendix B of RFC 5234 113 [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629]. 115 3. UTF-8 Address Type 117 An Extensible Message Format for Delivery Status Notifications 118 [RFC3464] defines the concept of an address type. The address format 119 introduced in Internationalized Email Headers [RFC5335] is a new 120 address type. The syntax for the new address type in the context of 121 status notifications is specified at the end of this section. 123 An SMTP [RFC2821] server that advertises both the UTF8SMTP extension 124 [RFC5336] and the DSN extension [RFC3461] MUST accept a UTF-8 address 125 type in the ORCPT parameter including 8-bit UTF-8 characters. This 126 address type also includes a 7-bit encoding suitable for use in a 127 message/delivery-status body part or an ORCPT parameter sent to an 128 SMTP server that does not advertise UTF8SMTP. 130 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, 131 and utf-8-address. The first 2 forms are 7-bit safe. 133 The utf-8-address form is only suitable for use in newly defined 134 protocols capable of native representation of 8-bit characters. That 135 is, the utf-8-address form MUST NOT be used in the ORCPT parameter 136 when the SMTP server doesn't advertise support for UTF8SMTP or the 137 SMTP server supports UTF8SMTP, but the address contains US-ASCII 138 characters not permitted in the ORCPT parameter (e.g., the ORCPT 139 parameter forbids unencoded SP and the = character), or in a 7-bit 140 transport environment including a message/delivery-status Original- 141 Recipient or Final-Recipient field. In the former case, the utf-8- 142 addr-xtext form (see below) MUST be used instead; in the latter case, 143 the utf-8-addr-unitext form MUST be used. The utf-8-address form MAY 144 be used in the ORCPT parameter when the SMTP server also advertises 145 support for UTF8SMTP and the address doesn't contain any US-ASCII 146 characters not permitted in the ORCPT parameter. It SHOULD be used 147 in a message/global-delivery-status Original-Recipient or Final- 148 Recipient DSN field, or in an Original-Recipient header field 149 [RFC3798] if the message is a UTF8SMTP message. 151 In addition, the utf-8-addr-unitext form can be used anywhere where 152 the utf-8-address form is allowed. 154 When using in the ORCPT parameter, the UTF-8 address type requires 155 that US-ASCII CTLs, SP, \, +, and = be encoded using xtext encoding 156 as described in [RFC3461]. This is described by the utf-8-addr-xtext 157 form in the ABNF below. Unicode characters MAY be included in a 158 UTF-8 address type using a "\x{HEXPOINT}" syntax 159 (EmbeddedUnicodeChar), where HEXPOINT is 2 to 6 hexadecimal digits. 160 When sending data to a UTF8SMTP-capable server, native UTF-8 161 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax 162 described in details below. When sending data to an SMTP server that 163 does not advertise UTF8SMTP, then the EmbeddedUnicodeChar syntax MUST 164 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 all xtext encoding 170 first (which will result in the utf-8-addr-unitext form), followed by 171 removal of the unitext encoding. However, if an address is labeled 172 with the UTF-8 address type but does not conform to utf-8 syntax, 173 then it MUST be copied into the message/global-delivery-status field 174 without alteration. 176 The ability to encode characters with the EmbeddedUnicodeChar 177 encodings should be viewed as a transitional mechanism. It is hoped 178 that as systems lacking support for UTF8SMTP become less common over 179 time, these encodings can eventually be phased out. 181 In the ABNF below, all productions not defined in this document are 182 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 183 [RFC3464]. 185 utf-8-type-addr = "utf-8;" utf-8-enc-addr 187 utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ] 188 ; uMailbox is defined in [RFC5336]. 189 ; Mailbox is defined in [RFC2821]. 191 utf-8-enc-addr = utf-8-addr-xtext / 192 utf-8-addr-unitext / 193 utf-8-address 195 utf-8-addr-xtext = xtext 196 ; xtext is defined in [RFC3461]. 197 ; When xtext encoding is removed, 198 ; the syntax MUST conform to 199 ; utf-8-addr-unitext. 201 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 202 ; MUST follow utf-8-address ABNF when 203 ; dequoted 205 QUCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e / 206 UTF8-2 / UTF8-3 / UTF8-4 207 ; US-ASCII printable characters except 208 ; CTLs, SP, '\', '+' and '=', plus 209 ; other Unicode characters in UTF-8 211 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 212 ; starts with "\x" 214 HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 215 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 216 ( NZDHEXDIG 3(HEXDIG) ) / 217 ( "D" %x30-37 2(HEXDIG) ) / 218 ; 4 digit forms excluding surrogate 219 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 220 ( "10" 4*HEXDIG ) ; 6 digit forms 221 ; represents either "\" or a Unicode code point outside the 222 ; US-ASCII repertoire 224 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 225 ; HEXDIG excluding 0-7 226 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 227 ; HEXDIG excluding "0" 228 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 229 ; HEXDIG excluding "0" and "D" 231 4. UTF-8 Delivery Status Notifications 233 A traditional delivery status notification [RFC3464] comes in a 234 three-part multipart/report [RFC3462] container, where the first part 235 is human-readable text describing the error, the second part is a 236 7-bit-only message/delivery-status, and the optional third part is 237 used for content (message/rfc822) or header (text/rfc822-headers) 238 return. As the present DSN format does not permit returning of 239 undeliverable UTF8SMTP messages, three new media types are needed. 241 The first type, message/global-delivery-status, has the syntax of 242 message/delivery-status with three modifications. First, the charset 243 for message/global-delivery-status is UTF-8, and thus any field MAY 244 contain UTF-8 characters when appropriate (see the ABNF below). In 245 particular, the Diagnostic-Code field MAY contain UTF-8 as described 246 in UTF8SMTP [RFC5336]; the Diagnostic-Code field SHOULD be in 247 i-default language [DEFAULTLANG]. Second, systems generating a 248 message/global-delivery-status body part SHOULD use the utf-8-address 249 form of the UTF-8 address type for all addresses containing 250 characters outside the US-ASCII repertoire. These systems SHOULD up- 251 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 252 UTF-8 address type in the ORCPT parameter to the utf-8-address form 253 of a UTF-8 address type in the Original-Recipient field. Third, a 254 new optional field called Localized-Diagnostic is added. Each 255 instance includes a language tag [LANGTAGS] and contains text in the 256 specified language. This is equivalent to the text part of the 257 Diagnostic-Code field. All instances of Localized-Diagnostic MUST 258 use different language tags. The ABNF for message/ 259 global-delivery-status is specified below. 261 In the ABNF below, all productions not defined in this document are 262 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 263 [RFC3464]. 265 utf-8-delivery-status-content = per-message-fields 266 1*( CRLF utf-8-per-recipient-fields ) 267 ; "per-message-fields" remains unchanged from the definition 268 ; in RFC 3464, except for the "extension-field" 269 ; which is updated below. 271 utf-8-per-recipient-fields = 272 [ original-recipient-field CRLF ] 273 final-recipient-field CRLF 274 action-field CRLF 275 status-field CRLF 276 [ remote-mta-field CRLF ] 277 [ diagnostic-code-field CRLF 278 *(localized-diagnostic-text-field CRLF) ] 280 [ last-attempt-date-field CRLF ] 281 [ will-retry-until-field CRLF ] 282 *( extension-field CRLF ) 283 ; All fields except for "original-recipient-field", 284 ; "final-recipient-field", "diagnostic-code-field" 285 ; and "extension-field" remain unchanged from 286 ; the definition in RFC 3464. 288 generic-address =/ utf-8-enc-addr 289 ; Only allowed with the "utf-8" address-type. 290 ; 291 ; This indirectly updates "original-recipient-field" 292 ; and "final-recipient-field" 294 diagnostic-code-field = 295 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed 297 localized-diagnostic-text-field = 298 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 299 ; "Language-Tag" is a language tag as defined in [LANGTAGS]. 301 extension-field =/ extension-field-name ":" *utf8-text 303 text-fixed = %d1-9 / ; Any US-ASCII character except for NUL, 304 %d11 / ; CR and LF 305 %d12 / 306 %d14-127 307 ; Same as from [RFC2822], but without . 308 ; If/when RFC 2822 is updated to disallow , 309 ; this should become just 310 ; Also, if/when RFC 2822 is updated to disallow control characters 311 ; this should become a reference to RFC 2822upd instead. 313 utf8-text = text-fixed / UTF8-non-ascii 315 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 317 The second type, used for returning the content, is message/global 318 which is similar to message/rfc822, except it contains a message with 319 UTF-8 headers. This media type is described in [RFC5335]. 321 The third type, used for returning the headers, is message/ 322 global-headers and contains only the UTF-8 header fields of a message 323 (all lines prior to the first blank line in a UTF8SMTP message). 324 Unlike message/global, this body part provides no difficulties for 325 the present infrastructure. 327 Note that as far as multipart/report [RFC3462] container is 328 concerned, message/global-delivery-status, message/global, and 329 message/global-headers MUST be treated as equivalent to message/ 330 delivery-status, message/rfc822, and text/rfc822-headers. That is, 331 implementations processing multipart/report MUST expect any 332 combinations of the 6 media types mentioned above inside a multipart/ 333 report media type. 335 All three new types will typically use the "8bit" Content-Transfer- 336 Encoding. (In the event all content is 7-bit, the equivalent 337 traditional types for delivery status notifications MAY be used. For 338 example, if information in message/global-delivery-status part can be 339 represented without any loss of information as message/ 340 delivery-status, then the message/delivery-status body part may be 341 used.) Note that [RFC5335] relaxed restriction from MIME [RFC2046] 342 regarding use of Content-Transfer-Encoding in new "message" subtypes. 343 This specification explicitly allows use of Content-Transfer-Encoding 344 in message/global-headers and message/global-delivery-status. This 345 is not believed to be problematic as these new media types are 346 intended primarily for use by newer systems with full support for 347 8-bit MIME and UTF-8 headers. 349 4.1. Additional Requirements on SMTP Servers 351 If an SMTP server that advertises both UTF8SMTP and DSN needs to 352 return an undeliverable UTF8SMTP message, then it MUST NOT downgrade 353 [DOWNGRADE] the UTF8SMTP message when generating the corresponding 354 multipart/report. If the return path SMTP server does not support 355 UTF8SMTP, then the undeliverable body part and headers MUST be 356 encoded using a 7-bit Content-Transfer-Encoding such as "base64" or 357 "quoted-printable" [RFC2045], as detailed in Section 4. Otherwise, 358 "8bit" Content-Transfer-Encoding can be used. 360 5. UTF-8 Message Disposition Notifications 362 Message Disposition Notifications [RFC3798] have a similar design and 363 structure to DSNs. As a result, they use the same basic return 364 format. When generating an MDN for a UTF-8 header message, the third 365 part of the multipart/report contains the returned content (message/ 366 global) or header (message/global-headers), same as for DSNs. The 367 second part of the multipart/report uses a new media type, message/ 368 global-disposition-notification, which has the syntax of message/ 369 disposition-notification with two modifications. First, the charset 370 for message/global-disposition-notification is UTF-8, and thus any 371 field MAY contain UTF-8 characters when appropriate (see the ABNF 372 below). (In particular, the failure-field, the error-field, and the 373 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 374 language [DEFAULTLANG].) Second, systems generating a message/ 375 global-disposition-notification body part (typically a mail user 376 agent) SHOULD use the UTF-8 address type for all addresses containing 377 characters outside the US-ASCII repertoire. 379 The MDN specification also defines the Original-Recipient header 380 field, which is added with a copy of the contents of ORCPT at 381 delivery time. When generating an Original-Recipient header field, a 382 delivery agent writing a UTF-8 header message in native format SHOULD 383 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 384 UTF-8 address type in the ORCPT parameter to the corresponding utf-8- 385 address form. 387 The MDN specification also defines the Disposition-Notification-To 388 header field, which is an address header field and thus follows the 389 same 8-bit rules as other address headers such as "From" and "To" 390 when used in a UTF-8 header message. 392 ; ABNF for "original-recipient-header", "original-recipient-field", 393 ; and "final-recipient-field" from RFC 3798 is implicitly updated 394 ; as they use the updated "generic-address" as defined in 395 ; Section 4 of this document. 397 failure-field = "Failure" ":" *utf8-text 398 ; "utf8-text" is defined in Section 4 of this document. 400 error-field = "Error" ":" *utf8-text 401 ; "utf8-text" is defined in Section 4 of this document. 403 warning-field = "Warning" ":" *utf8-text 404 ; "utf8-text" is defined in Section 4 of this document. 406 6. IANA Considerations 408 This specification does not create any new IANA registries. However, 409 the following items have been registered as a result of this 410 document. 412 6.1. UTF-8 Mail Address Type Registration 414 The mail address type registry was created by [RFC3464]. The 415 registration template response follows: 417 (a) The proposed address-type name. 419 UTF-8 421 (b) The syntax for mailbox addresses of this type, specified using 422 BNF, regular expressions, ASN.1, or other non-ambiguous language. 424 See Section 3. 426 (c) If addresses of this type are not composed entirely of graphic 427 characters from the US-ASCII repertoire, a specification for how 428 they are to be encoded as graphic US-ASCII characters in a DSN 429 Original-Recipient or Final-Recipient DSN field. 431 This address type has 3 forms (as defined in Section 3): utf-8- 432 addr-xtext, utf-8-addr-unitext, and utf-8-address. The first 2 433 forms are 7-bit safe. 435 The utf-8-address form MUST NOT be used 437 1. in the ORCPT parameter when the SMTP server doesn't advertise 438 support for UTF8SMTP; 440 2. or the SMTP server supports UTF8SMTP, but the address contains 441 US-ASCII characters not permitted in the ORCPT parameter (e.g., 442 the ORCPT parameter forbids SP and the = characters); 444 3. or in a 7-bit transport environment including a message/ 445 delivery-status Original-Recipient or Final-Recipient field. 447 The utf-8-addr-xtext form MUST be used instead in the first case; the 448 utf-8-addr-unitext form MUST be used in the other two cases. The 449 utf-8-address form MAY be used in the ORCPT parameter when the SMTP 450 server also advertises support for UTF8SMTP and the address doesn't 451 contain any US-ASCII characters not permitted in the ORCPT parameter; 452 in a message/global-delivery-status Original-Recipient or Final- 453 Recipient DSN field; or in an Original-Recipient header field 454 [RFC3798] if the message is a UTF8SMTP message. 456 In addition, the utf-8-addr-unitext form can be used anywhere where 457 the utf-8-address form is allowed. 459 6.2. Update to 'smtp' Diagnostic Type Registration 461 The mail diagnostic type registry was created by [RFC3464] and 462 updated by [RFC5337]. The registration for the 'smtp' diagnostic 463 type should be updated to reference RFC XXXX in addition to [RFC3464] 464 and [RFC5337]. 466 When the 'smtp' diagnostic type is used in the context of a message/ 467 delivery-status body part, it remains as presently defined. When the 468 'smtp' diagnostic type is used in the context of a message/ 469 global-delivery-status body part, the codes remain the same, but the 470 text portion MAY contain UTF-8 characters. 472 6.3. message/global-headers 474 Type name: message 476 Subtype name: global-headers 478 Required parameters: none 480 Optional parameters: none 482 Encoding considerations: This media type contains Internationalized 483 Email Headers [RFC5335] with no message body. Whenever possible, 484 the 8-bit content transfer encoding SHOULD be used. When this 485 media type passes through a 7-bit-only SMTP infrastructure it MAY 486 be encoded with the base64 or quoted-printable content transfer 487 encoding. 489 Security considerations: See Section 7. 491 Interoperability considerations: It is important that this media 492 type is not converted to a charset other than UTF-8. As a result, 493 implementations MUST NOT include a charset parameter with this 494 media type. Although it might be possible to downconvert this 495 media type to the text/rfc822-header media type, such conversion 496 is discouraged as it loses information. 498 Published specification: RFC XXXX 500 Applications that use this media type: UTF8SMTP servers and email 501 clients that support multipart/report generation or parsing. 503 Additional information: 505 Magic number(s): none 507 File extension(s): In the event this is saved to a file, the 508 extension ".u8hdr" is suggested. 510 Macintosh file type code(s): The 'TEXT' type code is suggested as 511 files of this type are typically used for diagnostic purposes and 512 suitable for analysis in a UTF-8 aware text editor. A uniform 513 type identifier (UTI) of "public.utf8-email-message-header" is 514 suggested. This type conforms to "public.utf8-plain-text" and 515 "public.plain-text". 517 Person & email address to contact for further information: See the 518 Authors' Addresses section of this document. 520 Intended usage: COMMON 522 Restrictions on usage: This media type contains textual data in the 523 UTF-8 charset. It typically contains octets with the 8th bit set. 524 As a result, a transfer encoding is required when a 7-bit 525 transport is used. 527 Author: See the Authors' Addresses section of this document. 529 Change controller: IETF Standards Process 531 6.4. message/global-delivery-status 533 Type name: message 535 Subtype name: global-delivery-status 537 Required parameters: none 539 Optional parameters: none 541 Encoding considerations: This media type contains delivery status 542 notification attributes in the UTF-8 charset. The 8-bit content 543 transfer encoding MUST be used with this content-type, unless it 544 is sent over a 7-bit transport environment in which case quoted- 545 printable or base64 may be necessary. 547 Security considerations: See Section 7 549 Interoperability considerations: This media type provides 550 functionality similar to the message/delivery-status content-type 551 for email message return information. Clients of the previous 552 format will need to be upgraded to interpret the new format; 553 however, the new media type makes it simple to identify the 554 difference. 556 Published specification: RFC XXXX 558 Applications that use this media type: SMTP servers and email 559 clients that support delivery status notification generation or 560 parsing. 562 Additional information: 564 Magic number(s): none 566 File extension(s): The extension ".u8dsn" is suggested. 568 Macintosh file type code(s): A uniform type identifier (UTI) of 569 "public.utf8-email-message-delivery-status" is suggested. This 570 type conforms to "public.utf8-plain-text". 572 Person & email address to contact for further information: See the 573 Authors' Addresses section of this document. 575 Intended usage: COMMON 577 Restrictions on usage: This is expected to be the second part of a 578 multipart/report. 580 Author: See the Authors' Addresses section of this document. 582 Change controller: IETF Standards Process 584 6.5. message/global-disposition-notification 586 Type name: message 588 Subtype name: global-disposition-notification 590 Required parameters: none 592 Optional parameters: none 594 Encoding considerations: This media type contains disposition 595 notification attributes in the UTF-8 charset. The 8-bit content 596 transfer encoding MUST be used with this content-type, unless it 597 is sent over a 7-bit transport environment in which case quoted- 598 printable or base64 may be necessary. 600 Security considerations: See Section 7. 602 Interoperability considerations: This media type provides 603 functionality similar to the message/disposition-notification 604 content-type for email message disposition information. Clients 605 of the previous format will need to be upgraded to interpret the 606 new format; however, the new media type makes it simple to 607 identify the difference. 609 Published specification: RFC XXXX 611 Applications that use this media type: Email clients or servers that 612 support message disposition notification generation or parsing. 614 Additional information: 616 Magic number(s): none 618 File extension(s): The extension ".u8mdn" is suggested. 620 Macintosh file type code(s): A uniform type identifier (UTI) of 621 "public.utf8-email-message-disposition-notification" is suggested. 622 This type conforms to "public.utf8-plain-text". 624 Person & email address to contact for further information: See the 625 Authors' Addresses section of this document. 627 Intended usage: COMMON 629 Restrictions on usage: This is expected to be the second part of a 630 multipart/report. 632 Author: See the Authors' Addresses section of this document. 634 Change controller: IETF Standards Process 636 7. Security Considerations 638 Automated use of report types without authentication presents several 639 security issues. Forging negative reports presents the opportunity 640 for denial-of-service attacks when the reports are used for automated 641 maintenance of directories or mailing lists. Forging positive 642 reports may cause the sender to incorrectly believe a message was 643 delivered when it was not. 645 Malicious users can generate report structures designed to trigger 646 coding flaws in report parsers. Report parsers need to use secure 647 coding techniques to avoid the risk of buffer overflow or denial-of- 648 service attacks against parser coding mistakes. Code reviews of such 649 parsers are also recommended. 651 Malicious users of the email system regularly send messages with 652 forged envelope return paths, and these messages trigger delivery 653 status reports that result in a large amount of unwanted traffic on 654 the Internet. Many users choose to ignore delivery status 655 notifications because they are usually the result of "blowback" from 656 forged messages and thus never notice when messages they sent go 657 undelivered. As a result, support for correlation of delivery status 658 and message disposition notification messages with sent-messages has 659 become a critical feature of mail clients and possibly mail stores if 660 the email infrastructure is to remain reliable. In the short term, 661 simply correlating message-IDs may be sufficient to distinguish true 662 status notifications from those resulting from forged originator 663 addresses. But in the longer term, including cryptographic signature 664 material that can securely associate the status notification with the 665 original message is advisable. 667 As this specification permits UTF-8 in additional fields, the 668 security considerations of UTF-8 [RFC3629] apply. 670 8. References 672 8.1. Normative References 674 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 675 Requirement Levels", BCP 14, RFC 2119, March 1997. 677 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", 678 RFC 2821, April 2001. 680 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 681 April 2001. 683 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) 684 Service Extension for Delivery Status Notifications 685 (DSNs)", RFC 3461, January 2003. 687 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for 688 the Reporting of Mail System Administrative Messages", 689 RFC 3462, January 2003. 691 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message 692 Format for Delivery Status Notifications", RFC 3464, 693 January 2003. 695 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 696 10646", STD 63, RFC 3629, November 2003. 698 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 699 Notification", RFC 3798, May 2004. 701 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 702 Specifications: ABNF", STD 68, RFC 5234, January 2008. 704 [RFC5335] Yang, A., Ed., "Internationalized Email Headers", 705 RFC 5335, September 2008. 707 [RFC5336] Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for 708 Internationalized Email Addresses", RFC 5336, 709 September 2008. 711 [LANGTAGS] Phillips, A. and M. Davis, "Tags for Identifying 712 Languages", RFC 4646, September 2006. 714 [DEFAULTLANG] Alvestrand, H., "IETF Policy on Character Sets and 715 Languages", RFC 2277, January 1998. 717 8.2. Informative References 719 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet 720 Mail Extensions (MIME) Part One: Format of Internet 721 Message Bodies", RFC 2045, November 1996. 723 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet 724 Mail Extensions (MIME) Part Two: Media Types", 725 RFC 2046, November 1996. 727 [RFC5337] Newman, C. and A. Melnikov, "Internationalized 728 Delivery Status and Disposition Notifications", 729 RFC 5337, September 2008. 731 [DOWNGRADE] Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for 732 Email Address Internationalization", Work in Progress, 733 July 2008. 735 Appendix A. Changes Since RFC 5337 737 Made minor changes to move from Experimental to Standards Track. 739 Minor ABNF changes. 741 Minor changes to MIME type references. 743 Other minor corrections. 745 Appendix B. Acknowledgements 747 Many thanks for input provided by Pete Resnick, James Galvin, Ned 748 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, and 749 members of the EAI WG to help solidify this proposal. 751 Authors' Addresses 753 Tony Hansen (editor) 754 AT&T Laboratories 755 200 Laurel Ave. 756 Middletown, NJ 07748 757 USA 759 EMail: tony+eaidsn@maillennium.att.com 761 Chris Newman 762 Sun Microsystems 763 800 Royal Oaks 764 Monrovia, CA 91016-6347 765 US 767 EMail: chris.newman@sun.com 769 Alexey Melnikov 770 Isode Ltd 771 5 Castle Business Village 772 36 Station Road 773 Hampton, Middlesex TW12 2BX 774 UK 776 EMail: Alexey.Melnikov@isode.com