idnits 2.17.1 draft-melnikov-rfc6533bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC6533, but the abstract doesn't seem to mention this, which it should. -- 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. -- The draft header indicates that this document updates RFC3798bis, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 16, 2016) is 2808 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASCII' ** Obsolete normative reference: RFC 3798 (Obsoleted by RFC 8098) -- Obsolete informational reference (is this intentional?): RFC 5337 (Obsoleted by RFC 6533) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Hansen, Ed. 3 Internet-Draft AT&T Laboratories 4 Obsoletes: 6533 (if approved) C. Newman 5 Updates: 3461, 3464, 3798bis, 6522 (if Oracle 6 approved) A. Melnikov 7 Intended status: Standards Track Isode Ltd 8 Expires: February 17, 2017 August 16, 2016 10 Internationalized Delivery Status and Disposition Notifications 11 draft-melnikov-rfc6533bis-02.txt 13 Abstract 15 Delivery status notifications (DSNs) are critical to the correct 16 operation of an email system. However, the existing Draft Standards 17 (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in 18 the machine-readable portions of the protocol. This specification 19 adds a new address type for international email addresses so an 20 original recipient address with non-ASCII characters can be correctly 21 preserved even after downgrading. This also provides updated content 22 return media types for delivery status notifications and message 23 disposition notifications to support use of the new address type. 25 This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 17, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 63 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . 3 64 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6 65 4.1. The message/global-delivery-status Media Type . . . . . . 6 66 4.2. The message/global Media Type . . . . . . . . . . . . . . 9 67 4.3. The message/global-headers Media Type . . . . . . . . . . 9 68 4.4. Using These Media Types with multipart/report . . . . . . 9 69 4.5. Additional Requirements on SMTP Servers . . . . . . . . . 9 70 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 10 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 72 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . 11 73 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11 74 6.3. message/global-headers . . . . . . . . . . . . . . . . . 11 75 6.4. message/global-delivery-status . . . . . . . . . . . . . 13 76 6.5. message/global-disposition-notification . . . . . . . . . 14 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 8.2. Informative References . . . . . . . . . . . . . . . . . 17 81 Appendix A. Changes since RFC 6533 . . . . . . . . . . . . . . . 18 82 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 When an email message is transmitted using the SMTPUTF8 [RFC6531] 88 extension and Internationalized Email Headers [RFC6532], it is 89 sometimes necessary to return that message or generate a Message 90 Disposition Notification (MDN) [RFC3798]. As a message sent to 91 multiple recipients can generate a status and disposition 92 notification for each recipient, it is helpful if a client can 93 correlate these notifications based on the recipient address it 94 provided; thus, preservation of the original recipient is important. 95 This specification describes how to preserve the original recipient 96 and updates the MDN and DSN formats to support the new address types. 98 NOTE: While this specification updates the experimental versions of 99 this protocol by removing certain constructs (e.g., the ">" address syntax is no longer permitted), the name of the 101 Address Type "UTF-8" and the media type names message/global, 102 message/global-delivery-status, and message/global-headers have not 103 been changed. 105 This specification is a revision of and replacement for [RFC5337]. 106 Section 6 of [RFC6530] describes the change in approach between this 107 specification and the previous version. 109 2. Conventions Used in This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 116 [RFC5234] notation including the core rules defined in Appendix B of 117 [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629]. 119 3. UTF-8 Address Type 121 "An Extensible Message Format for Delivery Status Notifications" 122 [RFC3464] defines the concept of an address type. The address format 123 introduced in "Internationalized Email Headers" [RFC6532] is a new 124 address type. The syntax for the new address type in the context of 125 status notifications is specified at the end of this section. 127 An SMTP [RFC5321] server that advertises both the SMTPUTF8 extension 128 [RFC6531] and the DSN extension [RFC3461] MUST accept a UTF-8 address 129 type in the ORCPT parameter including 8-bit UTF-8 characters. This 130 address type also includes a 7-bit encoding suitable for use in a 131 message/delivery-status body part or an ORCPT parameter sent to an 132 SMTP server that does not advertise SMTPUTF8. 134 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, 135 and utf-8-address. Only the first form is 7-bit safe (only uses 136 ASCII characters [ASCII]). 138 The utf-8-address form is only suitable for use in newly defined 139 protocols capable of native representation of 8-bit characters. That 140 is, the utf-8-address form MUST NOT be used: 142 1. in the ORCPT parameter when the SMTP server doesn't advertise 143 support for SMTPUTF8 (utf-8-addr-xtext MUST be used instead); or 145 2. if the SMTP server supports SMTPUTF8, but the address contains 146 ASCII characters not permitted in the ORCPT parameter (e.g., the 147 ORCPT parameter forbids unencoded SP and the '=' character), 148 (either utf-8-addr-unitext or utf-8-addr-xtext MUST be used 149 instead); or 151 3. in a 7-bit transport environment including a message/delivery- 152 status "Original-Recipient:" or "Final-Recipient:" field, 153 (utf-8-addr-xtext MUST be used instead). 155 The utf-8-address form MAY be used in the ORCPT parameter when the 156 SMTP server also advertises support for SMTPUTF8 and the address 157 doesn't contain any ASCII characters not permitted in the ORCPT 158 parameter. It SHOULD be used in a message/global-delivery-status 159 "Original-Recipient:" or "Final-Recipient:" DSN field, or in an 160 "Original-Recipient:" header field [RFC3798] if the message is a 161 SMTPUTF8 message. 163 In addition, the utf-8-addr-unitext form can be used anywhere where 164 the utf-8-address form is allowed. 166 When used in the ORCPT parameter, the UTF-8 address type requires 167 that ASCII CTLs, SP, '\', '+', and '=' be encoded using 'unitext' 168 encoding (see below). This is described by the utf-8-addr-xtext and 169 utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding 170 uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below) 171 for encoding any Unicode character outside of ASCII range, as well as 172 for encoding CTLs, SP, '\', '+', and '='. HEXPOINT is 2 to 6 173 hexadecimal digits. This encoding avoids the need to use the xtext 174 encoding described in [RFC3461], as any ASCII characters that need to 175 be escaped using xtext encoding never appear in any unitext-encoded 176 string. When sending data to a SMTPUTF8-capable server, native UTF-8 177 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax 178 described below. When sending data to an SMTP server that does not 179 advertise SMTPUTF8, then the EmbeddedUnicodeChar syntax MUST be used 180 instead of UTF-8. 182 When the ORCPT parameter is placed in a message/global-delivery- 183 status "Original-Recipient:" field, the utf-8-addr-xtext form of the 184 UTF-8 address type SHOULD be converted to the utf-8-address form (see 185 the ABNF below) by removing the unitext encoding. However, if an 186 address is labeled with the UTF-8 address type but does not conform 187 to utf-8 syntax, then it MUST be copied into the message/global- 188 delivery-status field without alteration. 190 The ability to encode characters with the EmbeddedUnicodeChar 191 encodings should be viewed as a transitional mechanism and avoided 192 when possible. It is hoped that as systems lacking support for 193 SMTPUTF8 become less common over time, these encodings can eventually 194 be phased out. 196 In the ABNF below, all productions not defined in this document are 197 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 198 [RFC3464]. 200 utf-8-type-addr = "utf-8;" utf-8-enc-addr 202 utf-8-address = Mailbox 203 ; Mailbox as defined in [RFC6531]. 205 utf-8-enc-addr = utf-8-addr-xtext / 206 utf-8-addr-unitext / 207 utf-8-address 209 utf-8-addr-xtext = 1*(QCHAR / EmbeddedUnicodeChar) 210 ; 7bit form of utf-8-addr-unitext. 211 ; Safe for use in the ORCPT [RFC3461] 212 ; parameter even when SMTPUTF8 SMTP 213 ; extension is not advertised. 215 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) 216 ; MUST follow utf-8-address ABNF when 217 ; dequoted. 218 ; Safe for using in the ORCPT [RFC3461] 219 ; parameter when SMTPUTF8 SMTP extension 220 ; is also advertised. 222 QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e 223 ; ASCII printable characters except 224 ; CTLs, SP, '\', '+', '='. 226 QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4 227 ; ASCII printable characters except 228 ; CTLs, SP, '\', '+' and '=', plus 229 ; other Unicode characters encoded in UTF-8 231 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}" 232 ; starts with "\x" 234 HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" / 235 "2B" / "3D" / "7F" / ; all xtext-specials 236 "5C" / (HEXDIG8 HEXDIG) / ; 2-digit forms 237 ( NZHEXDIG 2(HEXDIG) ) / ; 3-digit forms 238 ( NZDHEXDIG 3(HEXDIG) ) / ; 4-digit forms excluding 239 ( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate 240 ( NZHEXDIG 4(HEXDIG) ) / ; 5-digit forms 241 ( "10" 4*HEXDIG ) ; 6-digit forms 242 ; represents either "\" or a Unicode code point outside 243 ; the ASCII repertoire 245 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F" 246 ; HEXDIG excluding 0-7 247 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F" 248 ; HEXDIG excluding "0" 249 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F" 250 ; HEXDIG excluding "0" and "D" 252 4. UTF-8 Delivery Status Notifications 254 A traditional delivery status notification [RFC3464] comes in a 255 three-part multipart/report [RFC6522] container, where the first part 256 is human-readable text describing the error, the second part is a 7- 257 bit-only message/delivery-status, and the optional third part is used 258 for content (message/rfc822) or header (text/rfc822-headers) return. 259 As the present standard DSN format does not permit the return of 260 undeliverable SMTPUTF8 messages, three new media types have been 261 defined. ([RFC5337] introduced experimental versions of these media 262 types.) 264 4.1. The message/global-delivery-status Media Type 266 The first type, message/global-delivery-status, has the syntax of 267 message/delivery-status with three modifications. First, the charset 268 for message/global-delivery-status is UTF-8, and thus any field MAY 269 contain UTF-8 characters when appropriate (see the ABNF below). In 270 particular, the "Diagnostic-Code:" field MAY contain UTF-8 as 271 described in SMTPUTF8 [RFC6531]; the "Diagnostic-Code:" field SHOULD 272 be in i-default language [RFC2277]. Second, systems generating a 273 message/global-delivery-status body part SHOULD use the utf-8-address 274 form of the UTF-8 address type for all addresses containing 275 characters outside the ASCII repertoire. These systems SHOULD up- 276 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a 277 UTF-8 address type in the ORCPT parameter to the utf-8-address form 278 of a UTF-8 address type in the "Original-Recipient:" field. Third, 279 an optional field called "Localized-Diagnostic:" is added. Each 280 instance includes a language tag [RFC5646] and contains text in the 281 specified language. This is equivalent to the text part of the 282 "Diagnostic-Code:" field. All instances of "Localized-Diagnostic:" 283 MUST use different language tags. The ABNF for message/global- 284 delivery-status is specified below. 286 In the ABNF below, all productions not defined in this document are 287 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in 288 [RFC3464]. Note that is the same as from 290 [RFC5322], but without . If or when RFC 5322 is updated to 291 disallow , should become just . Also, 292 if or when RFC 5322 is updated to disallow control characters in 293 , should become a reference to that update 294 instead. 296 utf-8-delivery-status-content = per-message-fields 297 1*( CRLF utf-8-per-recipient-fields ) 298 ; "per-message-fields" remains unchanged from the definition 299 ; in RFC 3464, except for the "extension-field", 300 ; which is updated below. 302 utf-8-per-recipient-fields = 303 [ original-recipient-field CRLF ] 304 final-recipient-field CRLF 305 action-field CRLF 306 status-field CRLF 307 [ remote-mta-field CRLF ] 308 [ diagnostic-code-field CRLF 309 *(localized-diagnostic-text-field CRLF) ] 310 [ last-attempt-date-field CRLF ] 311 [ final-log-id-field CRLF ] 312 [ will-retry-until-field CRLF ] 313 *( extension-field CRLF ) 314 ; All fields except for "original-recipient-field", 315 ; "final-recipient-field", "diagnostic-code-field", 316 ; and "extension-field" remain unchanged from 317 ; the definition in RFC 3464. 319 generic-address =/ utf-8-enc-addr 320 ; Only allowed with the "utf-8" address-type. 321 ; Updates Section 3.2.3 of RFC 3798. 322 ; 323 ; This indirectly updates "original-recipient-field" 324 ; and "final-recipient-field". 326 diagnostic-code-field = 327 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed 329 localized-diagnostic-text-field = 330 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text 331 ; "Language-Tag" is a language tag as defined in [RFC5646]. 333 extension-field =/ extension-field-name ":" *utf8-text 334 ; Updates Section 7 of RFC3798 336 text-fixed = %d1-9 / ; Any ASCII character except for NUL, 337 %d11 / ; CR, and LF. 338 %d12 / ; See note above about 339 %d14-127 341 utf8-text = text-fixed / UTF8-non-ascii 343 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 345 4.2. The message/global Media Type 347 The second type, used for returning the content, is message/global, 348 which is similar to message/rfc822, except it contains a message with 349 UTF-8 headers. This media type is described in [RFC6532]. 351 4.3. The message/global-headers Media Type 353 The third type, used for returning the headers, is message/global- 354 headers and contains only the UTF-8 header fields of a message (all 355 lines prior to the first blank line in a SMTPUTF8 message). Unlike 356 message/global, this body part provides no difficulties for the 357 present infrastructure. 359 4.4. Using These Media Types with multipart/report 361 Note that as far as a multipart/report [RFC6522] container is 362 concerned, message/global-delivery-status, message/global, and 363 message/global-headers MUST be treated as equivalent to message/ 364 delivery-status, message/rfc822, and text/rfc822-headers. That is, 365 implementations processing multipart/report MUST expect any 366 combinations of the 6 media types mentioned above inside a multipart/ 367 report media type. 369 All three new types will typically use the "8bit" Content-Transfer- 370 Encoding. (In the event all content is 7-bit, the equivalent 371 traditional types for delivery status notifications MAY be used. For 372 example, if information in a message/global-delivery-status part can 373 be represented without any loss of information as message/delivery- 374 status, then the message/delivery-status body part may be used.) 375 Note that [RFC6532] relaxed a restriction from MIME [RFC2046] 376 regarding the use of Content-Transfer-Encoding in new "message" 377 subtypes. This specification explicitly allows the use of Content- 378 Transfer-Encoding in message/global-headers and message/global- 379 delivery-status. This is not believed to be problematic as these new 380 media types are intended primarily for use by newer systems with full 381 support for 8-bit MIME and UTF-8 headers. 383 4.5. Additional Requirements on SMTP Servers 385 If an SMTP server that advertises both SMTPUTF8 and DSN needs to 386 return an undeliverable SMTPUTF8 message, then it has two choices for 387 encapsulating the SMTPUTF8 message when generating the corresponding 388 multipart/report: 390 If the return-path SMTP server does not support SMTPUTF8, then the 391 undeliverable body part and headers MUST be encoded using a 7-bit 392 Content-Transfer-Encoding such as "base64" or "quoted-printable" 393 [RFC2045], as detailed in Section 4. 395 Otherwise, "8bit" Content-Transfer-Encoding can be used. 397 5. UTF-8 Message Disposition Notifications 399 Message Disposition Notifications [RFC3798] have a similar design and 400 structure to DSNs. As a result, they use the same basic return 401 format. When generating an MDN for a UTF-8 header message, the third 402 part of the multipart/report contains the returned content (message/ 403 global) or header (message/global-headers), same as for DSNs. The 404 second part of the multipart/report uses a new media type, message/ 405 global-disposition-notification, which has the syntax of message/ 406 disposition-notification with two modifications. First, the charset 407 for message/global-disposition-notification is UTF-8, and thus any 408 field MAY contain UTF-8 characters when appropriate (see the ABNF 409 below). (In particular, the extension-field, and the error-field MAY 410 contain UTF-8. These fields SHOULD be in i-default language 411 [RFC2277].) Second, systems generating a message/global-disposition- 412 notification body part (typically a mail user agent) SHOULD use the 413 UTF-8 address type for all addresses containing characters outside 414 the ASCII repertoire. 416 The MDN specification also defines the "Original-Recipient:" header 417 field, which is added with a copy of the contents of ORCPT at 418 delivery time. When generating an "Original-Recipient:" header 419 field, a delivery agent writing a UTF-8 header message in native 420 format SHOULD convert the utf-8-addr-xtext or the utf-8-addr-unitext 421 form of a UTF-8 address type in the ORCPT parameter to the 422 corresponding utf-8-address form. 424 The MDN specification also defines the "Disposition-Notification-To:" 425 header field, which is an address header field and thus follows the 426 same 8-bit rules as other address header fields such as "From:" and 427 "To:" when used in a UTF-8 header message. 429 ; ABNF for "original-recipient-header", "original-recipient-field", 430 ; and "final-recipient-field" from RFC 3798 is implicitly updated 431 ; as they use the updated "generic-address" as defined in 432 ; Section 4 of this document. 434 error-field = "Error" ":" *([FWS] utf8-text) 435 ; "utf8-text" is defined in Section 4 of this document. 437 extension-field =/ extension-field-name ":" *([FWS] utf8-text) 438 ; Updates Section 7 of RFC3798 440 6. IANA Considerations 442 This specification does not create any new IANA registries. However, 443 the following items have been registered as a result of this 444 document. 446 6.1. UTF-8 Mail Address Type Registration 448 The mail address type registry was created by [RFC3464]. The 449 registration template response follows: 451 (a) The address-type name. 453 UTF-8 455 (b) The syntax for mailbox addresses of this type, specified using 456 BNF, regular expressions, ASN.1, or other non-ambiguous language. 458 See Section 3. 460 (c) If addresses of this type are not composed entirely of graphic 461 characters from the ASCII repertoire, a specification for how 462 they are to be encoded as graphic ASCII characters in an 463 "Original-Recipient:" or "Final-Recipient:" DSN field. 465 This address type has 3 forms (as defined in Section 3): 466 utf-8-addr-xtext, utf-8-addr-unitext, and utf-8-address. Only 467 the first form is 7-bit safe. 469 6.2. Update to 'smtp' Diagnostic Type Registration 471 The mail diagnostic type registry was created by [RFC3464] and 472 updated by [RFC5337]. This specification replaces [RFC5337]. The 473 registration for the 'smtp' diagnostic type has been updated to 474 reference RFC XXXX in addition to [RFC3464] and to remove the 475 reference to [RFC5337]. 477 When the 'smtp' diagnostic type is used in the context of a message/ 478 delivery-status body part, it remains as presently defined. When the 479 'smtp' diagnostic type is used in the context of a message/global- 480 delivery-status body part, the codes remain the same, but the text 481 portion MAY contain UTF-8 characters. 483 6.3. message/global-headers 485 Type name: message 487 Subtype name: global-headers 488 Required parameters: none 490 Optional parameters: none 492 Encoding considerations: This media type contains Internationalized 493 Email Headers [RFC6532] with no message body. Whenever possible, 494 the 8-bit content transfer encoding SHOULD be used. When this 495 media type passes through a 7-bit-only SMTP infrastructure, it MAY 496 be encoded with the base64 or quoted-printable content transfer 497 encoding. 499 Security considerations: See Section 7. 501 Interoperability considerations: It is important that this media 502 type is not converted to a charset other than UTF-8. As a result, 503 implementations MUST NOT include a charset parameter with this 504 media type. Although it might be possible to down-convert this 505 media type to the text/rfc822-header media type, such conversion 506 is discouraged as it loses information. 508 Published specification: RFC XXXX 510 Applications that use this media type: SMTPUTF8 servers and email 511 clients that support multipart/report generation or parsing. 513 Additional information: 515 Magic number(s): none 517 File extension(s): In the event this is saved to a file, the 518 extension ".u8hdr" is suggested. 520 Macintosh file type code(s): The 'TEXT' type code is suggested as 521 files of this type are typically used for diagnostic purposes 522 and suitable for analysis in a UTF-8-aware text editor. A 523 uniform type identifier (UTI) of 524 "public.utf8-email-message-header" is suggested. This type 525 conforms to "public.utf8-plain-text" and "public.plain-text". 527 Person & email address to contact for further information: See the 528 Authors' Addresses section of this document. 530 Intended usage: COMMON 532 Restrictions on usage: This media type contains textual data in the 533 UTF-8 charset. It typically contains octets with the 8th bit set. 534 As a result, a transfer encoding is required when a 7-bit 535 transport is used. 537 Author: See the Authors' Addresses section of this document. 539 Change controller: IETF Standards Process 541 6.4. message/global-delivery-status 543 Type name: message 545 Subtype name: global-delivery-status 547 Required parameters: none 549 Optional parameters: none 551 Encoding considerations: This media type contains delivery status 552 notification attributes in the UTF-8 charset. The 8-bit content 553 transfer encoding MUST be used with this content-type, unless it 554 is sent over a 7-bit transport environment, in which case quoted- 555 printable or base64 may be necessary. 557 Security considerations: See Section 7 559 Interoperability considerations: This media type provides 560 functionality similar to the message/delivery-status content-type 561 for email message return information. Clients of the previous 562 format will need to be upgraded to interpret the new format; 563 however, the new media type makes it simple to identify the 564 difference. 566 Published specification: RFC XXXX 568 Applications that use this media type: SMTP servers and email 569 clients that support delivery status notification generation or 570 parsing. 572 Additional information: 574 Magic number(s): none 576 File extension(s): The extension ".u8dsn" is suggested. 578 Macintosh file type code(s): A uniform type identifier (UTI) of 579 "public.utf8-email-message-delivery-status" is suggested. This 580 type conforms to "public.utf8-plain-text". 582 Person & email address to contact for further information: See the 583 Authors' Addresses section of this document. 585 Intended usage: COMMON 587 Restrictions on usage: This is expected to be the second part of a 588 multipart/report. 590 Author: See the Authors' Addresses section of this document. 592 Change controller: IETF Standards Process 594 6.5. message/global-disposition-notification 596 Type name: message 598 Subtype name: global-disposition-notification 600 Required parameters: none 602 Optional parameters: none 604 Encoding considerations: This media type contains disposition 605 notification attributes in the UTF-8 charset. The 8-bit content 606 transfer encoding MUST be used with this content-type, unless it 607 is sent over a 7-bit transport environment, in which case quoted- 608 printable or base64 may be necessary. 610 Security considerations: See Section 7. 612 Interoperability considerations: This media type provides 613 functionality similar to the message/disposition-notification 614 content-type for email message disposition information. Clients 615 of the previous format will need to be upgraded to interpret the 616 new format; however, the new media type makes it simple to 617 identify the difference. 619 Published specification: RFC XXXX 621 Applications that use this media type: Email clients or servers that 622 support message disposition notification generation or parsing. 624 Additional information: 626 Magic number(s): none 628 File extension(s): The extension ".u8mdn" is suggested. 630 Macintosh file type code(s): A uniform type identifier (UTI) of 631 "public.utf8-email-message-disposition-notification" is 632 suggested. This type conforms to "public.utf8-plain-text". 634 Person & email address to contact for further information: See the 635 Authors' Addresses section of this document. 637 Intended usage: COMMON 639 Restrictions on usage: This is expected to be the second part of a 640 multipart/report. 642 Author: See the Authors' Addresses section of this document. 644 Change controller: IETF Standards Process 646 7. Security Considerations 648 Automated use of report types without authentication presents several 649 security issues. Forging negative reports presents the opportunity 650 for denial-of-service attacks when the reports are used for automated 651 maintenance of directories or mailing lists. Forging positive 652 reports may cause the sender to incorrectly believe a message was 653 delivered when it was not. 655 Malicious users can generate report structures designed to trigger 656 coding flaws in report parsers. Report parsers need to use secure 657 coding techniques to avoid the risk of buffer overflow or denial-of- 658 service attacks against parser coding mistakes. Code reviews of such 659 parsers are also recommended. 661 Malicious users of the email system regularly send messages with 662 forged envelope return paths, and these messages trigger delivery 663 status reports that result in a large amount of unwanted traffic on 664 the Internet. Many users choose to ignore delivery status 665 notifications because they are usually the result of "blowback" from 666 forged messages and thus never notice when messages they sent go 667 undelivered. As a result, support for correlation of delivery status 668 and message disposition notification messages with sent messages has 669 become a critical feature of mail clients and possibly mail stores, 670 if the email infrastructure is to remain reliable. In the short 671 term, simply correlating Message-IDs may be sufficient to distinguish 672 true status notifications from those resulting from forged originator 673 addresses. But in the longer term, including cryptographic signature 674 material that can securely associate the status notification with the 675 original message is advisable. 677 As this specification permits UTF-8 in additional fields, the 678 security considerations of UTF-8 [RFC3629] apply. 680 8. References 682 8.1. Normative References 684 [ASCII] American National Standards Institute (formerly United 685 States of America Standards Institute), "USA Code for 686 Information Interchange", ANSI X3.4-1968, 1968. 688 ANSI X3.4-1968 has been replaced by newer versions with 689 slight modifications, but the 1968 version remains 690 definitive for the Internet. 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, 694 DOI 10.17487/RFC2119, March 1997, 695 . 697 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 698 Languages", BCP 18, RFC 2277, DOI 10.17487/RFC2277, 699 January 1998, . 701 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service 702 Extension for Delivery Status Notifications (DSNs)", 703 RFC 3461, DOI 10.17487/RFC3461, January 2003, 704 . 706 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format 707 for Delivery Status Notifications", RFC 3464, 708 DOI 10.17487/RFC3464, January 2003, 709 . 711 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 712 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 713 2003, . 715 [RFC3798] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message 716 Disposition Notification", RFC 3798, DOI 10.17487/RFC3798, 717 May 2004, . 719 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 720 Specifications: ABNF", STD 68, RFC 5234, 721 DOI 10.17487/RFC5234, January 2008, 722 . 724 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 725 DOI 10.17487/RFC5321, October 2008, 726 . 728 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 729 DOI 10.17487/RFC5322, October 2008, 730 . 732 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 733 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 734 September 2009, . 736 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for 737 the Reporting of Mail System Administrative Messages", 738 STD 73, RFC 6522, DOI 10.17487/RFC6522, January 2012, 739 . 741 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for 742 Internationalized Email", RFC 6530, February 2012. 744 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized 745 Email", RFC 6531, February 2012. 747 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized 748 Email Headers", RFC 6532, February 2012. 750 8.2. Informative References 752 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 753 Extensions (MIME) Part One: Format of Internet Message 754 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 755 . 757 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 758 Extensions (MIME) Part Two: Media Types", RFC 2046, 759 DOI 10.17487/RFC2046, November 1996, 760 . 762 [RFC5337] Newman, C. and A. Melnikov, Ed., "Internationalized 763 Delivery Status and Disposition Notifications", RFC 5337, 764 DOI 10.17487/RFC5337, September 2008, 765 . 767 Appendix A. Changes since RFC 6533 769 Because the warning disposition modifier was previously removed in 770 RFC 3798, warning-field has also been removed from this 771 specification. 773 failure-field was removed to match a change in RFC 3798bis. 775 extension-field was updated to allow for FWS, to match RFC 3798bis. 777 Other minor corrections. 779 Appendix B. Acknowledgements 781 TBD 783 Authors' Addresses 785 Tony Hansen (editor) 786 AT&T Laboratories 787 200 Laurel Ave. 788 Middletown, NJ 07748 789 US 791 EMail: tony@att.com 793 Chris Newman 794 Oracle 795 800 Royal Oaks 796 Monrovia, CA 91016-6347 797 US 799 EMail: chris.newman@oracle.com 801 Alexey Melnikov 802 Isode Ltd 803 5 Castle Business Village 804 36 Station Road 805 Hampton, Middlesex TW12 2BX 806 UK 808 EMail: Alexey.Melnikov@isode.com