idnits 2.17.1 draft-ietf-eai-dsn-05.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 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 827. 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 (November 16, 2007) is 5999 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-07 == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-09 ** Obsolete normative reference: RFC 4646 (ref. 'LANGTAGS') (Obsoleted by RFC 5646) == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-04 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 November 16, 2007 7 Expires: May 19, 2008 9 International Delivery and Disposition Notifications 10 draft-ietf-eai-dsn-05.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 May 19, 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 . . . . . . . . . . . . . . . . . . . . . 10 64 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 10 65 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 17 74 Appendix B. Changes from -04 . . . . . . . . . . . . . . . . . . 17 75 Appendix C. Changes from -03 . . . . . . . . . . . . . . . . . . 17 76 Appendix D. Changes from -02 . . . . . . . . . . . . . . . . . . 17 77 Appendix E. Changes from -01 . . . . . . . . . . . . . . . . . . 17 78 Appendix F. Changes from -00 . . . . . . . . . . . . . . . . . . 18 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 80 Intellectual Property and Copyright Statements . . . . . . . . . . 19 82 1. Introduction 84 When an email message is transmitted using the UTF8SMTP 85 [I-D.ietf-eai-smtpext] extension and Internationalized Email Headers 86 [I-D.ietf-eai-utf8headers], it is sometimes necessary to return that 87 message or generate a Message Disposition Notification [RFC3798] 88 (MDN). As a message sent to multiple recipients can generate a 89 status and disposition notification for each recipient, it is helpful 90 if a client can correlate these returns based on the recipient 91 address it provided, thus preservation of the original recipient is 92 important. This specification describes how to preserve the original 93 recipient and updates the MDN and DSN formats to support the new 94 address types. 96 2. Conventions Used in this Document 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234] 103 notation including the core rules defined in Appendix B of RFC 4234 104 and the UTF-8 syntax rules in section 4 of [RFC3629]. 106 3. UTF-8 Address Type 108 An Extensible Message Format for Delivery Status Notifications 109 [RFC3464] defines the concept of an address type. The address format 110 introduced in Internationalized Email Headers 111 [I-D.ietf-eai-utf8headers] is a new address type. The syntax for the 112 new address type in the context of status notifications follows: 114 An SMTP [RFC2821] server which advertises both the UTF8SMTP extension 115 [I-D.ietf-eai-smtpext] and the DSN extension [RFC3461] MUST accept a 116 UTF-8 address type in the ORCPT parameter including 8-bit UTF-8 117 characters. This address type also includes a 7-bit encoding 118 suitable for use in a message/delivery-status body part or an ORCPT 119 parameter sent to an SMTP server which does not advertise UTF8SMTP. 121 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext 122 and utf-8-address. The first 2 forms are 7-bit safe. 124 The utf-8-address form is only suitable for use in newly defined 125 protocols capable of native representation of 8-bit characters. I.e. 126 the utf-8-address form MUST NOT be used in the ORCPT parameter when 127 the SMTP server doesn't advertise support for UTF8SMTP or the SMTP 128 server supports UTF8SMTP, but the address contains US-ASCII 129 characters not permitted in the ORCPT parameter (e.g. the ORCPT 130 parameter forbids unencoded SP and the = character); or in a 7-bit 131 transport environment including a message/delivery-status Original- 132 Recipient or Final-Recipient field. In the former case the utf-8- 133 addr-xtext form (see below) MUST be used instead, in the latter case 134 the utf-8-addr-unitext form MUST be used. The utf-8-address form MAY 135 be used in the ORCPT parameter when the SMTP server also advertises 136 support for UTF8SMTP and the address doesn't contain any US-ASCII 137 characters not permitted in the ORCPT parameter. It SHOULD be used 138 in a message/global-delivery-status Original-Recipient or Final- 139 Recipient DSN field; or in an Original-Recipient header field 140 [RFC3798] if the message is a UTF8SMTP message. 142 In addition, the utf-8-addr-unitext form can be used anywhere where 143 the utf-8-address form is allowed. 145 When using in the ORCPT parameter, the UTF-8 address type requires 146 that US-ASCII CTLs, SP, \, + and = be encoded using xtext encoding as 147 described in [RFC3461]. This is described by the utf-8-addr-xtext 148 form in the ABNF below. Unicode characters MAY be included in a 149 UTF-8 address type using a "\x{HEXPOINT}" syntax 150 (EmbeddedUnicodeChar), where HEXPOINT is 2 to 6 hexadecimal digits. 151 When sending data to a UTF8SMTP capable server, native UTF-8 152 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax 153 described in details below. When sending data to an SMTP server 154 which does not advertise UTF8SMTP, then the EmbeddedUnicodeChar 155 syntax MUST be used instead of UTF-8. 157 When the ORCPT parameter is placed in a message/ 158 global-delivery-status Original-Recipient field, the utf-8-addr-xtext 159 form of the UTF-8 address type SHOULD be converted to the 'utf-8- 160 address' form (see the ABNF below) by removing all xtext encoding 161 first (which will result in the 'utf-8-addr-unitext' form), followed 162 by removal of the 'unitext' encoding. However, if an address is 163 labeled with the UTF-8 address type but does not conform to utf-8 164 syntax, then it MUST be copied into the message/ 165 global-delivery-status field without alteration. 167 The ability to encode characters with the EmbeddedUnicodeChar 168 encodings should be viewed as a transitional mechanism. It is hoped 169 that as systems lacking support for UTF8SMTP become less common over 170 time, these encodings can eventually be phased out. 172 utf-8-type-addr = "utf-8;" utf-8-enc-addr 174 utf-8-address = uMailbox [ 1*WSP "<" Mailbox ">" ] 175 ; 'uMailbox' is defined in [I-D.ietf-eai-smtpext]. 176 ; 'Mailbox' is defined in [RFC2821]. 178 utf-8-enc-addr = utf-8-addr-xtext / 179 utf-8-addr-unitext / 180 utf-8-address 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 ; US-ASCII printable characters except 195 ; CTLs, SP, '\', '+' and '=', plus 196 ; other Unicode characters in UTF-8 198 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 199 ; starts with "\x" 201 HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 202 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 203 ( NZDHEXDIG 3(HEXDIG) ) / 204 ( "D" %x30-37 2(HEXDIG) ) / 205 ; 4 digit forms excluding surrogate 206 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 207 ( "10" 4*HEXDIG ) ; 6 digit forms 208 ; represents either "\" or a Unicode code point outside the 209 ; US-ASCII repertoire 211 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 212 ; HEXDIG excluding 0-7 213 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 214 ; HEXDIG excluding "0" 215 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 216 ; HEXDIG excluding "0" and "D" 218 4. UTF-8 Delivery Status Notifications 220 A traditional delivery status notification [RFC3464] comes in a 221 three-part multipart/report [RFC3462] container, where the first part 222 is human readable text describing the error, the second part is a 223 7-bit-only message/delivery-status and the optional third part is 224 used for content (message/rfc822) or header (text/rfc822-headers) 225 return. As the present DSN format does not permit returning of 226 undeliverable UTF8SMTP messages, three new media types are needed. 228 The first type, message/global-delivery-status has the syntax of 229 message/delivery-status with three modifications. First, the charset 230 for message/global-delivery-status is UTF-8 and thus any field MAY 231 contain UTF-8 characters when appropriate (see the ABNF below). In 232 particular, the Diagnostic-Code field MAY contain UTF-8 as described 233 in UTF8SMTP [I-D.ietf-eai-smtpext]; the Diagnostic-Code field SHOULD 234 be in i-default language [DEFAULTLANG]. Second, systems generating a 235 message/global-delivery-status body part SHOULD use the utf-8-address 236 form of the UTF-8 address type for all addresses containing 237 characters outside the US-ASCII repertoire. These systems SHOULD up- 238 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 239 UTF-8 address type in the ORCPT parameter to the utf-8-address form 240 of a UTF-8 address type in the Original-Recipient field. Third, a 241 new optional field called Localized-Diagnostic is added. Each 242 instance includes a language tag [LANGTAGS] and contains text in the 243 specified language. This is equivalent to the text part of the 244 Diagnostic-Code field. All instances of Localized-Diagnostic MUST 245 use different language tags. The ABNF for message/ 246 global-delivery-status is specified below: 248 utf-8-delivery-status-content = per-message-fields 249 1*( CRLF utf-8-per-recipient-fields ) 250 ; "per-message-fields" remains unchanged from the definition 251 ; in RFC 3464, except for the "extension-field" 252 ; which is updated below. 254 utf-8-per-recipient-fields = 255 [ original-recipient-field CRLF ] 256 final-recipient-field CRLF 257 action-field CRLF 258 status-field CRLF 259 [ remote-mta-field CRLF ] 260 [ diagnostic-code-field CRLF 261 *(localized-diagnostic-text-field CRLF) ] 262 [ last-attempt-date-field CRLF ] 263 [ will-retry-until-field CRLF ] 264 *( extension-field CRLF ) 265 ; All fields except for "original-recipient-field", 266 ; "final-recipient-field", "diagnostic-code-field" 267 ; and "extension-field" remain unchanged from 268 ; the definition in RFC 3464. 270 generic-address =/ utf-8-enc-addr 271 ; Only allowed with the "utf-8" address-type. 272 ; 273 ; This indirectly updates "original-recipient-field" 274 ; and "final-recipient-field" 276 diagnostic-code-field = 277 "Diagnostic-Code" ":" diagnostic-type ";" *text 279 localized-diagnostic-text-field = 280 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 281 ; "Language-Tag" is a language tag as defined in [LANGTAGS]. 283 extension-field =/ extension-field-name ":" *utf8-text 285 text-fixed = %d1-9 / ; Any Unicode character except for NUL, 286 %d11 / ; CR and LF, encoded in UTF-8 287 %d12 / 288 %d14-127 289 ; Same as from RFC 2822, but without . 290 ; If/when RFC 2822 to disallow , this should become 291 ; just 293 utf8-text = text-fixed / UTF8-non-ascii 295 UTF8-non-ascii = UTF2 / UTF3 / UTF4 296 The second type, used for returning the content, is message/global 297 which is similar to message/rfc822, except it contains a message with 298 UTF-8 headers. This media type is described in 299 [I-D.ietf-eai-utf8headers]. 301 The third type, used for returning the headers, is message/ 302 global-headers and contains only the UTF-8 header fields of a message 303 (all lines prior to the first blank line in a UTF8SMTP message). 304 Unlike message/global, this body part provides no difficulties for 305 present infrastructure. 307 Note, that as far as multipart/report [RFC3462] container is 308 concerned, message/global-delivery-status, message/global and 309 message/global-headers MUST be treated as equivalent to message/ 310 delivery-status, message/rfc822 and text/rfc822-headers. I.e. 311 implementations processing multipart/report MUST expect any 312 combinations of the 6 MIME types mentioned above inside a multipart/ 313 report MIME type. 315 All three new types will typically use the "8bit" Content-Transfer- 316 Encoding. (In the event all content is 7-bit, the equivalent 317 traditional types for delivery status notifications MAY be used. For 318 example, if information in message/global-delivery-status part can be 319 represented without any loss of information as message/ 320 delivery-status, then the message/delivery-status body part may be 321 used.) Note that [I-D.ietf-eai-utf8headers] relaxed restriction from 322 MIME [RFC2046] regarding use of Content-Transfer-Encoding in new 323 "message" subtypes. This specification explicitly allows use of 324 Content-Transfer-Encoding in message/global-headers and message/ 325 global-delivery-status. This is not believed to be problematic as 326 these new MIME types are intended primarily for use by newer systems 327 with full support for 8-bit MIME and UTF-8 headers. 329 4.1. Additional requirements on SMTP servers 331 If an SMTP server which advertises both UTF8SMTP and DSN needs to 332 return an undeliverable UTF8SMTP message, then it MUST NOT downgrade 333 [I-D.ietf-eai-downgrade] the UTF8SMTP message when generating the 334 corresponding multipart/report. If the return path SMTP server does 335 not support UTF8SMTP, then the undeliverable body part and headers 336 MUST be encoded using a 7 bit Content-Transfer-Encoding such as 337 base64 or quoted-printable [RFC2045], as detailed in Section 4. 338 Otherwise 8bit Content-Transfer-Encoding can be used. 340 5. UTF-8 Message Disposition Notifications 342 Message Disposition Notifications [RFC3798] have a similar design and 343 structure to DSNs. As a result, they use the same basic return 344 format. When generating a MDN for a UTF-8 header message, the third 345 part of the multipart/report contains the returned content (message/ 346 global) or header (message/global-headers), same as for DSNs. The 347 second part of the multipart/report uses a new media type, message/ 348 global-disposition-notification, which has the syntax of message/ 349 disposition-notification with two modifications. First, the charset 350 for message/global-disposition-notification is UTF-8 and thus any 351 field MAY contain UTF-8 characters when appropriate (see the ABNF 352 below). (In particular, the failure-field, the error-field and the 353 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 354 language [DEFAULTLANG].) Second, systems generating a message/ 355 global-disposition-notification body part (typically a mail user 356 agent) SHOULD use the UTF-8 address type for all addresses containing 357 characters outside the US-ASCII repertoire. 359 The MDN specification also defines the Original-Recipient header 360 field which is added with a copy of the contents of ORCPT at delivery 361 time. When generating an Original-Recipient header field, a delivery 362 agent writing a UTF-8 header message in native format SHOULD convert 363 the utf-8-addr-xtext or the utf-8-addr-unitext form of a UTF-8 364 address type in the ORCPT parameter to the corresponding utf-8- 365 address form. 367 The MDN specification also defines the Disposition-Notification-To 368 header which is an address header and thus follows the same 8-bit 369 rules as other address headers such as "From" and "To" when used in a 370 UTF-8 header message. 372 ; ABNF for "original-recipient-header", "original-recipient-field" 373 ; and "final-recipient-field" from RFC 3798 is implicitly updated 374 ; as they use the updated "generic-address" as defined in 375 ; section 4 of this document. 377 failure-field = "Failure" ":" *utf8-text 378 ; "utf8-text" is defined in section 4 of this document. 380 error-field = "Error" ":" *utf8-text 381 ; "utf8-text" is defined in section 4 of this document. 383 warning-field = "Warning" ":" *utf8-text 384 ; "utf8-text" is defined in section 4 of this document. 386 6. IANA Considerations 388 This specification does not create any new IANA registries. However 389 the following items are registered as a result of this document: 391 6.1. UTF-8 Mail Address Type Registration 393 The mail address type registry was created by RFC 3464. The 394 registration template response follows: 396 (a) The proposed address-type name. 398 UTF-8 400 (b) The syntax for mailbox addresses of this type, specified using 401 BNF, regular expressions, ASN.1, or other non-ambiguous language. 403 See Section 3. 405 (c) If addresses of this type are not composed entirely of graphic 406 characters from the US-ASCII repertoire, a specification for how they 407 are to be encoded as graphic US-ASCII characters in a DSN Original- 408 Recipient or Final-Recipient DSN field. 410 This address type has 3 forms (as defined in Section 3): utf-8-addr- 411 xtext, utf-8-addr-unitext and utf-8-address. The first 2 forms are 412 7-bit safe. 414 The utf-8-address form MUST NOT be used 416 1. in the ORCPT parameter when the SMTP server doesn't advertise 417 support for UTF8SMTP 419 2. or the SMTP server supports UTF8SMTP, but the address contains 420 US-ASCII characters not permitted in the ORCPT parameter (e.g. 421 the ORCPT parameter forbids SP and the = characters); 423 3. or in a 7-bit transport environment including a message/ 424 delivery-status Original-Recipient or Final-Recipient field. 426 The utf-8-addr-xtext form MUST be used instead in the first case, the 427 utf-8-addr-unitext form MUST be used in the other two cases. The 428 utf-8-address form MAY be used in the ORCPT parameter when the SMTP 429 server also advertises support for UTF8SMTP and the address doesn't 430 contain any US-ASCII characters not permitted in the ORCPT parameter; 431 in a message/global-delivery-status Original-Recipient or Final- 432 Recipient DSN field; or in an Original-Recipient header field 433 [RFC3798] if the message is a UTF8SMTP message. 435 In addition, the utf-8-addr-unitext form can be used anywhere where 436 the utf-8-address form is allowed. 438 6.2. Update to 'smtp' Diagnostic Type Registration 440 The mail diagnostic type registry was created by RFC 3464. The 441 registration for the 'smtp' diagnostic type should be updated to 442 reference RFC XXXX in addition to RFC 3464. 444 When the 'smtp' diagnostic type is used in the context of a message/ 445 delivery-status body part, it remains as presently defined. When the 446 'smtp' diagnostic type is used in the context of a message/ 447 global-delivery-status body part, the codes remain the same, but the 448 text portion MAY contain UTF-8 characters. 450 6.3. message/global-headers 452 Type name: message 454 Subtype name: global-headers 456 Required parameters: none 458 Optional parameters: none 460 Encoding considerations: This media type contains Internationalized 461 Email Headers [I-D.ietf-eai-utf8headers] with no message body. 462 Whenever possible, the 8-bit content transfer encoding SHOULD be 463 used. When this media type passes through a 7-bit-only SMTP 464 infrastructure it MAY be encoded with the base64 or quoted- 465 printable content transfer encoding. 467 Security considerations: See Section 7 469 Interoperability considerations: It is important this media type is 470 not converted to a charset other than UTF-8. As a result, 471 implementations MUST NOT include a charset parameter with this 472 media type. Although it might be possible to downconvert this 473 media type to the text/rfc822-header media type, such conversion 474 is discouraged as it loses information. 476 Published specification: RFC XXXX 478 Applications that use this media type: UTF8SMTP servers and email 479 clients that support multipart/report generation or parsing. 481 Additional information: 483 Magic number(s): none 485 File extension(s): In the event this is saved to a file, the 486 extension ".u8hdr" is suggested. 488 Macintosh file type code(s): The 'TEXT' type code is suggested as 489 files of this type are typically used for diagnostic purposes and 490 suitable for analysis in a UTF-8 aware text editor. A uniform 491 type identifier (UTI) of "public.utf8-email-message-header" is 492 suggested. This type conforms to "public.utf8-plain-text" and 493 "public.plain-text". 495 Person & email address to contact for further information: See the 496 Author's address section of this document. 498 Intended usage: COMMON 500 Restrictions on usage: This media type contains textual data in the 501 UTF-8 charset. It typically contains octets with the 8th bit set. 502 As a result a transfer encoding is required when a 7-bit transport 503 is used. 505 Author: See Author's Address section of this document. 507 Change controller: IETF Standards Process 509 6.4. message/global-delivery-status 511 Type name: message 513 Subtype name: global-delivery-status 515 Required parameters: none 517 Optional parameters: none 519 Encoding considerations: This media type contains delivery status 520 notification attributes in the UTF-8 charset. The 8-bit content 521 transfer encoding MUST be used with this content-type, unless it 522 is sent over a 7-bit transport environment in which case quoted- 523 printable or base64 may be necessary. 525 Security considerations: See Section 7 526 Interoperability considerations: This media type provides 527 functionality similar to the message/delivery-status content type 528 for email message return information. Clients of the previous 529 format will need to be upgraded to interpret the new format, 530 however the new media type makes it simple to identify the 531 difference. 533 Published specification: RFC XXXX 535 Applications that use this media type: SMTP servers and email 536 clients that support delivery status notification generation or 537 parsing. 539 Additional information: 541 Magic number(s): none 543 File extension(s): The extension ".u8dsn" is suggested. 545 Macintosh file type code(s): A uniform type identifier (UTI) of 546 "public.utf8-email-message-delivery-status" is suggested. This 547 type conforms to "public.utf8-plain-text". 549 Person & email address to contact for further information: See the 550 Author's address section of this document. 552 Intended usage: COMMON 554 Restrictions on usage: This is expected to be the second part of a 555 multipart/report. 557 Author: See Author's Address section of this document. 559 Change controller: IETF Standards Process 561 6.5. message/global-disposition-notification 563 Type name: message 565 Subtype name: global-disposition-notification 567 Required parameters: none 569 Optional parameters: none 570 Encoding considerations: This media type contains disposition 571 notification attributes in the UTF-8 charset. The 8-bit content 572 transfer encoding MUST be used with this content-type, unless it 573 is sent over a 7-bit transport environment in which case quoted- 574 printable or base64 may be necessary. 576 Security considerations: See Section 7 578 Interoperability considerations: This media type provides 579 functionality similar to the message/disposition-notification 580 content type for email message disposition information. Clients 581 of the previous format will need to be upgraded to interpret the 582 new format, however the new media type makes it simple to identify 583 the difference. 585 Published specification: RFC XXXX 587 Applications that use this media type: Email clients or servers that 588 support message disposition notification generation or parsing. 590 Additional information: 592 Magic number(s): none 594 File extension(s): The extension ".u8mdn" is suggested. 596 Macintosh file type code(s): A uniform type identifier (UTI) of 597 "public.utf8-email-message-disposition-notification" is suggested. 598 This type conforms to "public.utf8-plain-text". 600 Person & email address to contact for further information: See the 601 Author's address section of this document. 603 Intended usage: COMMON 605 Restrictions on usage: This is expected to be the second part of a 606 multipart/report. 608 Author: See Author's Address section of this document. 610 Change controller: IETF Standards Process 612 7. Security Considerations 614 Automated use of report types without authentication presents several 615 security issues. Forging negative reports presents the opportunity 616 for denial-of-service attacks when the reports are used for automated 617 maintenance of directories or mailing lists. Forging positive 618 reports may cause the sender to incorrectly believe a message was 619 delivered when it was not. 621 Malicious users can generate report structures designed to trigger 622 coding flaws in report parsers. Report parsers need to use secure 623 coding techniques to avoid the risk of buffer overflow or denial-of- 624 service attacks against parser coding mistakes. Code reviews of such 625 parsers are also recommended. 627 Malicious users of the email system regularly send messages with 628 forged envelope return paths and these messages trigger delivery 629 status reports that result in a large amount of unwanted traffic on 630 the Internet. Many users choose to ignore delivery status 631 notifications because they are usually the result of "blowback" from 632 forged messages and thus never notice when messages they sent go 633 undelivered. As a result, support for correlation of delivery status 634 and message disposition notification messages with sent-messages has 635 become a critical feature of mail clients and possibly mail stores if 636 the email infrastructure is to remain reliable. In the short term, 637 simply correlating message-IDs may be sufficient to distinguish true 638 status notifications from those resulting from forged originator 639 addresses. But in the longer term, including cryptographic signature 640 material that can securely associate the status notification with the 641 original message is advisable. 643 As this specification permits UTF-8 in additional fields, the 644 security considerations of UTF-8 [RFC3629] apply. 646 8. References 648 8.1. Normative References 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, March 1997. 653 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 654 April 2001. 656 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 657 Extension for Delivery Status Notifications (DSNs)", 658 RFC 3461, January 2003. 660 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 661 Reporting of Mail System Administrative Messages", 662 RFC 3462, January 2003. 664 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 665 for Delivery Status Notifications", RFC 3464, 666 January 2003. 668 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 669 10646", STD 63, RFC 3629, November 2003. 671 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 672 Notification", RFC 3798, May 2004. 674 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 675 Specifications: ABNF", RFC 4234, October 2005. 677 [I-D.ietf-eai-utf8headers] 678 Yang, A., "Internationalized Email Headers", 679 draft-ietf-eai-utf8headers-07 (work in progress), 680 April 2007. 682 [I-D.ietf-eai-smtpext] 683 Yao, J. and W. Mao, "SMTP extension for internationalized 684 email address", draft-ietf-eai-smtpext-09 (work in 685 progress), November 2007. 687 [LANGTAGS] 688 Phillips, A. and M. Davis, "Tags for Identifying 689 Languages", RFC 4646, September 2006. 691 [DEFAULTLANG] 692 Alvestrand, H., "IETF Policy on Character Sets and 693 Languages", RFC 2277, January 1998. 695 8.2. Informative References 697 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 698 Extensions (MIME) Part One: Format of Internet Message 699 Bodies", RFC 2045, November 1996. 701 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 702 Extensions (MIME) Part Two: Media Types", RFC 2046, 703 November 1996. 705 [I-D.ietf-eai-downgrade] 706 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 707 Email Address Internationalization (EAI)", 708 draft-ietf-eai-downgrade-04 (work in progress), Mar 2007. 710 Appendix A. Acknowledgements 712 Many thanks for input provided by Pete Resnick, James Galvin, Ned 713 Freed, John Klensin, Harald Alvestrand, Frank Ellermann and members 714 of the EAI WG to help solidify this proposal. 716 Appendix B. Changes from -04 718 Restructured to be more clear about how it relates to RFC 719 2822 . 721 Appendix C. Changes from -03 723 Addressed editorial comments from Frank Ellermann and 724 sm+ietf@elandsys.com. 726 Moved EAI-downgrade to the Informative References. 728 Updated references. 730 Deleted the list of open issues. 732 Fixed IDnits. 734 Appendix D. Changes from -02 736 Make the space between UTF-8 and ASCII address mandatory. 738 Changed all MIME types to be message/global-*. 740 Clarified that new message/global-* MIME types are semantically 741 equivalent to the corresponding RFC 3464 MIME types. 743 Added a requirement not to downgrade non-delivery reports. 745 Deleted unused RFC 3501 reference and updated other references. 747 Appendix E. Changes from -01 749 Cleaned up and tightened ABNF, in particular HEXPOINT. 751 Extended DSN report syntax to allow for localized version of 752 diagnostic-code-field. 754 Added ABNF for the EAI DSN and EAI MDN. 756 Appendix F. Changes from -00 758 Added paragraph about use of 8bit Content-Transfer-Encoding for new 759 message sub-types. 761 Updated the list of open issues. 763 Clarified that this document is targeted to become an Experimental 764 RFC. 766 Made the EAI downgrade document a normative reference. 768 Updated ABNF for utf-8-address. 770 Authors' Addresses 772 Chris Newman 773 Sun Microsystems 774 3401 Centrelake Dr., Suite 410 775 Ontario, CA 91761 776 US 778 Email: chris.newman@sun.com 780 Alexey Melnikov (editor) 781 Isode Ltd 782 5 Castle Business Village 783 36 Station Road 784 Hampton, Middlesex TW12 2BX 785 UK 787 Email: Alexey.Melnikov@isode.com 789 Full Copyright Statement 791 Copyright (C) The IETF Trust (2007). 793 This document is subject to the rights, licenses and restrictions 794 contained in BCP 78, and except as set forth therein, the authors 795 retain all their rights. 797 This document and the information contained herein are provided on an 798 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 799 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 800 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 801 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 802 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 803 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 805 Intellectual Property 807 The IETF takes no position regarding the validity or scope of any 808 Intellectual Property Rights or other rights that might be claimed to 809 pertain to the implementation or use of the technology described in 810 this document or the extent to which any license under such rights 811 might or might not be available; nor does it represent that it has 812 made any independent effort to identify any such rights. Information 813 on the procedures with respect to rights in RFC documents can be 814 found in BCP 78 and BCP 79. 816 Copies of IPR disclosures made to the IETF Secretariat and any 817 assurances of licenses to be made available, or the result of an 818 attempt made to obtain a general license or permission for the use of 819 such proprietary rights by implementers or users of this 820 specification can be obtained from the IETF on-line IPR repository at 821 http://www.ietf.org/ipr. 823 The IETF invites any interested party to bring to its attention any 824 copyrights, patents or patent applications, or other proprietary 825 rights that may cover technology that may be required to implement 826 this standard. Please address the information to the IETF at 827 ietf-ipr@ietf.org. 829 Acknowledgment 831 Funding for the RFC Editor function is provided by the IETF 832 Administrative Support Activity (IASA).