idnits 2.17.1 draft-ietf-eai-dsn-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 825. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 849. 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 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 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 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 RFC3464, 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 (January 21, 2008) is 5940 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2821 (Obsoleted by RFC 5321) ** Obsolete normative reference: RFC 3462 (Obsoleted by RFC 6522) ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) ** Obsolete normative reference: RFC 4234 (Obsoleted by RFC 5234) == 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 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 Updates: 3461,3464,3798 A. Melnikov, Ed. 5 (if approved) Isode Ltd 6 Intended status: Experimental January 21, 2008 7 Expires: July 24, 2008 9 Internationalized Delivery Status and Disposition Notifications 10 draft-ietf-eai-dsn-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 24, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 Delivery status notifications (DSNs) are critical to the correct 44 operation of an email system. However, the existing draft standard 45 is presently limited to US-ASCII text in the machine readable 46 portions of the protocol. This specification adds a new address type 47 for international email addresses so an original recipient address 48 with non-US-ASCII characters can be correctly preserved even after 49 downgrading. This also provides updated content return media types 50 for delivery status notifications and message disposition 51 notifications to support use of the new address type. 53 This document experimentally extends RFC 3461, RFC 3464 and RFC 3798. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 59 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3 60 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6 61 4.1. Additional requirements on SMTP servers . . . . . . . . . 8 62 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 8 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 9 65 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 10 66 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 11 67 6.4. message/global-delivery-status . . . . . . . . . . . . . . 12 68 6.5. message/global-disposition-notification . . . . . . . . . 13 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 73 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 74 Appendix B. Changes from -05 . . . . . . . . . . . . . . . . . . 16 75 Appendix C. Changes from -04 . . . . . . . . . . . . . . . . . . 17 76 Appendix D. Changes from -03 . . . . . . . . . . . . . . . . . . 17 77 Appendix E. Changes from -02 . . . . . . . . . . . . . . . . . . 17 78 Appendix F. Changes from -01 . . . . . . . . . . . . . . . . . . 17 79 Appendix G. Changes from -00 . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 81 Intellectual Property and Copyright Statements . . . . . . . . . . 19 83 1. Introduction 85 When an email message is transmitted using the UTF8SMTP 86 [I-D.ietf-eai-smtpext] extension and Internationalized Email Headers 87 [I-D.ietf-eai-utf8headers], it is sometimes necessary to return that 88 message or generate a Message Disposition Notification [RFC3798] 89 (MDN). As a message sent to multiple recipients can generate a 90 status and disposition notification for each recipient, it is helpful 91 if a client can correlate these notifications based on the recipient 92 address it provided, thus preservation of the original recipient is 93 important. This specification describes how to preserve the original 94 recipient and updates the MDN and DSN formats to support the new 95 address types. 97 2. Conventions Used in this Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234] 104 notation including the core rules defined in Appendix B of RFC 4234 105 and the UTF-8 syntax rules in section 4 of [RFC3629]. 107 3. UTF-8 Address Type 109 An Extensible Message Format for Delivery Status Notifications 110 [RFC3464] defines the concept of an address type. The address format 111 introduced in Internationalized Email Headers 112 [I-D.ietf-eai-utf8headers] is a new address type. The syntax for the 113 new address type in the context of status notifications follows: 115 An SMTP [RFC2821] server which advertises both the UTF8SMTP extension 116 [I-D.ietf-eai-smtpext] and the DSN extension [RFC3461] MUST accept a 117 UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 118 characters. This address type also includes a 7-bit encoding 119 suitable for use in a message/delivery-status body part or an ORCPT 120 parameter sent to an SMTP server which does not advertise UTF8SMTP. 122 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext 123 and utf-8-address. The first 2 forms are 7-bit safe. 125 The utf-8-address form is only suitable for use in newly defined 126 protocols capable of native representation of 8-bit characters. I.e. 127 the utf-8-address form MUST NOT be used in the ORCPT parameter when 128 the SMTP server doesn't advertise support for UTF8SMTP or the SMTP 129 server supports UTF8SMTP, but the address contains US-ASCII 130 characters not permitted in the ORCPT parameter (e.g. the ORCPT 131 parameter forbids unencoded SP and the = character); or in a 7-bit 132 transport environment including a message/delivery-status Original- 133 Recipient or Final-Recipient field. In the former case the utf-8- 134 addr-xtext form (see below) MUST be used instead, in the latter case 135 the utf-8-addr-unitext form MUST be used. The utf-8-address form MAY 136 be used in the ORCPT parameter when the SMTP server also advertises 137 support for UTF8SMTP and the address doesn't contain any US-ASCII 138 characters not permitted in the ORCPT parameter. It SHOULD be used 139 in a message/global-delivery-status Original-Recipient or Final- 140 Recipient DSN field; or in an Original-Recipient header field 141 [RFC3798] if the message is a UTF8SMTP message. 143 In addition, the utf-8-addr-unitext form can be used anywhere where 144 the utf-8-address form is allowed. 146 When using in the ORCPT parameter, the UTF-8 address type requires 147 that US-ASCII CTLs, SP, \, + and = be encoded using xtext encoding as 148 described in [RFC3461]. This is described by the utf-8-addr-xtext 149 form in the ABNF below. Unicode characters MAY be included in a 150 UTF-8 address type using a "\x{HEXPOINT}" syntax 151 (EmbeddedUnicodeChar), where HEXPOINT is 2 to 6 hexadecimal digits. 152 When sending data to a UTF8SMTP capable server, native UTF-8 153 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax 154 described in details below. When sending data to an SMTP server 155 which does not advertise UTF8SMTP, then the EmbeddedUnicodeChar 156 syntax MUST be used instead of UTF-8. 158 When the ORCPT parameter is placed in a message/ 159 global-delivery-status Original-Recipient field, the utf-8-addr-xtext 160 form of the UTF-8 address type SHOULD be converted to the 'utf-8- 161 address' form (see the ABNF below) by removing all xtext encoding 162 first (which will result in the 'utf-8-addr-unitext' form), followed 163 by removal of the 'unitext' encoding. However, if an address is 164 labeled with the UTF-8 address type but does not conform to utf-8 165 syntax, then it MUST be copied into the message/ 166 global-delivery-status field without alteration. 168 The ability to encode characters with the EmbeddedUnicodeChar 169 encodings should be viewed as a transitional mechanism. It is hoped 170 that as systems lacking support for UTF8SMTP become less common over 171 time, these encodings can eventually be phased out. 173 In the ABNF below all productions not defined in this document are 174 defined in Appendix B of [RFC4234], in section 4 of [RFC3629] or in 175 [RFC3464]. 177 utf-8-type-addr = "utf-8;" utf-8-enc-addr 179 utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ] 180 ; 'uMailbox' is defined in [I-D.ietf-eai-smtpext]. 181 ; 'Mailbox' is defined in [RFC2821]. 183 utf-8-enc-addr = utf-8-addr-xtext / 184 utf-8-addr-unitext / 185 utf-8-address 187 utf-8-addr-xtext = xtext 188 ; xtext is defined in [RFC3461]. 189 ; When xtext encoding is removed, 190 ; the syntax MUST conform to 191 ; 'utf-8-addr-unitext'. 193 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 194 ; MUST follow 'utf-8-address' ABNF when 195 ; dequoted 197 QUCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e / 198 UTF8-2 / UTF8-3 / UTF8-4 199 ; US-ASCII printable characters except 200 ; CTLs, SP, '\', '+' and '=', plus 201 ; other Unicode characters in UTF-8 203 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 204 ; starts with "\x" 206 HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 207 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 208 ( NZDHEXDIG 3(HEXDIG) ) / 209 ( "D" %x30-37 2(HEXDIG) ) / 210 ; 4 digit forms excluding surrogate 211 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 212 ( "10" 4*HEXDIG ) ; 6 digit forms 213 ; represents either "\" or a Unicode code point outside the 214 ; US-ASCII repertoire 216 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 217 ; HEXDIG excluding 0-7 218 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 219 ; HEXDIG excluding "0" 220 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 221 ; HEXDIG excluding "0" and "D" 223 4. UTF-8 Delivery Status Notifications 225 A traditional delivery status notification [RFC3464] comes in a 226 three-part multipart/report [RFC3462] container, where the first part 227 is human readable text describing the error, the second part is a 228 7-bit-only message/delivery-status and the optional third part is 229 used for content (message/rfc822) or header (text/rfc822-headers) 230 return. As the present DSN format does not permit returning of 231 undeliverable UTF8SMTP messages, three new media types are needed. 233 The first type, message/global-delivery-status has the syntax of 234 message/delivery-status with three modifications. First, the charset 235 for message/global-delivery-status is UTF-8 and thus any field MAY 236 contain UTF-8 characters when appropriate (see the ABNF below). In 237 particular, the Diagnostic-Code field MAY contain UTF-8 as described 238 in UTF8SMTP [I-D.ietf-eai-smtpext]; the Diagnostic-Code field SHOULD 239 be in i-default language [DEFAULTLANG]. Second, systems generating a 240 message/global-delivery-status body part SHOULD use the utf-8-address 241 form of the UTF-8 address type for all addresses containing 242 characters outside the US-ASCII repertoire. These systems SHOULD up- 243 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 244 UTF-8 address type in the ORCPT parameter to the utf-8-address form 245 of a UTF-8 address type in the Original-Recipient field. Third, a 246 new optional field called Localized-Diagnostic is added. Each 247 instance includes a language tag [LANGTAGS] and contains text in the 248 specified language. This is equivalent to the text part of the 249 Diagnostic-Code field. All instances of Localized-Diagnostic MUST 250 use different language tags. The ABNF for message/ 251 global-delivery-status is specified below: 253 In the ABNF below all productions not defined in this document are 254 defined in Appendix B of [RFC4234], in section 4 of [RFC3629] or in 255 [RFC3464]. 257 utf-8-delivery-status-content = per-message-fields 258 1*( CRLF utf-8-per-recipient-fields ) 259 ; "per-message-fields" remains unchanged from the definition 260 ; in RFC 3464, except for the "extension-field" 261 ; which is updated below. 263 utf-8-per-recipient-fields = 264 [ original-recipient-field CRLF ] 265 final-recipient-field CRLF 266 action-field CRLF 267 status-field CRLF 268 [ remote-mta-field CRLF ] 269 [ diagnostic-code-field CRLF 270 *(localized-diagnostic-text-field CRLF) ] 272 [ last-attempt-date-field CRLF ] 273 [ will-retry-until-field CRLF ] 274 *( extension-field CRLF ) 275 ; All fields except for "original-recipient-field", 276 ; "final-recipient-field", "diagnostic-code-field" 277 ; and "extension-field" remain unchanged from 278 ; the definition in RFC 3464. 280 generic-address =/ utf-8-enc-addr 281 ; Only allowed with the "utf-8" address-type. 282 ; 283 ; This indirectly updates "original-recipient-field" 284 ; and "final-recipient-field" 286 diagnostic-code-field = 287 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed 289 localized-diagnostic-text-field = 290 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 291 ; "Language-Tag" is a language tag as defined in [LANGTAGS]. 293 extension-field =/ extension-field-name ":" *utf8-text 295 text-fixed = %d1-9 / ; Any Unicode character except for NUL, 296 %d11 / ; CR and LF, encoded in UTF-8 297 %d12 / 298 %d14-127 299 ; Same as from RFC 2822, but without . 300 ; If/when RFC 2822 is updated to disallow , 301 ; this should become just 302 ; Also, if/when RFC 2822 is updated to disallow control characters 303 ; this should become a reference to RFC 2822upd instead. 305 utf8-text = text-fixed / UTF8-non-ascii 307 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 309 The second type, used for returning the content, is message/global 310 which is similar to message/rfc822, except it contains a message with 311 UTF-8 headers. This media type is described in 312 [I-D.ietf-eai-utf8headers]. 314 The third type, used for returning the headers, is message/ 315 global-headers and contains only the UTF-8 header fields of a message 316 (all lines prior to the first blank line in a UTF8SMTP message). 317 Unlike message/global, this body part provides no difficulties for 318 present infrastructure. 320 Note, that as far as multipart/report [RFC3462] container is 321 concerned, message/global-delivery-status, message/global and 322 message/global-headers MUST be treated as equivalent to message/ 323 delivery-status, message/rfc822 and text/rfc822-headers. I.e. 324 implementations processing multipart/report MUST expect any 325 combinations of the 6 MIME types mentioned above inside a multipart/ 326 report MIME type. 328 All three new types will typically use the "8bit" Content-Transfer- 329 Encoding. (In the event all content is 7-bit, the equivalent 330 traditional types for delivery status notifications MAY be used. For 331 example, if information in message/global-delivery-status part can be 332 represented without any loss of information as message/ 333 delivery-status, then the message/delivery-status body part may be 334 used.) Note that [I-D.ietf-eai-utf8headers] relaxed restriction from 335 MIME [RFC2046] regarding use of Content-Transfer-Encoding in new 336 "message" subtypes. This specification explicitly allows use of 337 Content-Transfer-Encoding in message/global-headers and message/ 338 global-delivery-status. This is not believed to be problematic as 339 these new MIME types are intended primarily for use by newer systems 340 with full support for 8-bit MIME and UTF-8 headers. 342 4.1. Additional requirements on SMTP servers 344 If an SMTP server which advertises both UTF8SMTP and DSN needs to 345 return an undeliverable UTF8SMTP message, then it MUST NOT downgrade 346 [I-D.ietf-eai-downgrade] the UTF8SMTP message when generating the 347 corresponding multipart/report. If the return path SMTP server does 348 not support UTF8SMTP, then the undeliverable body part and headers 349 MUST be encoded using a 7 bit Content-Transfer-Encoding such as 350 base64 or quoted-printable [RFC2045], as detailed in Section 4. 351 Otherwise 8bit Content-Transfer-Encoding can be used. 353 5. UTF-8 Message Disposition Notifications 355 Message Disposition Notifications [RFC3798] have a similar design and 356 structure to DSNs. As a result, they use the same basic return 357 format. When generating a MDN for a UTF-8 header message, the third 358 part of the multipart/report contains the returned content (message/ 359 global) or header (message/global-headers), same as for DSNs. The 360 second part of the multipart/report uses a new media type, message/ 361 global-disposition-notification, which has the syntax of message/ 362 disposition-notification with two modifications. First, the charset 363 for message/global-disposition-notification is UTF-8 and thus any 364 field MAY contain UTF-8 characters when appropriate (see the ABNF 365 below). (In particular, the failure-field, the error-field and the 366 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 367 language [DEFAULTLANG].) Second, systems generating a message/ 368 global-disposition-notification body part (typically a mail user 369 agent) SHOULD use the UTF-8 address type for all addresses containing 370 characters outside the US-ASCII repertoire. 372 The MDN specification also defines the Original-Recipient header 373 field which is added with a copy of the contents of ORCPT at delivery 374 time. When generating an Original-Recipient header field, a delivery 375 agent writing a UTF-8 header message in native format SHOULD convert 376 the utf-8-addr-xtext or the utf-8-addr-unitext form of a UTF-8 377 address type in the ORCPT parameter to the corresponding utf-8- 378 address form. 380 The MDN specification also defines the Disposition-Notification-To 381 header which is an address header and thus follows the same 8-bit 382 rules as other address headers such as "From" and "To" when used in a 383 UTF-8 header message. 385 ; ABNF for "original-recipient-header", "original-recipient-field" 386 ; and "final-recipient-field" from RFC 3798 is implicitly updated 387 ; as they use the updated "generic-address" as defined in 388 ; section 4 of this document. 390 failure-field = "Failure" ":" *utf8-text 391 ; "utf8-text" is defined in section 4 of this document. 393 error-field = "Error" ":" *utf8-text 394 ; "utf8-text" is defined in section 4 of this document. 396 warning-field = "Warning" ":" *utf8-text 397 ; "utf8-text" is defined in section 4 of this document. 399 6. IANA Considerations 401 This specification does not create any new IANA registries. However 402 the following items are registered as a result of this document: 404 6.1. UTF-8 Mail Address Type Registration 406 The mail address type registry was created by RFC 3464. The 407 registration template response follows: 409 (a) The proposed address-type name. 411 UTF-8 413 (b) The syntax for mailbox addresses of this type, specified using 414 BNF, regular expressions, ASN.1, or other non-ambiguous language. 416 See Section 3. 418 (c) If addresses of this type are not composed entirely of graphic 419 characters from the US-ASCII repertoire, a specification for how they 420 are to be encoded as graphic US-ASCII characters in a DSN Original- 421 Recipient or Final-Recipient DSN field. 423 This address type has 3 forms (as defined in Section 3): utf-8-addr- 424 xtext, utf-8-addr-unitext and utf-8-address. The first 2 forms are 425 7-bit safe. 427 The utf-8-address form MUST NOT be used 429 1. in the ORCPT parameter when the SMTP server doesn't advertise 430 support for UTF8SMTP 432 2. or the SMTP server supports UTF8SMTP, but the address contains 433 US-ASCII characters not permitted in the ORCPT parameter (e.g. 434 the ORCPT parameter forbids SP and the = characters); 436 3. or in a 7-bit transport environment including a message/ 437 delivery-status Original-Recipient or Final-Recipient field. 439 The utf-8-addr-xtext form MUST be used instead in the first case, the 440 utf-8-addr-unitext form MUST be used in the other two cases. The 441 utf-8-address form MAY be used in the ORCPT parameter when the SMTP 442 server also advertises support for UTF8SMTP and the address doesn't 443 contain any US-ASCII characters not permitted in the ORCPT parameter; 444 in a message/global-delivery-status Original-Recipient or Final- 445 Recipient DSN field; or in an Original-Recipient header field 446 [RFC3798] if the message is a UTF8SMTP message. 448 In addition, the utf-8-addr-unitext form can be used anywhere where 449 the utf-8-address form is allowed. 451 6.2. Update to 'smtp' Diagnostic Type Registration 453 The mail diagnostic type registry was created by RFC 3464. The 454 registration for the 'smtp' diagnostic type should be updated to 455 reference RFC XXXX in addition to RFC 3464. 457 When the 'smtp' diagnostic type is used in the context of a message/ 458 delivery-status body part, it remains as presently defined. When the 459 'smtp' diagnostic type is used in the context of a message/ 460 global-delivery-status body part, the codes remain the same, but the 461 text portion MAY contain UTF-8 characters. 463 6.3. message/global-headers 465 Type name: message 467 Subtype name: global-headers 469 Required parameters: none 471 Optional parameters: none 473 Encoding considerations: This media type contains Internationalized 474 Email Headers [I-D.ietf-eai-utf8headers] with no message body. 475 Whenever possible, the 8-bit content transfer encoding SHOULD be 476 used. When this media type passes through a 7-bit-only SMTP 477 infrastructure it MAY be encoded with the base64 or quoted- 478 printable content transfer encoding. 480 Security considerations: See Section 7 482 Interoperability considerations: It is important this media type is 483 not converted to a charset other than UTF-8. As a result, 484 implementations MUST NOT include a charset parameter with this 485 media type. Although it might be possible to downconvert this 486 media type to the text/rfc822-header media type, such conversion 487 is discouraged as it loses information. 489 Published specification: RFC XXXX 491 Applications that use this media type: UTF8SMTP servers and email 492 clients that support multipart/report generation or parsing. 494 Additional information: 496 Magic number(s): none 498 File extension(s): In the event this is saved to a file, the 499 extension ".u8hdr" is suggested. 501 Macintosh file type code(s): The 'TEXT' type code is suggested as 502 files of this type are typically used for diagnostic purposes and 503 suitable for analysis in a UTF-8 aware text editor. A uniform 504 type identifier (UTI) of "public.utf8-email-message-header" is 505 suggested. This type conforms to "public.utf8-plain-text" and 506 "public.plain-text". 508 Person & email address to contact for further information: See the 509 Author's address section of this document. 511 Intended usage: COMMON 513 Restrictions on usage: This media type contains textual data in the 514 UTF-8 charset. It typically contains octets with the 8th bit set. 515 As a result a transfer encoding is required when a 7-bit transport 516 is used. 518 Author: See Author's Address section of this document. 520 Change controller: IETF Standards Process 522 6.4. message/global-delivery-status 524 Type name: message 526 Subtype name: global-delivery-status 528 Required parameters: none 530 Optional parameters: none 532 Encoding considerations: This media type contains delivery status 533 notification attributes in the UTF-8 charset. The 8-bit content 534 transfer encoding MUST be used with this content-type, unless it 535 is sent over a 7-bit transport environment in which case quoted- 536 printable or base64 may be necessary. 538 Security considerations: See Section 7 540 Interoperability considerations: This media type provides 541 functionality similar to the message/delivery-status content type 542 for email message return information. Clients of the previous 543 format will need to be upgraded to interpret the new format, 544 however the new media type makes it simple to identify the 545 difference. 547 Published specification: RFC XXXX 549 Applications that use this media type: SMTP servers and email 550 clients that support delivery status notification generation or 551 parsing. 553 Additional information: 555 Magic number(s): none 557 File extension(s): The extension ".u8dsn" is suggested. 559 Macintosh file type code(s): A uniform type identifier (UTI) of 560 "public.utf8-email-message-delivery-status" is suggested. This 561 type conforms to "public.utf8-plain-text". 563 Person & email address to contact for further information: See the 564 Author's address section of this document. 566 Intended usage: COMMON 568 Restrictions on usage: This is expected to be the second part of a 569 multipart/report. 571 Author: See Author's Address section of this document. 573 Change controller: IETF Standards Process 575 6.5. message/global-disposition-notification 577 Type name: message 579 Subtype name: global-disposition-notification 581 Required parameters: none 583 Optional parameters: none 585 Encoding considerations: This media type contains disposition 586 notification attributes in the UTF-8 charset. The 8-bit content 587 transfer encoding MUST be used with this content-type, unless it 588 is sent over a 7-bit transport environment in which case quoted- 589 printable or base64 may be necessary. 591 Security considerations: See Section 7 593 Interoperability considerations: This media type provides 594 functionality similar to the message/disposition-notification 595 content type for email message disposition information. Clients 596 of the previous format will need to be upgraded to interpret the 597 new format, however the new media type makes it simple to identify 598 the difference. 600 Published specification: RFC XXXX 602 Applications that use this media type: Email clients or servers that 603 support message disposition notification generation or parsing. 605 Additional information: 607 Magic number(s): none 609 File extension(s): The extension ".u8mdn" is suggested. 611 Macintosh file type code(s): A uniform type identifier (UTI) of 612 "public.utf8-email-message-disposition-notification" is suggested. 613 This type conforms to "public.utf8-plain-text". 615 Person & email address to contact for further information: See the 616 Author's address section of this document. 618 Intended usage: COMMON 620 Restrictions on usage: This is expected to be the second part of a 621 multipart/report. 623 Author: See Author's Address section of this document. 625 Change controller: IETF Standards Process 627 7. Security Considerations 629 Automated use of report types without authentication presents several 630 security issues. Forging negative reports presents the opportunity 631 for denial-of-service attacks when the reports are used for automated 632 maintenance of directories or mailing lists. Forging positive 633 reports may cause the sender to incorrectly believe a message was 634 delivered when it was not. 636 Malicious users can generate report structures designed to trigger 637 coding flaws in report parsers. Report parsers need to use secure 638 coding techniques to avoid the risk of buffer overflow or denial-of- 639 service attacks against parser coding mistakes. Code reviews of such 640 parsers are also recommended. 642 Malicious users of the email system regularly send messages with 643 forged envelope return paths and these messages trigger delivery 644 status reports that result in a large amount of unwanted traffic on 645 the Internet. Many users choose to ignore delivery status 646 notifications because they are usually the result of "blowback" from 647 forged messages and thus never notice when messages they sent go 648 undelivered. As a result, support for correlation of delivery status 649 and message disposition notification messages with sent-messages has 650 become a critical feature of mail clients and possibly mail stores if 651 the email infrastructure is to remain reliable. In the short term, 652 simply correlating message-IDs may be sufficient to distinguish true 653 status notifications from those resulting from forged originator 654 addresses. But in the longer term, including cryptographic signature 655 material that can securely associate the status notification with the 656 original message is advisable. 658 As this specification permits UTF-8 in additional fields, the 659 security considerations of UTF-8 [RFC3629] apply. 661 8. References 663 8.1. Normative References 665 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 666 Requirement Levels", BCP 14, RFC 2119, March 1997. 668 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 669 April 2001. 671 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 672 Extension for Delivery Status Notifications (DSNs)", 673 RFC 3461, January 2003. 675 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 676 Reporting of Mail System Administrative Messages", 677 RFC 3462, January 2003. 679 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 680 for Delivery Status Notifications", RFC 3464, 681 January 2003. 683 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 684 10646", STD 63, RFC 3629, November 2003. 686 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 687 Notification", RFC 3798, May 2004. 689 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 690 Specifications: ABNF", RFC 4234, October 2005. 692 [I-D.ietf-eai-utf8headers] 693 Yang, A., "Internationalized Email Headers", 694 draft-ietf-eai-utf8headers-08 (work in progress), 695 April 2007. 697 [I-D.ietf-eai-smtpext] 698 Yao, J. and W. Mao, "SMTP extension for internationalized 699 email address", draft-ietf-eai-smtpext-10 (work in 700 progress), November 2007. 702 [LANGTAGS] 703 Phillips, A. and M. Davis, "Tags for Identifying 704 Languages", RFC 4646, September 2006. 706 [DEFAULTLANG] 707 Alvestrand, H., "IETF Policy on Character Sets and 708 Languages", RFC 2277, January 1998. 710 8.2. Informative References 712 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 713 Extensions (MIME) Part One: Format of Internet Message 714 Bodies", RFC 2045, November 1996. 716 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 717 Extensions (MIME) Part Two: Media Types", RFC 2046, 718 November 1996. 720 [I-D.ietf-eai-downgrade] 721 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 722 Email Address Internationalization (EAI)", 723 draft-ietf-eai-downgrade-05 (work in progress), Mar 2007. 725 Appendix A. Acknowledgements 727 Many thanks for input provided by Pete Resnick, James Galvin, Ned 728 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM and 729 members of the EAI WG to help solidify this proposal. 731 Appendix B. Changes from -05 733 Minor ABNF fixed discovered while examining Bill Fenner's ABNF parser 734 output. 736 Minor editorial changes from SM. 738 Appendix C. Changes from -04 740 Restructured to be more clear about how it relates to RFC 741 2822 . 743 Appendix D. Changes from -03 745 Addressed editorial comments from Frank Ellermann and 746 sm+ietf@elandsys.com. 748 Moved EAI-downgrade to the Informative References. 750 Updated references. 752 Deleted the list of open issues. 754 Fixed IDnits. 756 Appendix E. Changes from -02 758 Make the space between UTF-8 and ASCII address mandatory. 760 Changed all MIME types to be message/global-*. 762 Clarified that new message/global-* MIME types are semantically 763 equivalent to the corresponding RFC 3464 MIME types. 765 Added a requirement not to downgrade non-delivery reports. 767 Deleted unused RFC 3501 reference and updated other references. 769 Appendix F. Changes from -01 771 Cleaned up and tightened ABNF, in particular HEXPOINT. 773 Extended DSN report syntax to allow for localized version of 774 diagnostic-code-field. 776 Added ABNF for the EAI DSN and EAI MDN. 778 Appendix G. Changes from -00 780 Added paragraph about use of 8bit Content-Transfer-Encoding for new 781 message sub-types. 783 Updated the list of open issues. 785 Clarified that this document is targeted to become an Experimental 786 RFC. 788 Made the EAI downgrade document a normative reference. 790 Updated ABNF for utf-8-address. 792 Authors' Addresses 794 Chris Newman 795 Sun Microsystems 796 3401 Centrelake Dr., Suite 410 797 Ontario, CA 91761 798 US 800 Email: chris.newman@sun.com 802 Alexey Melnikov (editor) 803 Isode Ltd 804 5 Castle Business Village 805 36 Station Road 806 Hampton, Middlesex TW12 2BX 807 UK 809 Email: Alexey.Melnikov@isode.com 811 Full Copyright Statement 813 Copyright (C) The IETF Trust (2008). 815 This document is subject to the rights, licenses and restrictions 816 contained in BCP 78, and except as set forth therein, the authors 817 retain all their rights. 819 This document and the information contained herein are provided on an 820 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 821 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 822 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 823 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 824 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 825 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 827 Intellectual Property 829 The IETF takes no position regarding the validity or scope of any 830 Intellectual Property Rights or other rights that might be claimed to 831 pertain to the implementation or use of the technology described in 832 this document or the extent to which any license under such rights 833 might or might not be available; nor does it represent that it has 834 made any independent effort to identify any such rights. Information 835 on the procedures with respect to rights in RFC documents can be 836 found in BCP 78 and BCP 79. 838 Copies of IPR disclosures made to the IETF Secretariat and any 839 assurances of licenses to be made available, or the result of an 840 attempt made to obtain a general license or permission for the use of 841 such proprietary rights by implementers or users of this 842 specification can be obtained from the IETF on-line IPR repository at 843 http://www.ietf.org/ipr. 845 The IETF invites any interested party to bring to its attention any 846 copyrights, patents or patent applications, or other proprietary 847 rights that may cover technology that may be required to implement 848 this standard. Please address the information to the IETF at 849 ietf-ipr@ietf.org. 851 Acknowledgment 853 Funding for the RFC Editor function is provided by the IETF 854 Administrative Support Activity (IASA).