idnits 2.17.1 draft-ietf-eai-dsn-02.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 750. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 768. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 774. 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 (July 1, 2007) is 6116 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-eai-downgrade' is defined on line 649, but no explicit reference was found in the text == Unused Reference: 'RFC2045' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC3501' is defined on line 668, but no explicit reference was found in the text ** 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-05 == Outdated reference: A later version (-13) exists of draft-ietf-eai-smtpext-05 == Outdated reference: A later version (-12) exists of draft-ietf-eai-downgrade-03 ** Obsolete normative reference: RFC 4646 (ref. 'LANGTAGS') (Obsoleted by RFC 5646) -- Obsolete informational reference (is this intentional?): RFC 3501 (Obsoleted by RFC 9051) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 11 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 July 1, 2007 7 Expires: January 2, 2008 9 International Delivery and Disposition Notifications 10 draft-ietf-eai-dsn-02.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 January 2, 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 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 8 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 63 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 9 64 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 10 65 6.3. message/utf-8-headers . . . . . . . . . . . . . . . . . . 10 66 6.4. message/utf-8-delivery-status . . . . . . . . . . . . . . 11 67 6.5. message/utf-8-disposition-notification . . . . . . . . . . 13 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 73 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 16 74 Appendix C. Changes from -01 . . . . . . . . . . . . . . . . . . 16 75 Appendix D. Changes from -00 . . . . . . . . . . . . . . . . . . 17 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 77 Intellectual Property and Copyright Statements . . . . . . . . . . 18 79 1. Introduction 81 When an email message is transmitted using the UTF8SMTP 82 [I-D.ietf-eai-smtpext] extension and Internationalized Email Headers 83 [I-D.ietf-eai-utf8headers], it is sometimes necessary to return that 84 message or generate a Message Disposition Notification [RFC3798] 85 (MDN). As a message sent to multiple recipients can generate a 86 status and disposition notification for each recipient, it is helpful 87 if a client can correlate these returns based on the recipient 88 address it provided, thus preservation of the original recipient is 89 important. This specification describes how to preserve the original 90 recipient and updates the MDN and DSN formats to support the new 91 address types. 93 2. Conventions Used in this Document 95 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 96 in this document are to be interpreted as defined in "Key words for 97 use in RFCs to Indicate Requirement Levels" [RFC2119]. 99 The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC4234] 100 notation including the core rules defined in Appendix B of RFC 4234 101 and the rules in section 4 of RFC 3629. 103 3. UTF-8 Address Type 105 An Extensible Message Format for Delivery Status Notifications 106 [RFC3464] defines the concept of an address type. The address format 107 introduced in Internationalized Email Headers 108 [I-D.ietf-eai-utf8headers] is a new address type. The syntax for the 109 new address type in the context of status notifications follows: 111 An SMTP [RFC2821] server which advertises both the UTF8SMTP extension 112 [I-D.ietf-eai-smtpext] and the DSN extension [RFC3461] MUST accept a 113 utf-8 address type in the ORCPT parameter including 8-bit UTF-8 114 characters. This address type also includes a 7-bit encoding 115 suitable for use in a message/delivery-status body part or an ORCPT 116 parameter sent to an SMTP server which does not advertise UTF8SMTP. 118 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext 119 and utf-8-address. The first 2 forms are 7-bit safe. 121 The utf-8-address form is only suitable for use in newly defined 122 protocols capable of native representation of 8-bit characters. I.e. 123 the utf-8-address form MUST NOT be used in the ORCPT parameter when 124 the SMTP server doesn't advertise support for UTF8SMTP or the SMTP 125 server supports UTF8SMTP, but the address contains US-ASCII 126 characters not permitted in the ORCPT parameter (e.g. the ORCPT 127 parameter forbids SP and =); or in a 7-bit transport environment 128 including a message/delivery-status Original-Recipient or Final- 129 Recipient field. The utf-8-addr-xtext form (see below) MUST be used 130 instead in the former case, the utf-8-addr-unitext form MUST be used 131 in the latter case. The utf-8-address form MAY be used in the ORCPT 132 parameter when the SMTP server also advertises support for UTF8SMTP 133 and the address doesn't contains any US-ASCII characters not 134 permitted in the ORCPT parameter. It SHOULD be used in a message/ 135 utf-8-delivery-status Original-Recipient or Final-Recipient DSN 136 field; or in an Original-Recipient header field [RFC3798] if the 137 message is a UTF-8 header message. 139 In addition, the utf-8-addr-unitext form can be used anywhere where 140 the utf-8-address form is allowed. 142 When using in the ORCPT parameter, the utf-8 address type requires 143 that US-ASCII CTLs, SP, \, + and = be encoded using xtext encoding as 144 described in [RFC3461]. This is described by the utf-8-addr-xtext 145 form in the ABNF below. Unicode characters MAY be included in a 146 utf-8 address type using a "\x{HEXPOINT}" syntax, where HEXPOINT is 2 147 to 6 hexadecimal digits. When sending data to a UTF8SMTP capable 148 server, native UTF-8 characters SHOULD be used instead of the 149 QMIDCHAR and QHIGHCHAR encodings described below. When sending data 150 to an SMTP server which does not advertise UTF8SMTP, then the 151 QMIDCHAR and QHIGHCHAR encodings MUST be used instead of UTF-8. 153 When the ORCPT parameter is placed in a message/utf-8-delivery-status 154 Original-Recipient field, the utf-8-addr-xtext form of the utf-8 155 address type SHOULD be converted to the 'utf-8-address' form (see the 156 ABNF below) by removing all xtext encoding first (which will result 157 in the 'utf-8-addr-unitext' form), followed by removal of the 158 'unitext' encoding. However, if an address is labeled with the utf-8 159 address type but does not conform to utf-8 syntax, then it MUST be 160 copied into the message/utf-8-delivery-status field without 161 alteration. 163 The ability to encode characters with the EmbeddedUnicodeChar 164 encodings should be viewed as a transitional mechanism. It is hoped 165 that as systems lacking support for UTF8SMTP become less common over 166 time, these encodings can eventually be phased out. 168 utf-8-type-addr = "utf-8;" utf-8-enc-addr 170 utf-8-address = uMailbox [ *WSP "<" Mailbox ">" ] 171 ; 'uMailbox' is defined in [I-D.ietf-eai-smtpext]. 172 ; 'Mailbox' is defined in [RFC2821]. 174 utf-8-enc-addr = utf-8-addr-xtext / 175 utf-8-addr-unitext / 176 utf-8-address 178 ///Add comment about which where each type is used 180 utf-8-addr-xtext = xtext 181 ; xtext is defined in [RFC3461]. 182 ; When xtext encoding is removed, 183 ; the syntax MUST conform to 184 ; 'utf-8-addr-unitext'. 186 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 187 ; MUST follow 'utf-8-address' ABNF when 188 ; dequoted 190 QUCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e / 191 UTF8-2 / UTF8-3 / UTF8-4 192 ; Printable except CTLs, SP, '\', '+' and '=' 194 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 195 ; starts with "\x" 197 HEXPOINT = "5C" / (HEXDIG8 HEXDIG) / ; 2 digit forms 198 ( NZHEXDIG 2(HEXDIG) ) / ; 3 digit forms 199 ( NZDHEXDIG 3(HEXDIG) ) / 200 ( "D" %x30-37 2(HEXDIG) ) / 201 ; 4 digit forms excluding surrogate 202 ( NZHEXDIG 4(HEXDIG) ) / ; 5 digit forms 203 ( "10" 4*HEXDIG ) ; 6 digit forms 204 ; represents either "\" or a Unicode code point outside the 205 ; US-ASCII repertoire 207 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 208 ; HEXDIG excluding 0-7 209 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 210 ; HEXDIG excluding "0" 211 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 212 ; HEXDIG excluding "0" and "D" 214 4. UTF-8 Delivery Status Notifications 216 A traditional delivery status notification [RFC3464] comes in a 217 three-part multipart/report [RFC3462] container, where the first part 218 is human readable text describing the error, the second part is a 219 7-bit-only message/delivery-status and the optional third part is 220 used for content (message/rfc822) or header (text/rfc822-headers) 221 return. An SMTP server which advertises both UTF8SMTP and DSN SHOULD 222 return an undeliverable UTF8SMTP message without downgrading it 223 (assuming the return SMTP server supports UTF8SMTP). As the present 224 DSN format does not permit this, three new media types are needed. 226 The first type, message/utf-8-delivery-status has the syntax of 227 message/delivery-status with three modifications. First, the charset 228 for message/utf-8-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/utf-8-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 utf-8-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/utf-8 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/utf-8-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/utf-8, this 298 body part provides no difficulties for present infrastructure. 300 All three new types will typically use the "8bit" Content-Transfer- 301 Encoding (in the event all content is 7-bit, the equivalent 302 traditional types for delivery status notifications are advised for 303 greater backwards compatibility). While MIME [RFC2046] advises 304 against the use of 8-bit in new message subtypes intended for the 305 email infrastructure, that advice does not apply to these new types 306 which are intended primarily for use by newer systems with full 307 support for 8-bit MIME and UTF-8 headers. 309 5. UTF-8 Message Disposition Notifications 311 Message Disposition Notifications [RFC3798] have a similar design and 312 structure to DSNs. As a result, they use the same basic return 313 format. When generating a MDN for a UTF-8 header message, content or 314 header return is the same as for DSNs. The second part of the 315 multipart/report uses a new media type, message/ 316 utf-8-disposition-notification, which has the syntax of message/ 317 disposition-notification with two modifications. First, the charset 318 for message/utf-8-disposition-notification is UTF-8 and thus any 319 field MAY contain UTF-8 characters when appropriate (see the ABNF 320 below). (In particular, the failure-field, the error-field and the 321 warning-field MAY contain UTF-8. These fields SHOULD be in i-default 322 language [LANGTAGS].) Second, systems generating a message/ 323 utf-8-disposition-notification body part (typically a mail user 324 agent) SHOULD use the utf-8 address type for all addresses containing 325 characters outside the US-ASCII repertoire. 327 The MDN specification also defines the Original-Recipient header 328 field which is added with a copy of the contents of ORCPT at delivery 329 time. When generating an Original-Recipient header field, a delivery 330 agent writing a UTF-8 header message in native format SHOULD convert 331 the utf-8-addr-xtext or the utf-8-addr-unitext form of a utf-8 332 address type in the ORCPT parameter to the corresponding utf-8- 333 address form. 335 The MDN specification also defines the Disposition-Notification-To 336 header which is an address header and thus follows the same 8-bit 337 rules as other address headers such as "From" and "To" when used in a 338 UTF-8 header message. 340 ; ABNF for "original-recipient-header", "original-recipient-field" 341 ; and "final-recipient-field" from RFC 3798 is implicitly updated 342 ; as they use the updated "generic-address" as defined in 343 ; section 4 of this document. 345 failure-field = "Failure" ":" *utf8-text 346 ; "utf8-text" is defined in section 4 of this document. 348 error-field = "Error" ":" *utf8-text 349 ; "utf8-text" is defined in section 4 of this document. 351 warning-field = "Warning" ":" *utf8-text 352 ; "utf8-text" is defined in section 4 of this document. 354 6. IANA Considerations 356 This specification does not create any new IANA registries. However 357 the following items are registered as a result of this document: 359 6.1. UTF-8 Mail Address Type Registration 361 The mail address type registry was created by RFC 3464. The 362 registration template response follows: 364 (a) The proposed address-type name. 366 UTF-8 368 (b) The syntax for mailbox addresses of this type, specified using 369 BNF, regular expressions, ASN.1, or other non-ambiguous language. 371 See Section 3. 373 (c) If addresses of this type are not composed entirely of graphic 374 characters from the US-ASCII repertoire, a specification for how they 375 are to be encoded as graphic US-ASCII characters in a DSN Original- 376 Recipient or Final-Recipient DSN field. 378 This address type has 3 forms (as defined in Section 3): utf-8-addr- 379 xtext, utf-8-addr-unitext and utf-8-address. The first 2 forms are 380 7-bit safe. 382 The utf-8-address form MUST NOT be used in the ORCPT parameter when 383 the SMTP server doesn't advertise support for UTF8SMTP or the SMTP 384 server supports UTF8SMTP, but the address contains US-ASCII 385 characters not permitted in the ORCPT parameter (e.g. the ORCPT 386 parameter forbids SP and =); or in a 7-bit transport environment 387 including a message/delivery-status Original-Recipient or Final- 388 Recipient field. The utf-8-addr-xtext form MUST be used instead in 389 the former case, the utf-8-addr-unitext form MUST be used in the 390 latter case. The utf-8-address form MAY be used in the ORCPT 391 parameter when the SMTP server also advertises support for UTF8SMTP 392 and the address doesn't contains any US-ASCII characters not 393 permitted in the ORCPT parameter; in a message/utf-8-delivery-status 394 Original-Recipient or Final-Recipient DSN field; or an Original- 395 Recipient header field [RFC3798] if the message is a UTF-8 header 396 message. 398 In addition, the utf-8-addr-unitext form can be used anywhere where 399 the utf-8-address form is allowed. 401 6.2. Update to 'smtp' Diagnostic Type Registration 403 The mail diagnostic type registry was created by RFC 3464. The 404 registration for the 'smtp' diagnostic type should be updated to 405 reference RFC XXXX in addition to RFC 3464. 407 When the 'smtp' diagnostic type is used in the context of a message/ 408 delivery-status body part, it remains as presently defined. When the 409 'smtp' diagnostic type is used in the context of a message/ 410 utf-8-delivery-status body part, the codes remain the same, but the 411 text portion MAY contain UTF-8 characters. 413 6.3. message/utf-8-headers 415 Type name: message 417 Subtype name: utf-8-headers 419 Required parameters: none 421 Optional parameters: none 423 Encoding considerations: This media type contains Internationalized 424 Email Headers [I-D.ietf-eai-utf8headers] with no message body. 425 Whenever possible, the 8-bit content transfer encoding SHOULD be 426 used. When this media type passes through a 7-bit-only SMTP 427 infrastructure it MAY be encoded with the base64 or quoted- 428 printable content transfer encoding. 430 Security considerations: See Section 7 431 Interoperability considerations: It is important this media type is 432 not converted to a charset other than UTF-8. As a result, 433 implementations MUST NOT include a charset parameter with this 434 media type. Although it might be possible to downconvert this 435 media type to the text/rfc822-header media type, such conversion 436 is discouraged as it loses information. 438 Published specification: RFC XXXX 440 Applications that use this media type: UTF8SMTP servers and email 441 clients that support multipart/report generation or parsing. 443 Additional information: 445 Magic number(s): none 447 File extension(s): In the event this is saved to a file, the 448 extension ".u8hdr" is suggested. 450 Macintosh file type code(s): The 'TEXT' type code is suggested as 451 files of this type are typically used for diagnostic purposes and 452 suitable for analysis in a UTF-8 aware text editor. A uniform 453 type identifier (UTI) of "public.utf8-email-message-header" is 454 suggested. This type conforms to "public.utf8-plain-text" and 455 "public.plain-text". 457 Person & email address to contact for further information: See the 458 Author's address section of this document. 460 Intended usage: COMMON 462 Restrictions on usage: This media type contains textual data in the 463 UTF-8 charset. It typically contains octets with the 8th bit set. 464 As a result a transfer encoding is required when a 7-bit transport 465 is used. 467 Author: See Author's Address section of this document. 469 Change controller: IETF Standards Process 471 6.4. message/utf-8-delivery-status 473 Type name: message 475 Subtype name: utf-8-delivery-status 476 Required parameters: none 478 Optional parameters: none 480 Encoding considerations: This media type contains delivery status 481 notification attributes in the UTF-8 charset. The 8-bit content 482 transfer encoding MUST be used with this content-type, unless it 483 is sent over a 7-bit transport environment in which case quoted- 484 printable or base64 may be necessary. 486 Security considerations: See Section 7 488 Interoperability considerations: This media type provides 489 functionality similar to the message/delivery-status content type 490 for email message return information. Clients of the previous 491 format will need to be upgraded to interpret the new format, 492 however the new media type makes it simple to identify the 493 difference. 495 Published specification: RFC XXXX 497 Applications that use this media type: SMTP servers and email 498 clients that support delivery status notification generation or 499 parsing. 501 Additional information: 503 Magic number(s): none 505 File extension(s): The extension ".u8dsn" is suggested. 507 Macintosh file type code(s): A uniform type identifier (UTI) of 508 "public.utf8-email-message-delivery-status" is suggested. This 509 type conforms to "public.utf8-plain-text". 511 Person & email address to contact for further information: See the 512 Author's address section of this document. 514 Intended usage: COMMON 516 Restrictions on usage: This is expected to be the second part of a 517 multipart/report. 519 Author: See Author's Address section of this document. 521 Change controller: IETF Standards Process 523 6.5. message/utf-8-disposition-notification 525 Type name: message 527 Subtype name: utf-8-disposition-notification 529 Required parameters: none 531 Optional parameters: none 533 Encoding considerations: This media type contains disposition 534 notification attributes in the UTF-8 charset. The 8-bit content 535 transfer encoding MUST be used with this content-type, unless it 536 is sent over a 7-bit transport environment in which case quoted- 537 printable or base64 may be necessary. 539 Security considerations: See Section 7 541 Interoperability considerations: This media type provides 542 functionality similar to the message/disposition-notification 543 content type for email message disposition information. Clients 544 of the previous format will need to be upgraded to interpret the 545 new format, however the new media type makes it simple to identify 546 the difference. 548 Published specification: RFC XXXX 550 Applications that use this media type: Email clients or servers that 551 support message disposition notification generation or parsing. 553 Additional information: 555 Magic number(s): none 557 File extension(s): The extension ".u8mdn" is suggested. 559 Macintosh file type code(s): A uniform type identifier (UTI) of 560 "public.utf8-email-message-disposition-notification" is suggested. 561 This 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 7. Security Considerations 577 Automated use of report types without authentication presents several 578 security issues. Forging negative reports presents the opportunity 579 for denial-of-service attacks when the reports are used for automated 580 maintenance of directories or mailing lists. Forging positive 581 reports may cause the sender to incorrectly believe a message was 582 delivered when it was not. 584 Malicious users can generate report structures designed to trigger 585 coding flaws in report parsers. Report parsers need to use secure 586 coding techniques to avoid the risk of buffer overflow or denial-of- 587 service attacks against parser coding mistakes. Code reviews of such 588 parsers are also recommended. 590 Malicious users of the email system regularly send messages with 591 forged envelope return paths and these messages trigger delivery 592 status reports that result in a large amount of unwanted traffic on 593 the Internet. Many users choose to ignore delivery status 594 notifications because they are usually the result of "blowback" from 595 forged messages and thus never notice when messages they sent go 596 undelivered. As a result, support for correlation of delivery status 597 and message disposition notification messages with sent-messages has 598 become a critical feature of mail clients and possibly mail stores if 599 the email infrastructure is to remain reliable. In the short term, 600 simply correlating message-IDs may be sufficient to distinguish true 601 status notifications from those resulting from forged originator 602 addresses. But in the longer term, including cryptographic signature 603 material that can securely associate the status notification with the 604 original message is advisable. 606 As this specification permits UTF-8 in additional fields, the 607 security considerations of UTF-8 [RFC3629] apply. 609 8. References 610 8.1. Normative References 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 616 April 2001. 618 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 619 Extension for Delivery Status Notifications (DSNs)", 620 RFC 3461, January 2003. 622 [RFC3462] Vaudreuil, G., "The Multipart/Report Content Type for the 623 Reporting of Mail System Administrative Messages", 624 RFC 3462, January 2003. 626 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 627 for Delivery Status Notifications", RFC 3464, 628 January 2003. 630 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 631 10646", STD 63, RFC 3629, November 2003. 633 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition 634 Notification", RFC 3798, May 2004. 636 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 637 Specifications: ABNF", RFC 4234, October 2005. 639 [I-D.ietf-eai-utf8headers] 640 Yang, A., "Internationalized Email Headers", 641 draft-ietf-eai-utf8headers-05 (work in progress), 642 April 2007. 644 [I-D.ietf-eai-smtpext] 645 Yao, J. and W. Mao, "SMTP extension for internationalized 646 email address", draft-ietf-eai-smtpext-05 (work in 647 progress), April 2007. 649 [I-D.ietf-eai-downgrade] 650 Yoneya, Y. and K. Fujiwara, "Downgrading mechanism for 651 Email Address Internationalization (EAI)", 652 draft-ietf-eai-downgrade-03 (work in progress), Mar 2007. 654 [LANGTAGS] 655 Phillips, A. and M. Davis, "Tags for Identifying 656 Languages", RFC 4646, September 2006. 658 8.2. Informative References 660 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 661 Extensions (MIME) Part One: Format of Internet Message 662 Bodies", RFC 2045, November 1996. 664 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 665 Extensions (MIME) Part Two: Media Types", RFC 2046, 666 November 1996. 668 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 669 4rev1", RFC 3501, March 2003. 671 Appendix A. Acknowledgements 673 Many thanks for input provided by Pete Resnick, James Galvin, Ned 674 Freed, John Klensin and members of the EAI WG to help solidify this 675 proposal. 677 Appendix B. Open Issues 679 Suggestion to change the utf-8-addr format from \-encoded Unicode to 680 \-encoded UTF-8 as used in URIs. 682 Use a single syntax for I18N addresses in ORCPT/DSN instead of two 683 (Chris) 685 Potential issue: an SMTP server can't deliver an EAI DSN to the next 686 hop - need to use a 7bit encoding, downgrade or discard? Need to 687 describe choices. 689 Tracker issue #1485: UTF8HDR 4.6/DSN: Choice of body part for 690 transport of UTF8SMTP messages 692 Tracker issue #1483: SMTPEXT 2.7: Non-ASCII in response texts 694 Appendix C. Changes from -01 696 Cleaned up and tightened ABNF, in particular HEXPOINT. 698 Extended DSN report syntax to allow for localized version of 699 diagnostic-code-field. 701 Added ABNF for the EAI DSN and EAI MDN. 703 Appendix D. Changes from -00 705 Added paragraph about use of 8bit Content-Transfer-Encoding for new 706 message sub-types. 708 Updated the list of open issues. 710 Clarified that this document is targeted to become an Experimental 711 RFC. 713 Made the EAI downgrade document a normative reference. 715 Updated ABNF for utf-8-address. 717 Authors' Addresses 719 Chris Newman 720 Sun Microsystems 721 3401 Centrelake Dr., Suite 410 722 Ontario, CA 91761 723 US 725 Email: chris.newman@sun.com 727 Alexey Melnikov (editor) 728 Isode Ltd 729 5 Castle Business Village 730 36 Station Road 731 Hampton, Middlesex TW12 2BX 732 UK 734 Email: Alexey.Melnikov@isode.com 736 Full Copyright Statement 738 Copyright (C) The IETF Trust (2007). 740 This document is subject to the rights, licenses and restrictions 741 contained in BCP 78, and except as set forth therein, the authors 742 retain all their rights. 744 This document and the information contained herein are provided on an 745 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 746 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 747 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 748 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 749 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 750 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 752 Intellectual Property 754 The IETF takes no position regarding the validity or scope of any 755 Intellectual Property Rights or other rights that might be claimed to 756 pertain to the implementation or use of the technology described in 757 this document or the extent to which any license under such rights 758 might or might not be available; nor does it represent that it has 759 made any independent effort to identify any such rights. Information 760 on the procedures with respect to rights in RFC documents can be 761 found in BCP 78 and BCP 79. 763 Copies of IPR disclosures made to the IETF Secretariat and any 764 assurances of licenses to be made available, or the result of an 765 attempt made to obtain a general license or permission for the use of 766 such proprietary rights by implementers or users of this 767 specification can be obtained from the IETF on-line IPR repository at 768 http://www.ietf.org/ipr. 770 The IETF invites any interested party to bring to its attention any 771 copyrights, patents or patent applications, or other proprietary 772 rights that may cover technology that may be required to implement 773 this standard. Please address the information to the IETF at 774 ietf-ipr@ietf.org. 776 Acknowledgment 778 Funding for the RFC Editor function is provided by the IETF 779 Administrative Support Activity (IASA).