idnits 2.17.1 draft-ietf-eai-dsn-03.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 777. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 801. 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). (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 (September 2, 2007) is 6074 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-06 == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-07 == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-04 ** Obsolete normative reference: RFC 4646 (ref. 'LANGTAGS') (Obsoleted by RFC 5646) Summary: 6 errors (**), 0 flaws (~~), 5 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 September 2, 2007 7 Expires: March 5, 2008 9 International Delivery and Disposition Notifications 10 draft-ietf-eai-dsn-03.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 March 5, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 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. Open Issues . . . . . . . . . . . . . . . . . . . . . 16 75 Appendix C. Changes from -02 . . . . . . . . . . . . . . . . . . 17 76 Appendix D. Changes from -01 . . . . . . . . . . . . . . . . . . 17 77 Appendix E. Changes from -00 . . . . . . . . . . . . . . . . . . 17 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 79 Intellectual Property and Copyright Statements . . . . . . . . . . 19 81 1. Introduction 83 When an email message is transmitted using the UTF8SMTP 84 [I-D.ietf-eai-smtpext] extension and Internationalized Email Headers 85 [I-D.ietf-eai-utf8headers], it is sometimes necessary to return that 86 message or generate a Message Disposition Notification [RFC3798] 87 (MDN). As a message sent to multiple recipients can generate a 88 status and disposition notification for each recipient, it is helpful 89 if a client can correlate these returns based on the recipient 90 address it provided, thus preservation of the original recipient is 91 important. This specification describes how to preserve the original 92 recipient and updates the MDN and DSN formats to support the new 93 address types. 95 2. Conventions Used in this Document 97 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 98 in this document are to be interpreted as defined in "Key words for 99 use in RFCs to Indicate Requirement Levels" [RFC2119]. 101 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234] 102 notation including the core rules defined in Appendix B of RFC 4234 103 and the rules in section 4 of RFC 3629. 105 3. UTF-8 Address Type 107 An Extensible Message Format for Delivery Status Notifications 108 [RFC3464] defines the concept of an address type. The address format 109 introduced in Internationalized Email Headers 110 [I-D.ietf-eai-utf8headers] is a new address type. The syntax for the 111 new address type in the context of status notifications follows: 113 An SMTP [RFC2821] server which advertises both the UTF8SMTP extension 114 [I-D.ietf-eai-smtpext] and the DSN extension [RFC3461] MUST accept a 115 UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 116 characters. This address type also includes a 7-bit encoding 117 suitable for use in a message/delivery-status body part or an ORCPT 118 parameter sent to an SMTP server which does not advertise UTF8SMTP. 120 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext 121 and utf-8-address. The first 2 forms are 7-bit safe. 123 The utf-8-address form is only suitable for use in newly defined 124 protocols capable of native representation of 8-bit characters. I.e. 125 the utf-8-address form MUST NOT be used in the ORCPT parameter when 126 the SMTP server doesn't advertise support for UTF8SMTP or the SMTP 127 server supports UTF8SMTP, but the address contains US-ASCII 128 characters not permitted in the ORCPT parameter (e.g. the ORCPT 129 parameter forbids unencoded SP and =); or in a 7-bit transport 130 environment including a message/delivery-status Original-Recipient or 131 Final-Recipient field. In the former case the utf-8-addr-xtext form 132 (see below) MUST be used instead, in the latter case the utf-8-addr- 133 unitext form MUST be used. The utf-8-address form MAY be used in the 134 ORCPT parameter when the SMTP server also advertises support for 135 UTF8SMTP and the address doesn't contains any US-ASCII characters not 136 permitted in the ORCPT parameter. It SHOULD be used in a message/ 137 global-delivery-status Original-Recipient or Final-Recipient DSN 138 field; or in an Original-Recipient header field [RFC3798] if the 139 message is a UTF8SMTP message. 141 In addition, the utf-8-addr-unitext form can be used anywhere where 142 the utf-8-address form is allowed. 144 When using in the ORCPT parameter, the UTF-8 address type requires 145 that US-ASCII CTLs, SP, \, + and = be encoded using xtext encoding as 146 described in [RFC3461]. This is described by the utf-8-addr-xtext 147 form in the ABNF below. Unicode characters MAY be included in a 148 UTF-8 address type using a "\x{HEXPOINT}" syntax, where HEXPOINT is 2 149 to 6 hexadecimal digits. When sending data to a UTF8SMTP capable 150 server, native UTF-8 characters SHOULD be used instead of the 151 QMIDCHAR and QHIGHCHAR encodings described below. When sending data 152 to an SMTP server which does not advertise UTF8SMTP, then the 153 QMIDCHAR and QHIGHCHAR encodings MUST be used instead of UTF-8. 155 When the ORCPT parameter is placed in a message/ 156 global-delivery-status Original-Recipient field, the utf-8-addr-xtext 157 form of the UTF-8 address type SHOULD be converted to the 'utf-8- 158 address' form (see the ABNF below) by removing all xtext encoding 159 first (which will result in the 'utf-8-addr-unitext' form), followed 160 by removal of the 'unitext' encoding. However, if an address is 161 labeled with the UTF-8 address type but does not conform to utf-8 162 syntax, then it MUST be copied into the message/ 163 global-delivery-status field without alteration. 165 The ability to encode characters with the EmbeddedUnicodeChar 166 encodings should be viewed as a transitional mechanism. It is hoped 167 that as systems lacking support for UTF8SMTP become less common over 168 time, these encodings can eventually be phased out. 170 utf-8-type-addr = "utf-8;" utf-8-enc-addr 172 utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ] 173 ; 'uMailbox' is defined in [I-D.ietf-eai-smtpext]. 174 ; 'Mailbox' is defined in [RFC2821]. 176 utf-8-enc-addr = utf-8-addr-xtext / 177 utf-8-addr-unitext / 178 utf-8-address 180 ///Add comment about which where each type is used 182 utf-8-addr-xtext = xtext 183 ; xtext is defined in [RFC3461]. 184 ; When xtext encoding is removed, 185 ; the syntax MUST conform to 186 ; 'utf-8-addr-unitext'. 188 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 189 ; MUST follow 'utf-8-address' ABNF when 190 ; dequoted 192 QUCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e / 193 UTF8-2 / UTF8-3 / UTF8-4 194 ; Printable except CTLs, SP, '\', '+' and '=' 196 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 197 ; starts with "\x" 199 HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 200 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 201 ( NZDHEXDIG 3(HEXDIG) ) / 202 ( "D" %x30-37 2(HEXDIG) ) / 203 ; 4 digit forms excluding surrogate 204 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 205 ( "10" 4*HEXDIG ) ; 6 digit forms 206 ; represents either "\" or a Unicode code point outside the 207 ; US-ASCII repertoire 209 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 210 ; HEXDIG excluding 0-7 211 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 212 ; HEXDIG excluding "0" 213 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 214 ; HEXDIG excluding "0" and "D" 216 4. UTF-8 Delivery Status Notifications 218 A traditional delivery status notification [RFC3464] comes in a 219 three-part multipart/report [RFC3462] container, where the first part 220 is human readable text describing the error, the second part is a 221 7-bit-only message/delivery-status and the optional third part is 222 used for content (message/rfc822) or header (text/rfc822-headers) 223 return. As the present DSN format does not permit returning of 224 undeliverable UTF8SMTP message, three new media types are needed. 226 The first type, message/global-delivery-status has the syntax of 227 message/delivery-status with three modifications. First, the charset 228 for message/global-delivery-status is UTF-8 and thus any field MAY 229 contain UTF-8 characters when appropriate (see the ABNF below). In 230 particular, the Diagnostic-Code field MAY contain UTF-8 as described 231 in UTF8SMTP [I-D.ietf-eai-smtpext]; the Diagnostic-Code field SHOULD 232 be in i-default language [LANGTAGS]. Second, systems generating a 233 message/global-delivery-status body part SHOULD use the utf-8-address 234 form of the UTF-8 address type for all addresses containing 235 characters outside the US-ASCII repertoire. These systems SHOULD up- 236 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 237 UTF-8 address type in the ORCPT parameter to the utf-8-address form 238 of a UTF-8 address type in the Original-Recipient field. Third, a 239 new optional field called Localized-Diagnostic is added. Each 240 instance includes a language tag [LANGTAGS] and contains text in the 241 specified language. This is equivalent to the text part of the 242 Diagnostic-Code field. All instances of Localized-Diagnostic MUST 243 use different language tags. The ABNF for message/ 244 global-delivery-status is specified below: 246 utf-8-delivery-status-content = per-message-fields 247 1*( CRLF utf-8-per-recipient-fields ) 248 ; "per-message-fields" remains unchanged from the definition 249 ; in RFC 3464, except for the "extension-field" 250 ; which is updated below. 252 utf-8-per-recipient-fields = 253 [ original-recipient-field CRLF ] 254 final-recipient-field CRLF 255 action-field CRLF 256 status-field CRLF 257 [ remote-mta-field CRLF ] 258 [ diagnostic-code-field CRLF 259 *(localized-diagnostic-text-field CRLF) ] 260 [ last-attempt-date-field CRLF ] 261 [ will-retry-until-field CRLF ] 262 *( extension-field CRLF ) 263 ; All fields except for "original-recipient-field", 264 ; "final-recipient-field", "diagnostic-code-field" 265 ; and "extension-field" remain unchanged from 266 ; the definition in RFC 3464. 268 generic-address =/ utf-8-enc-addr 269 ; Only allowed with the "utf-8" address-type. 270 ; 271 ; This indirectly updates "original-recipient-field" 272 ; and "final-recipient-field" 274 diagnostic-code-field = 275 "Diagnostic-Code" ":" diagnostic-type ";" *text 277 localized-diagnostic-text-field = 278 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 279 ; "Language-Tag" is a language tag as defined in [LANGTAGS]. 281 extension-field =/ extension-field-name ":" *utf8-text 283 utf8-text = %d1-9 / ; Any Unicode character except for NUL, 284 %d11 / ; CR and LF, encoded in UTF-8 285 %d12 / 286 %d14-127 / 287 UTFMB 289 UTFMB = UTF2 / UTF3 / UTF4 291 The second type, used for content return, is message/global which is 292 similar to message/rfc822, except it contains a message with UTF-8 293 headers. This media type is described in [I-D.ietf-eai-utf8headers]. 295 The third type, used for header return, is message/global-headers and 296 contains only the UTF-8 headers of a message (all lines prior to the 297 first blank line in a UTF8SMTP message). Unlike message/global, this 298 body part provides no difficulties for present infrastructure. 300 Note, that as far as multipart/report [RFC3462] container is 301 concerned, message/global-delivery-status, message/global and 302 message/global-headers MUST be treated as equivalent to message/ 303 delivery-status, message/rfc822 and text/rfc822-headers. I.e. 304 implementations processing multipart/report MUST expect any 305 combinations of the 6 MIME types mentioned above inside a multipart/ 306 report MIME type. 308 All three new types will typically use the "8bit" Content-Transfer- 309 Encoding. (In the event all content is 7-bit, the equivalent 310 traditional types for delivery status notifications MAY be used. For 311 example, if information in message/global-delivery-status part can be 312 represented without any loss of information as message/ 313 delivery-status, then the message/delivery-status body part may be 314 used.) Note that [I-D.ietf-eai-utf8headers] relaxed restriction from 315 MIME [RFC2046] regarding use of Content-Transfer-Encoding in new 316 "message" subtypes. This specification explicitly allows use of 317 Content-Transfer-Encoding in message/global-headers and message/ 318 global-delivery-status. This is not believed to be problematic as 319 these new MIME types are intended primarily for use by newer systems 320 with full support for 8-bit MIME and UTF-8 headers. 322 4.1. Additional requirements on SMTP servers 324 If an SMTP server which advertises both UTF8SMTP and DSN needs to 325 return an undeliverable UTF8SMTP message, then it MUST NOT downgrade 326 [I-D.ietf-eai-downgrade] the UTF8SMTP message when generating the 327 corresponding multipart/report. If the return path SMTP server does 328 not support UTF8SMTP, then the undeliverable body part and headers 329 MUST be encoded using a 7 bit Content-Transfer-Encoding such as 330 base64 or quoted-printable [RFC2045], as detailed in Section 4. 331 Otherwise 8bit Content-Transfer-Encoding can be used. 333 5. UTF-8 Message Disposition Notifications 335 Message Disposition Notifications [RFC3798] have a similar design and 336 structure to DSNs. As a result, they use the same basic return 337 format. When generating a MDN for a UTF-8 header message, content or 338 header return is the same as for DSNs. The second part of the 339 multipart/report uses a new media type, message/ 340 global-disposition-notification, which has the syntax of message/ 341 disposition-notification with two modifications. First, the charset 342 for message/global-disposition-notification is UTF-8 and thus any 343 field MAY contain UTF-8 characters when appropriate (see the ABNF 344 below). (In particular, the failure-field, the error-field and the 345 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 346 language [LANGTAGS].) Second, systems generating a message/ 347 global-disposition-notification body part (typically a mail user 348 agent) SHOULD use the UTF-8 address type for all addresses containing 349 characters outside the US-ASCII repertoire. 351 The MDN specification also defines the Original-Recipient header 352 field which is added with a copy of the contents of ORCPT at delivery 353 time. When generating an Original-Recipient header field, a delivery 354 agent writing a UTF-8 header message in native format SHOULD convert 355 the utf-8-addr-xtext or the utf-8-addr-unitext form of a UTF-8 356 address type in the ORCPT parameter to the corresponding utf-8- 357 address form. 359 The MDN specification also defines the Disposition-Notification-To 360 header which is an address header and thus follows the same 8-bit 361 rules as other address headers such as "From" and "To" when used in a 362 UTF-8 header message. 364 ; ABNF for "original-recipient-header", "original-recipient-field" 365 ; and "final-recipient-field" from RFC 3798 is implicitly updated 366 ; as they use the updated "generic-address" as defined in 367 ; section 4 of this document. 369 failure-field = "Failure" ":" *utf8-text 370 ; "utf8-text" is defined in section 4 of this document. 372 error-field = "Error" ":" *utf8-text 373 ; "utf8-text" is defined in section 4 of this document. 375 warning-field = "Warning" ":" *utf8-text 376 ; "utf8-text" is defined in section 4 of this document. 378 6. IANA Considerations 380 This specification does not create any new IANA registries. However 381 the following items are registered as a result of this document: 383 6.1. UTF-8 Mail Address Type Registration 385 The mail address type registry was created by RFC 3464. The 386 registration template response follows: 388 (a) The proposed address-type name. 390 UTF-8 392 (b) The syntax for mailbox addresses of this type, specified using 393 BNF, regular expressions, ASN.1, or other non-ambiguous language. 395 See Section 3. 397 (c) If addresses of this type are not composed entirely of graphic 398 characters from the US-ASCII repertoire, a specification for how they 399 are to be encoded as graphic US-ASCII characters in a DSN Original- 400 Recipient or Final-Recipient DSN field. 402 This address type has 3 forms (as defined in Section 3): utf-8-addr- 403 xtext, utf-8-addr-unitext and utf-8-address. The first 2 forms are 404 7-bit safe. 406 The utf-8-address form MUST NOT be used in the ORCPT parameter when 407 the SMTP server doesn't advertise support for UTF8SMTP or the SMTP 408 server supports UTF8SMTP, but the address contains US-ASCII 409 characters not permitted in the ORCPT parameter (e.g. the ORCPT 410 parameter forbids SP and =); or in a 7-bit transport environment 411 including a message/delivery-status Original-Recipient or Final- 412 Recipient field. The utf-8-addr-xtext form MUST be used instead in 413 the former case, the utf-8-addr-unitext form MUST be used in the 414 latter case. The utf-8-address form MAY be used in the ORCPT 415 parameter when the SMTP server also advertises support for UTF8SMTP 416 and the address doesn't contains any US-ASCII characters not 417 permitted in the ORCPT parameter; in a message/global-delivery-status 418 Original-Recipient or Final-Recipient DSN field; or in an Original- 419 Recipient header field [RFC3798] if the message is a UTF8SMTP 420 message. 422 In addition, the utf-8-addr-unitext form can be used anywhere where 423 the utf-8-address form is allowed. 425 6.2. Update to 'smtp' Diagnostic Type Registration 427 The mail diagnostic type registry was created by RFC 3464. The 428 registration for the 'smtp' diagnostic type should be updated to 429 reference RFC XXXX in addition to RFC 3464. 431 When the 'smtp' diagnostic type is used in the context of a message/ 432 delivery-status body part, it remains as presently defined. When the 433 'smtp' diagnostic type is used in the context of a message/ 434 global-delivery-status body part, the codes remain the same, but the 435 text portion MAY contain UTF-8 characters. 437 6.3. message/global-headers 439 Type name: message 441 Subtype name: global-headers 443 Required parameters: none 445 Optional parameters: none 447 Encoding considerations: This media type contains Internationalized 448 Email Headers [I-D.ietf-eai-utf8headers] with no message body. 449 Whenever possible, the 8-bit content transfer encoding SHOULD be 450 used. When this media type passes through a 7-bit-only SMTP 451 infrastructure it MAY be encoded with the base64 or quoted- 452 printable content transfer encoding. 454 Security considerations: See Section 7 456 Interoperability considerations: It is important this media type is 457 not converted to a charset other than UTF-8. As a result, 458 implementations MUST NOT include a charset parameter with this 459 media type. Although it might be possible to downconvert this 460 media type to the text/rfc822-header media type, such conversion 461 is discouraged as it loses information. 463 Published specification: RFC XXXX 465 Applications that use this media type: UTF8SMTP servers and email 466 clients that support multipart/report generation or parsing. 468 Additional information: 470 Magic number(s): none 472 File extension(s): In the event this is saved to a file, the 473 extension ".u8hdr" is suggested. 475 Macintosh file type code(s): The 'TEXT' type code is suggested as 476 files of this type are typically used for diagnostic purposes and 477 suitable for analysis in a UTF-8 aware text editor. A uniform 478 type identifier (UTI) of "public.utf8-email-message-header" is 479 suggested. This type conforms to "public.utf8-plain-text" and 480 "public.plain-text". 482 Person & email address to contact for further information: See the 483 Author's address section of this document. 485 Intended usage: COMMON 487 Restrictions on usage: This media type contains textual data in the 488 UTF-8 charset. It typically contains octets with the 8th bit set. 489 As a result a transfer encoding is required when a 7-bit transport 490 is used. 492 Author: See Author's Address section of this document. 494 Change controller: IETF Standards Process 496 6.4. message/global-delivery-status 498 Type name: message 500 Subtype name: global-delivery-status 502 Required parameters: none 504 Optional parameters: none 506 Encoding considerations: This media type contains delivery status 507 notification attributes in the UTF-8 charset. The 8-bit content 508 transfer encoding MUST be used with this content-type, unless it 509 is sent over a 7-bit transport environment in which case quoted- 510 printable or base64 may be necessary. 512 Security considerations: See Section 7 514 Interoperability considerations: This media type provides 515 functionality similar to the message/delivery-status content type 516 for email message return information. Clients of the previous 517 format will need to be upgraded to interpret the new format, 518 however the new media type makes it simple to identify the 519 difference. 521 Published specification: RFC XXXX 523 Applications that use this media type: SMTP servers and email 524 clients that support delivery status notification generation or 525 parsing. 527 Additional information: 529 Magic number(s): none 531 File extension(s): The extension ".u8dsn" is suggested. 533 Macintosh file type code(s): A uniform type identifier (UTI) of 534 "public.utf8-email-message-delivery-status" is suggested. This 535 type conforms to "public.utf8-plain-text". 537 Person & email address to contact for further information: See the 538 Author's address section of this document. 540 Intended usage: COMMON 542 Restrictions on usage: This is expected to be the second part of a 543 multipart/report. 545 Author: See Author's Address section of this document. 547 Change controller: IETF Standards Process 549 6.5. message/global-disposition-notification 551 Type name: message 553 Subtype name: global-disposition-notification 555 Required parameters: none 557 Optional parameters: none 559 Encoding considerations: This media type contains disposition 560 notification attributes in the UTF-8 charset. The 8-bit content 561 transfer encoding MUST be used with this content-type, unless it 562 is sent over a 7-bit transport environment in which case quoted- 563 printable or base64 may be necessary. 565 Security considerations: See Section 7 567 Interoperability considerations: This media type provides 568 functionality similar to the message/disposition-notification 569 content type for email message disposition information. Clients 570 of the previous format will need to be upgraded to interpret the 571 new format, however the new media type makes it simple to identify 572 the difference. 574 Published specification: RFC XXXX 576 Applications that use this media type: Email clients or servers that 577 support message disposition notification generation or parsing. 579 Additional information: 581 Magic number(s): none 583 File extension(s): The extension ".u8mdn" is suggested. 585 Macintosh file type code(s): A uniform type identifier (UTI) of 586 "public.utf8-email-message-disposition-notification" is suggested. 587 This type conforms to "public.utf8-plain-text". 589 Person & email address to contact for further information: See the 590 Author's address section of this document. 592 Intended usage: COMMON 594 Restrictions on usage: This is expected to be the second part of a 595 multipart/report. 597 Author: See Author's Address section of this document. 599 Change controller: IETF Standards Process 601 7. Security Considerations 603 Automated use of report types without authentication presents several 604 security issues. Forging negative reports presents the opportunity 605 for denial-of-service attacks when the reports are used for automated 606 maintenance of directories or mailing lists. Forging positive 607 reports may cause the sender to incorrectly believe a message was 608 delivered when it was not. 610 Malicious users can generate report structures designed to trigger 611 coding flaws in report parsers. Report parsers need to use secure 612 coding techniques to avoid the risk of buffer overflow or denial-of- 613 service attacks against parser coding mistakes. Code reviews of such 614 parsers are also recommended. 616 Malicious users of the email system regularly send messages with 617 forged envelope return paths and these messages trigger delivery 618 status reports that result in a large amount of unwanted traffic on 619 the Internet. Many users choose to ignore delivery status 620 notifications because they are usually the result of "blowback" from 621 forged messages and thus never notice when messages they sent go 622 undelivered. As a result, support for correlation of delivery status 623 and message disposition notification messages with sent-messages has 624 become a critical feature of mail clients and possibly mail stores if 625 the email infrastructure is to remain reliable. In the short term, 626 simply correlating message-IDs may be sufficient to distinguish true 627 status notifications from those resulting from forged originator 628 addresses. But in the longer term, including cryptographic signature 629 material that can securely associate the status notification with the 630 original message is advisable. 632 As this specification permits UTF-8 in additional fields, the 633 security considerations of UTF-8 [RFC3629] apply. 635 8. References 637 8.1. Normative References 639 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 640 Requirement Levels", BCP 14, RFC 2119, March 1997. 642 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 643 April 2001. 645 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 646 Extension for Delivery Status Notifications (DSNs)", 647 RFC 3461, January 2003. 649 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 650 Reporting of Mail System Administrative Messages", 651 RFC 3462, January 2003. 653 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 654 for Delivery Status Notifications", RFC 3464, 655 January 2003. 657 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 658 10646", STD 63, RFC 3629, November 2003. 660 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 661 Notification", RFC 3798, May 2004. 663 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 664 Specifications: ABNF", RFC 4234, October 2005. 666 [I-D.ietf-eai-utf8headers] 667 Yang, A., "Internationalized Email Headers", 668 draft-ietf-eai-utf8headers-06 (work in progress), 669 April 2007. 671 [I-D.ietf-eai-smtpext] 672 Yao, J. and W. Mao, "SMTP extension for internationalized 673 email address", draft-ietf-eai-smtpext-07 (work in 674 progress), April 2007. 676 [I-D.ietf-eai-downgrade] 677 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 678 Email Address Internationalization (EAI)", 679 draft-ietf-eai-downgrade-04 (work in progress), Mar 2007. 681 [LANGTAGS] 682 Phillips, A. and M. Davis, "Tags for Identifying 683 Languages", RFC 4646, September 2006. 685 8.2. Informative References 687 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 688 Extensions (MIME) Part One: Format of Internet Message 689 Bodies", RFC 2045, November 1996. 691 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 692 Extensions (MIME) Part Two: Media Types", RFC 2046, 693 November 1996. 695 Appendix A. Acknowledgements 697 Many thanks for input provided by Pete Resnick, James Galvin, Ned 698 Freed, John Klensin and members of the EAI WG to help solidify this 699 proposal. 701 Appendix B. Open Issues 703 Suggestion to change the utf-8-addr format from \-encoded Unicode to 704 \-encoded UTF-8 as used in URIs. 706 Use a single syntax for I18N addresses in ORCPT/DSN instead of two 707 (Chris) 709 Potential issue: an SMTP server can't deliver an EAI DSN to the next 710 hop - need to use a 7bit encoding, downgrade or discard? Need to 711 describe choices. 713 Tracker issue #1485: UTF8HDR 4.6/DSN: Choice of body part for 714 transport of UTF8SMTP messages 716 Tracker issue #1483: SMTPEXT 2.7: Non-ASCII in response texts 718 Appendix C. Changes from -02 720 Make the space between UTF-8 and ASCII address mandatory. 722 Appendix D. Changes from -01 724 Cleaned up and tightened ABNF, in particular HEXPOINT. 726 Extended DSN report syntax to allow for localized version of 727 diagnostic-code-field. 729 Added ABNF for the EAI DSN and EAI MDN. 731 Appendix E. Changes from -00 733 Added paragraph about use of 8bit Content-Transfer-Encoding for new 734 message sub-types. 736 Updated the list of open issues. 738 Clarified that this document is targeted to become an Experimental 739 RFC. 741 Made the EAI downgrade document a normative reference. 743 Updated ABNF for utf-8-address. 745 Authors' Addresses 747 Chris Newman 748 Sun Microsystems 749 3401 Centrelake Dr., Suite 410 750 Ontario, CA 91761 751 US 753 Email: chris.newman@sun.com 754 Alexey Melnikov (editor) 755 Isode Ltd 756 5 Castle Business Village 757 36 Station Road 758 Hampton, Middlesex TW12 2BX 759 UK 761 Email: Alexey.Melnikov@isode.com 763 Full Copyright Statement 765 Copyright (C) The IETF Trust (2007). 767 This document is subject to the rights, licenses and restrictions 768 contained in BCP 78, and except as set forth therein, the authors 769 retain all their rights. 771 This document and the information contained herein are provided on an 772 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 773 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 774 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 775 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 776 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 777 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 779 Intellectual Property 781 The IETF takes no position regarding the validity or scope of any 782 Intellectual Property Rights or other rights that might be claimed to 783 pertain to the implementation or use of the technology described in 784 this document or the extent to which any license under such rights 785 might or might not be available; nor does it represent that it has 786 made any independent effort to identify any such rights. Information 787 on the procedures with respect to rights in RFC documents can be 788 found in BCP 78 and BCP 79. 790 Copies of IPR disclosures made to the IETF Secretariat and any 791 assurances of licenses to be made available, or the result of an 792 attempt made to obtain a general license or permission for the use of 793 such proprietary rights by implementers or users of this 794 specification can be obtained from the IETF on-line IPR repository at 795 http://www.ietf.org/ipr. 797 The IETF invites any interested party to bring to its attention any 798 copyrights, patents or patent applications, or other proprietary 799 rights that may cover technology that may be required to implement 800 this standard. Please address the information to the IETF at 801 ietf-ipr@ietf.org. 803 Acknowledgment 805 Funding for the RFC Editor function is provided by the IETF 806 Administrative Support Activity (IASA).