7Internet Engineering Task Force (IETF) T. Hansen, Ed.
8Request for Comments: 6533 AT&T Laboratories
9Obsoletes: 5337 C. Newman
10Updates: 3461, 3464, 3798, 6522 Oracle
11Category: Standards Track A. Melnikov
12ISSN: 2070-1721 Isode Ltd
16 Internationalized Delivery Status and Disposition Notifications
20 Delivery status notifications (DSNs) are critical to the correct
21 operation of an email system. However, the existing Draft Standards
22 (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in
23 the machine-readable portions of the protocol. This specification
24 adds a new address type for international email addresses so an
25 original recipient address with non-ASCII characters can be correctly
26 preserved even after downgrading. This also provides updated content
27 return media types for delivery status notifications and message
28 disposition notifications to support use of the new address type.
30 This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522.
34 This is an Internet Standards Track document.
36 This document is a product of the Internet Engineering Task Force
37 (IETF). It represents the consensus of the IETF community. It has
38 received public review and has been approved for publication by the
39 Internet Engineering Steering Group (IESG). Further information on
40 Internet Standards is available in Section 2 of RFC 5741.
42 Information about the current status of this document, any errata,
43 and how to provide feedback on it may be obtained at
44 http://www.rfc-editor.org/info/rfc6533.
58Hansen, et al. Standards Track [Page 1]
60RFC 6533 Internationalized DSN and MDNs February 2012
65 Copyright (c) 2012 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
81 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
82 3. UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . . 3
83 4. UTF-8 Delivery Status Notifications . . . . . . . . . . . . . 6
84 4.1. The message/global-delivery-status Media Type . . . . . . 6
85 4.2. The message/global Media Type . . . . . . . . . . . . . . 8
86 4.3. The message/global-headers Media Type . . . . . . . . . . 8
87 4.4. Using These Media Types with multipart/report . . . . . . 8
88 4.5. Additional Requirements on SMTP Servers . . . . . . . . . 9
89 5. UTF-8 Message Disposition Notifications . . . . . . . . . . . 9
90 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
91 6.1. UTF-8 Mail Address Type Registration . . . . . . . . . . . 10
92 6.2. Update to 'smtp' Diagnostic Type Registration . . . . . . 11
93 6.3. message/global-headers . . . . . . . . . . . . . . . . . . 11
94 6.4. message/global-delivery-status . . . . . . . . . . . . . . 12
95 6.5. message/global-disposition-notification . . . . . . . . . 14
96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
99 8.2. Informative References . . . . . . . . . . . . . . . . . . 17
100 Appendix A. Changes since RFC 5337 . . . . . . . . . . . . . . . 18
101 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18
114Hansen, et al. Standards Track [Page 2]
116RFC 6533 Internationalized DSN and MDNs February 2012
121 When an email message is transmitted using the SMTPUTF8 [RFC6531]
122 extension and Internationalized Email Headers [RFC6532], it is
123 sometimes necessary to return that message or generate a Message
124 Disposition Notification (MDN) [RFC3798]. As a message sent to
125 multiple recipients can generate a status and disposition
126 notification for each recipient, it is helpful if a client can
127 correlate these notifications based on the recipient address it
128 provided; thus, preservation of the original recipient is important.
129 This specification describes how to preserve the original recipient
130 and updates the MDN and DSN formats to support the new address types.
132 NOTE: While this specification updates the experimental versions of
133 this protocol by removing certain constructs (e.g., the "<addr
134 <addr>>" address syntax is no longer permitted), the name of the
135 Address Type "UTF-8" and the media type names message/global,
136 message/global-delivery-status, and message/global-headers have not
139 This specification is a revision of and replacement for [RFC5337].
140 Section 6 of [RFC6530] describes the change in approach between this
141 specification and the previous version.
1432. Conventions Used in This Document
145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
147 document are to be interpreted as described in [RFC2119].
149 The formal syntax uses the Augmented Backus-Naur Form (ABNF)
150 [RFC5234] notation including the core rules defined in Appendix B of
151 [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629].
155 "An Extensible Message Format for Delivery Status Notifications"
156 [RFC3464] defines the concept of an address type. The address format
157 introduced in "Internationalized Email Headers" [RFC6532] is a new
158 address type. The syntax for the new address type in the context of
159 status notifications is specified at the end of this section.
161 An SMTP [RFC5321] server that advertises both the SMTPUTF8 extension
162 [RFC6531] and the DSN extension [RFC3461] MUST accept a UTF-8 address
163 type in the ORCPT parameter including 8-bit UTF-8 characters. This
164 address type also includes a 7-bit encoding suitable for use in a
165 message/delivery-status body part or an ORCPT parameter sent to an
166 SMTP server that does not advertise SMTPUTF8.
170Hansen, et al. Standards Track [Page 3]
172RFC 6533 Internationalized DSN and MDNs February 2012
175 This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext,
176 and utf-8-address. Only the first form is 7-bit safe (only uses
177 ASCII characters [ASCII]).
179 The utf-8-address form is only suitable for use in newly defined
180 protocols capable of native representation of 8-bit characters. That
181 is, the utf-8-address form MUST NOT be used:
183 1. in the ORCPT parameter when the SMTP server doesn't advertise
184 support for SMTPUTF8 (utf-8-addr-xtext MUST be used instead); or
186 2. if the SMTP server supports SMTPUTF8, but the address contains
187 ASCII characters not permitted in the ORCPT parameter (e.g., the
188 ORCPT parameter forbids unencoded SP and the '=' character),
189 (either utf-8-addr-unitext or utf-8-addr-xtext MUST be used
192 3. in a 7-bit transport environment including a message/
193 delivery-status "Original-Recipient:" or "Final-Recipient:"
194 field, (utf-8-addr-xtext MUST be used instead).
196 The utf-8-address form MAY be used in the ORCPT parameter when the
197 SMTP server also advertises support for SMTPUTF8 and the address
198 doesn't contain any ASCII characters not permitted in the ORCPT
199 parameter. It SHOULD be used in a message/global-delivery-status
200 "Original-Recipient:" or "Final-Recipient:" DSN field, or in an
201 "Original-Recipient:" header field [RFC3798] if the message is a
204 In addition, the utf-8-addr-unitext form can be used anywhere where
205 the utf-8-address form is allowed.
207 When used in the ORCPT parameter, the UTF-8 address type requires
208 that ASCII CTLs, SP, '\', '+', and '=' be encoded using 'unitext'
209 encoding (see below). This is described by the utf-8-addr-xtext and
210 utf-8-addr-unitext forms in the ABNF below. The 'unitext' encoding
211 uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below)
212 for encoding any Unicode character outside of ASCII range, as well as
213 for encoding CTLs, SP, '\', '+', and '='. HEXPOINT is 2 to 6
214 hexadecimal digits. This encoding avoids the need to use the xtext
215 encoding described in [RFC3461], as any ASCII characters that need to
216 be escaped using xtext encoding never appear in any unitext-encoded
217 string. When sending data to a SMTPUTF8-capable server, native UTF-8
218 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax
219 described below. When sending data to an SMTP server that does not
220 advertise SMTPUTF8, then the EmbeddedUnicodeChar syntax MUST be used
226Hansen, et al. Standards Track [Page 4]
228RFC 6533 Internationalized DSN and MDNs February 2012
231 When the ORCPT parameter is placed in a message/
232 global-delivery-status "Original-Recipient:" field, the
233 utf-8-addr-xtext form of the UTF-8 address type SHOULD be converted
234 to the utf-8-address form (see the ABNF below) by removing the
235 unitext encoding. However, if an address is labeled with the UTF-8
236 address type but does not conform to utf-8 syntax, then it MUST be
237 copied into the message/global-delivery-status field without
240 The ability to encode characters with the EmbeddedUnicodeChar
241 encodings should be viewed as a transitional mechanism and avoided
242 when possible. It is hoped that as systems lacking support for
243 SMTPUTF8 become less common over time, these encodings can eventually
246 In the ABNF below, all productions not defined in this document are
247 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
252 utf-8-address = Mailbox
253 ; Mailbox as defined in [RFC6531].
255 utf-8-enc-addr = utf-8-addr-xtext /
260 ; 7bit form of utf-8-addr-unitext.
261 ; Safe for use in the ORCPT [RFC3461]
262 ; parameter even when SMTPUTF8 SMTP
263 ; extension is not advertised.
265 utf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar)
266 ; MUST follow utf-8-address ABNF when
268 ; Safe for using in the ORCPT [RFC3461]
269 ; parameter when SMTPUTF8 SMTP extension
270 ; is also advertised.
272 QCHAR = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e
273 ; ASCII printable characters except
274 ; CTLs, SP, '\', '+', '='.
282Hansen, et al. Standards Track [Page 5]
284RFC 6533 Internationalized DSN and MDNs February 2012
287 QUCHAR = QCHAR / UTF8-2 / UTF8-3 / UTF8-4
288 ; ASCII printable characters except
289 ; CTLs, SP, '\', '+' and '=', plus
290 ; other Unicode characters encoded in UTF-8
292 EmbeddedUnicodeChar = %x5C.78 "{" HEXPOINT "}"
295 HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" /
296 "2B" / "3D" / "7F" / ; all xtext-specials
297 "5C" / (HEXDIG8 HEXDIG) / ; 2-digit forms
298 ( NZHEXDIG 2(HEXDIG) ) / ; 3-digit forms
299 ( NZDHEXDIG 3(HEXDIG) ) / ; 4-digit forms excluding
300 ( "D" %x30-37 2(HEXDIG) ) / ; ... surrogate
301 ( NZHEXDIG 4(HEXDIG) ) / ; 5-digit forms
302 ( "10" 4*HEXDIG ) ; 6-digit forms
303 ; represents either "\" or a Unicode code point outside
304 ; the ASCII repertoire
306 HEXDIG8 = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F"
307 ; HEXDIG excluding 0-7
308 NZHEXDIG = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F"
309 ; HEXDIG excluding "0"
310 NZDHEXDIG = %x31-39 / "A" / "B" / "C" / "E" / "F"
311 ; HEXDIG excluding "0" and "D"
3134. UTF-8 Delivery Status Notifications
315 A traditional delivery status notification [RFC3464] comes in a
316 three-part multipart/report [RFC6522] container, where the first part
317 is human-readable text describing the error, the second part is a
318 7-bit-only message/delivery-status, and the optional third part is
319 used for content (message/rfc822) or header (text/rfc822-headers)
320 return. As the present standard DSN format does not permit the
321 return of undeliverable SMTPUTF8 messages, three new media types have
322 been defined. ([RFC5337] introduced experimental versions of these
327 The first type, message/global-delivery-status, has the syntax of
328 message/delivery-status with three modifications. First, the charset
329 for message/global-delivery-status is UTF-8, and thus any field MAY
330 contain UTF-8 characters when appropriate (see the ABNF below). In
331 particular, the "Diagnostic-Code:" field MAY contain UTF-8 as
332 described in SMTPUTF8 [RFC6531]; the "Diagnostic-Code:" field SHOULD
333 be in i-default language [RFC2277]. Second, systems generating a
334 message/global-delivery-status body part SHOULD use the utf-8-address
338Hansen, et al. Standards Track [Page 6]
340RFC 6533 Internationalized DSN and MDNs February 2012
343 form of the UTF-8 address type for all addresses containing
344 characters outside the ASCII repertoire. These systems SHOULD up-
345 convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a
346 UTF-8 address type in the ORCPT parameter to the utf-8-address form
347 of a UTF-8 address type in the "Original-Recipient:" field. Third,
348 an optional field called "Localized-Diagnostic:" is added. Each
349 instance includes a language tag [RFC5646] and contains text in the
350 specified language. This is equivalent to the text part of the
351 "Diagnostic-Code:" field. All instances of "Localized-Diagnostic:"
352 MUST use different language tags. The ABNF for message/
353 global-delivery-status is specified below.
355 In the ABNF below, all productions not defined in this document are
356 defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
357 [RFC3464]. Note that <text-fixed> is the same as <text> from
358 [RFC5322], but without <obs-text>. If or when RFC 5322 is updated to
359 disallow <obs-text>, <text-fixed> should become just <text>. Also,
360 if or when RFC 5322 is updated to disallow control characters in
361 <text>, <text-fixed> should become a reference to that update
364 utf-8-delivery-status-content = per-message-fields
365 1*( CRLF utf-8-per-recipient-fields )
367 ; in RFC 3464, except for the "extension-field",
368 ; which is updated below.
371 [ original-recipient-field CRLF ]
372 final-recipient-field CRLF
375 [ remote-mta-field CRLF ]
376 [ diagnostic-code-field CRLF
377 *(localized-diagnostic-text-field CRLF) ]
378 [ last-attempt-date-field CRLF ]
379 [ final-log-id-field CRLF ]
380 [ will-retry-until-field CRLF ]
381 *( extension-field CRLF )
382 ; All fields except for "original-recipient-field",
383 ; "final-recipient-field", "diagnostic-code-field",
384 ; and "extension-field" remain unchanged from
385 ; the definition in RFC 3464.
394Hansen, et al. Standards Track [Page 7]
396RFC 6533 Internationalized DSN and MDNs February 2012
399 generic-address =/ utf-8-enc-addr
400 ; Only allowed with the "utf-8" address-type.
401 ; Updates Section 3.2.3 of RFC 3798.
403 ; This indirectly updates "original-recipient-field"
404 ; and "final-recipient-field".
406 diagnostic-code-field =
407 "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed
409 localized-diagnostic-text-field =
410 "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text
411 ; "Language-Tag" is a language tag as defined in [RFC5646].
413 extension-field =/ extension-field-name ":" *utf8-text
414 ; Updates Section 7 of RFC3798
416 text-fixed = %d1-9 / ; Any ASCII character except for NUL,
418 %d12 / ; See note above about <text-fixed>
421 utf8-text = text-fixed / UTF8-non-ascii
423 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
4254.2. The message/global Media Type
427 The second type, used for returning the content, is message/global,
428 which is similar to message/rfc822, except it contains a message with
429 UTF-8 headers. This media type is described in [RFC6532].
433 The third type, used for returning the headers, is message/
434 global-headers and contains only the UTF-8 header fields of a message
435 (all lines prior to the first blank line in a SMTPUTF8 message).
436 Unlike message/global, this body part provides no difficulties for
437 the present infrastructure.
4394.4. Using These Media Types with multipart/report
442 concerned, message/global-delivery-status, message/global, and
443 message/global-headers MUST be treated as equivalent to message/
444 delivery-status, message/rfc822, and text/rfc822-headers. That is,
450Hansen, et al. Standards Track [Page 8]
452RFC 6533 Internationalized DSN and MDNs February 2012
455 implementations processing multipart/report MUST expect any
456 combinations of the 6 media types mentioned above inside a multipart/
459 All three new types will typically use the "8bit" Content-Transfer-
460 Encoding. (In the event all content is 7-bit, the equivalent
461 traditional types for delivery status notifications MAY be used. For
462 example, if information in a message/global-delivery-status part can
463 be represented without any loss of information as message/
464 delivery-status, then the message/delivery-status body part may be
465 used.) Note that [RFC6532] relaxed a restriction from MIME [RFC2046]
466 regarding the use of Content-Transfer-Encoding in new "message"
467 subtypes. This specification explicitly allows the use of Content-
468 Transfer-Encoding in message/global-headers and message/
469 global-delivery-status. This is not believed to be problematic as
470 these new media types are intended primarily for use by newer systems
471 with full support for 8-bit MIME and UTF-8 headers.
4734.5. Additional Requirements on SMTP Servers
475 If an SMTP server that advertises both SMTPUTF8 and DSN needs to
476 return an undeliverable SMTPUTF8 message, then it has two choices for
477 encapsulating the SMTPUTF8 message when generating the corresponding
481 undeliverable body part and headers MUST be encoded using a 7-bit
482 Content-Transfer-Encoding such as "base64" or "quoted-printable"
483 [RFC2045], as detailed in Section 4.
485 Otherwise, "8bit" Content-Transfer-Encoding can be used.
4875. UTF-8 Message Disposition Notifications
489 Message Disposition Notifications [RFC3798] have a similar design and
490 structure to DSNs. As a result, they use the same basic return
491 format. When generating an MDN for a UTF-8 header message, the third
492 part of the multipart/report contains the returned content (message/
493 global) or header (message/global-headers), same as for DSNs. The
494 second part of the multipart/report uses a new media type, message/
495 global-disposition-notification, which has the syntax of message/
496 disposition-notification with two modifications. First, the charset
497 for message/global-disposition-notification is UTF-8, and thus any
498 field MAY contain UTF-8 characters when appropriate (see the ABNF
499 below). (In particular, the failure-field, the error-field, and the
500 warning-field MAY contain UTF-8. These fields SHOULD be in i-default
506Hansen, et al. Standards Track [Page 9]
508RFC 6533 Internationalized DSN and MDNs February 2012
511 language [RFC2277].) Second, systems generating a message/
512 global-disposition-notification body part (typically a mail user
513 agent) SHOULD use the UTF-8 address type for all addresses containing
514 characters outside the ASCII repertoire.
516 The MDN specification also defines the "Original-Recipient:" header
517 field, which is added with a copy of the contents of ORCPT at
518 delivery time. When generating an "Original-Recipient:" header
519 field, a delivery agent writing a UTF-8 header message in native
520 format SHOULD convert the utf-8-addr-xtext or the utf-8-addr-unitext
521 form of a UTF-8 address type in the ORCPT parameter to the
522 corresponding utf-8-address form.
524 The MDN specification also defines the "Disposition-Notification-To:"
525 header field, which is an address header field and thus follows the
526 same 8-bit rules as other address header fields such as "From:" and
527 "To:" when used in a UTF-8 header message.
529 ; ABNF for "original-recipient-header", "original-recipient-field",
530 ; and "final-recipient-field" from RFC 3798 is implicitly updated
531 ; as they use the updated "generic-address" as defined in
532 ; Section 4 of this document.
534 failure-field = "Failure" ":" *utf8-text
535 ; "utf8-text" is defined in Section 4 of this document.
537 error-field = "Error" ":" *utf8-text
538 ; "utf8-text" is defined in Section 4 of this document.
540 warning-field = "Warning" ":" *utf8-text
541 ; "utf8-text" is defined in Section 4 of this document.
5436. IANA Considerations
545 This specification does not create any new IANA registries. However,
546 the following items have been registered as a result of this
5496.1. UTF-8 Mail Address Type Registration
551 The mail address type registry was created by [RFC3464]. The
552 registration template response follows:
554 (a) The address-type name.
562Hansen, et al. Standards Track [Page 10]
564RFC 6533 Internationalized DSN and MDNs February 2012
567 (b) The syntax for mailbox addresses of this type, specified using
568 BNF, regular expressions, ASN.1, or other non-ambiguous language.
572 (c) If addresses of this type are not composed entirely of graphic
573 characters from the ASCII repertoire, a specification for how
574 they are to be encoded as graphic ASCII characters in an
575 "Original-Recipient:" or "Final-Recipient:" DSN field.
577 This address type has 3 forms (as defined in Section 3):
578 utf-8-addr-xtext, utf-8-addr-unitext, and utf-8-address. Only
579 the first form is 7-bit safe.
5816.2. Update to 'smtp' Diagnostic Type Registration
583 The mail diagnostic type registry was created by [RFC3464] and
584 updated by [RFC5337]. This specification replaces [RFC5337]. The
585 registration for the 'smtp' diagnostic type has been updated to
586 reference RFC 6533 in addition to [RFC3464] and to remove the
587 reference to [RFC5337].
590 delivery-status body part, it remains as presently defined. When the
591 'smtp' diagnostic type is used in the context of a message/
592 global-delivery-status body part, the codes remain the same, but the
593 text portion MAY contain UTF-8 characters.
5956.3. message/global-headers
599 Subtype name: global-headers
601 Required parameters: none
603 Optional parameters: none
606 Email Headers [RFC6532] with no message body. Whenever possible,
607 the 8-bit content transfer encoding SHOULD be used. When this
608 media type passes through a 7-bit-only SMTP infrastructure, it MAY
609 be encoded with the base64 or quoted-printable content transfer
612 Security considerations: See Section 7.
618Hansen, et al. Standards Track [Page 11]
620RFC 6533 Internationalized DSN and MDNs February 2012
623 Interoperability considerations: It is important that this media
624 type is not converted to a charset other than UTF-8. As a result,
626 media type. Although it might be possible to down-convert this
627 media type to the text/rfc822-header media type, such conversion
628 is discouraged as it loses information.
630 Published specification: RFC 6533
632 Applications that use this media type: SMTPUTF8 servers and email
633 clients that support multipart/report generation or parsing.
635 Additional information:
637 Magic number(s): none
639 File extension(s): In the event this is saved to a file, the
640 extension ".u8hdr" is suggested.
642 Macintosh file type code(s): The 'TEXT' type code is suggested as
643 files of this type are typically used for diagnostic purposes
644 and suitable for analysis in a UTF-8-aware text editor. A
645 uniform type identifier (UTI) of
646 "public.utf8-email-message-header" is suggested. This type
647 conforms to "public.utf8-plain-text" and "public.plain-text".
649 Person & email address to contact for further information: See the
650 Authors' Addresses section of this document.
652 Intended usage: COMMON
654 Restrictions on usage: This media type contains textual data in the
655 UTF-8 charset. It typically contains octets with the 8th bit set.
656 As a result, a transfer encoding is required when a 7-bit
659 Author: See the Authors' Addresses section of this document.
661 Change controller: IETF Standards Process
6636.4. message/global-delivery-status
667 Subtype name: global-delivery-status
669 Required parameters: none
674Hansen, et al. Standards Track [Page 12]
676RFC 6533 Internationalized DSN and MDNs February 2012
679 Optional parameters: none
681 Encoding considerations: This media type contains delivery status
682 notification attributes in the UTF-8 charset. The 8-bit content
683 transfer encoding MUST be used with this content-type, unless it
684 is sent over a 7-bit transport environment, in which case quoted-
685 printable or base64 may be necessary.
687 Security considerations: See Section 7
689 Interoperability considerations: This media type provides
690 functionality similar to the message/delivery-status content-type
691 for email message return information. Clients of the previous
692 format will need to be upgraded to interpret the new format;
693 however, the new media type makes it simple to identify the
696 Published specification: RFC 6533
698 Applications that use this media type: SMTP servers and email
699 clients that support delivery status notification generation or
702 Additional information:
704 Magic number(s): none
706 File extension(s): The extension ".u8dsn" is suggested.
708 Macintosh file type code(s): A uniform type identifier (UTI) of
709 "public.utf8-email-message-delivery-status" is suggested. This
710 type conforms to "public.utf8-plain-text".
712 Person & email address to contact for further information: See the
713 Authors' Addresses section of this document.
715 Intended usage: COMMON
717 Restrictions on usage: This is expected to be the second part of a
720 Author: See the Authors' Addresses section of this document.
722 Change controller: IETF Standards Process
730Hansen, et al. Standards Track [Page 13]
732RFC 6533 Internationalized DSN and MDNs February 2012
7356.5. message/global-disposition-notification
739 Subtype name: global-disposition-notification
741 Required parameters: none
743 Optional parameters: none
745 Encoding considerations: This media type contains disposition
746 notification attributes in the UTF-8 charset. The 8-bit content
747 transfer encoding MUST be used with this content-type, unless it
748 is sent over a 7-bit transport environment, in which case quoted-
749 printable or base64 may be necessary.
751 Security considerations: See Section 7.
753 Interoperability considerations: This media type provides
754 functionality similar to the message/disposition-notification
755 content-type for email message disposition information. Clients
756 of the previous format will need to be upgraded to interpret the
757 new format; however, the new media type makes it simple to
758 identify the difference.
760 Published specification: RFC 6533
762 Applications that use this media type: Email clients or servers that
763 support message disposition notification generation or parsing.
765 Additional information:
767 Magic number(s): none
769 File extension(s): The extension ".u8mdn" is suggested.
771 Macintosh file type code(s): A uniform type identifier (UTI) of
772 "public.utf8-email-message-disposition-notification" is
773 suggested. This type conforms to "public.utf8-plain-text".
775 Person & email address to contact for further information: See the
776 Authors' Addresses section of this document.
778 Intended usage: COMMON
780 Restrictions on usage: This is expected to be the second part of a
786Hansen, et al. Standards Track [Page 14]
788RFC 6533 Internationalized DSN and MDNs February 2012
791 Author: See the Authors' Addresses section of this document.
793 Change controller: IETF Standards Process
7957. Security Considerations
797 Automated use of report types without authentication presents several
798 security issues. Forging negative reports presents the opportunity
799 for denial-of-service attacks when the reports are used for automated
800 maintenance of directories or mailing lists. Forging positive
801 reports may cause the sender to incorrectly believe a message was
802 delivered when it was not.
804 Malicious users can generate report structures designed to trigger
805 coding flaws in report parsers. Report parsers need to use secure
806 coding techniques to avoid the risk of buffer overflow or denial-of-
807 service attacks against parser coding mistakes. Code reviews of such
808 parsers are also recommended.
810 Malicious users of the email system regularly send messages with
811 forged envelope return paths, and these messages trigger delivery
812 status reports that result in a large amount of unwanted traffic on
813 the Internet. Many users choose to ignore delivery status
814 notifications because they are usually the result of "blowback" from
815 forged messages and thus never notice when messages they sent go
816 undelivered. As a result, support for correlation of delivery status
817 and message disposition notification messages with sent messages has
818 become a critical feature of mail clients and possibly mail stores,
819 if the email infrastructure is to remain reliable. In the short
820 term, simply correlating Message-IDs may be sufficient to distinguish
821 true status notifications from those resulting from forged originator
822 addresses. But in the longer term, including cryptographic signature
823 material that can securely associate the status notification with the
824 original message is advisable.
826 As this specification permits UTF-8 in additional fields, the
827 security considerations of UTF-8 [RFC3629] apply.
842Hansen, et al. Standards Track [Page 15]
844RFC 6533 Internationalized DSN and MDNs February 2012
8498.1. Normative References
851 [ASCII] American National Standards Institute (formerly United
852 States of America Standards Institute), "USA Code for
853 Information Interchange", ANSI X3.4-1968, 1968.
855 ANSI X3.4-1968 has been replaced by newer versions with
856 slight modifications, but the 1968 version remains
857 definitive for the Internet.
859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
860 Requirement Levels", BCP 14, RFC 2119, March 1997.
862 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
863 Languages", BCP 18, RFC 2277, January 1998.
865 [RFC3461] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
866 Extension for Delivery Status Notifications (DSNs)",
867 RFC 3461, January 2003.
869 [RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format
870 for Delivery Status Notifications", RFC 3464,
873 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
874 10646", STD 63, RFC 3629, November 2003.
876 [RFC3798] Hansen, T. and G. Vaudreuil, "Message Disposition
877 Notification", RFC 3798, May 2004.
879 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
880 Specifications: ABNF", STD 68, RFC 5234, January 2008.
882 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
885 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
888 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
889 Languages", BCP 47, RFC 5646, September 2009.
891 [RFC6522] Kucherawy, M., Ed., "The Multipart/Report Media Type for
892 the Reporting of Mail System Administrative Messages", STD
893 73, RFC 6522, January 2012.
898Hansen, et al. Standards Track [Page 16]
900RFC 6533 Internationalized DSN and MDNs February 2012
903 [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for
904 Internationalized Email", RFC 6530, February 2012.
906 [RFC6531] Yao, J. and W. Mao, "SMTP Extension for Internationalized
907 Email", RFC 6531, February 2012.
909 [RFC6532] Yang, A., Steele, S., and N. Freed, "Internationalized
910 Email Headers", RFC 6532, February 2012.
9128.2. Informative References
914 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
915 Extensions (MIME) Part One: Format of Internet Message
916 Bodies", RFC 2045, November 1996.
918 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
919 Extensions (MIME) Part Two: Media Types", RFC 2046,
922 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery
923 Status and Disposition Notifications", RFC 5337,
954Hansen, et al. Standards Track [Page 17]
956RFC 6533 Internationalized DSN and MDNs February 2012
959Appendix A. Changes since RFC 5337
961 Changes were made to move from Experimental to Standards Track. The
962 most significant was the removal of an embedded alternative ASCII
963 address within a utf-8-address, and the reflections of the ABNF
964 changes in [RFC6531].
966 Fixed description of utf-8-addr-xtext and utf-8-addr-unitext.
968 References to Downgrade and uMailbox removed/fixed.
970 ABNF changes and fixed errata submitted by Alfred Hoenes.
972 Minor changes to MIME type references.
974 Other minor corrections.
976Appendix B. Acknowledgements
978 Many thanks for input provided by Pete Resnick, James Galvin, Ned
979 Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred
980 Hoenes, Kazunori Fujiwara, and members of the EAI working group to
981 help solidify this proposal.
1010Hansen, et al. Standards Track [Page 18]
1012RFC 6533 Internationalized DSN and MDNs February 2012
1017 Tony Hansen (editor)
1020 Middletown, NJ 07748
1023 EMail: tony+eaidsn@maillennium.att.com
1029 Monrovia, CA 91016-6347
1032 EMail: chris.newman@oracle.com
1037 5 Castle Business Village
1039 Hampton, Middlesex TW12 2BX
1042 EMail: Alexey.Melnikov@isode.com
1066Hansen, et al. Standards Track [Page 19]