doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc6533.txt b/doc/rfc/rfc6533.txt
new file mode 100644
index 0000000..a350c17
--- /dev/null
+++ b/doc/rfc/rfc6533.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                    T. Hansen, Ed.
+Request for Comments: 6533                             AT&T Laboratories
+Obsoletes: 5337                                                C. Newman
+Updates: 3461, 3464, 3798, 6522                                   Oracle
+Category: Standards Track                                    A. Melnikov
+ISSN: 2070-1721                                                Isode Ltd
+                                                           February 2012
+
+
+    Internationalized Delivery Status and Disposition Notifications
+
+Abstract
+
+   Delivery status notifications (DSNs) are critical to the correct
+   operation of an email system.  However, the existing Draft Standards
+   (RFC 3461, RFC 3464, RFC 6522) are presently limited to ASCII text in
+   the machine-readable portions of the protocol.  This specification
+   adds a new address type for international email addresses so an
+   original recipient address with non-ASCII characters can be correctly
+   preserved even after downgrading.  This also provides updated content
+   return media types for delivery status notifications and message
+   disposition notifications to support use of the new address type.
+
+   This document extends RFC 3461, RFC 3464, RFC 3798, and RFC 6522.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6533.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                    [Page 1]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  UTF-8 Address Type . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  UTF-8 Delivery Status Notifications  . . . . . . . . . . . . .  6
+     4.1.  The message/global-delivery-status Media Type  . . . . . .  6
+     4.2.  The message/global Media Type  . . . . . . . . . . . . . .  8
+     4.3.  The message/global-headers Media Type  . . . . . . . . . .  8
+     4.4.  Using These Media Types with multipart/report  . . . . . .  8
+     4.5.  Additional Requirements on SMTP Servers  . . . . . . . . .  9
+   5.  UTF-8 Message Disposition Notifications  . . . . . . . . . . .  9
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
+     6.1.  UTF-8 Mail Address Type Registration . . . . . . . . . . . 10
+     6.2.  Update to 'smtp' Diagnostic Type Registration  . . . . . . 11
+     6.3.  message/global-headers . . . . . . . . . . . . . . . . . . 11
+     6.4.  message/global-delivery-status . . . . . . . . . . . . . . 12
+     6.5.  message/global-disposition-notification  . . . . . . . . . 14
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 17
+   Appendix A.  Changes since RFC 5337  . . . . . . . . . . . . . . . 18
+   Appendix B.  Acknowledgements  . . . . . . . . . . . . . . . . . . 18
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                    [Page 2]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+1.  Introduction
+
+   When an email message is transmitted using the SMTPUTF8 [RFC6531]
+   extension and Internationalized Email Headers [RFC6532], it is
+   sometimes necessary to return that message or generate a Message
+   Disposition Notification (MDN) [RFC3798].  As a message sent to
+   multiple recipients can generate a status and disposition
+   notification for each recipient, it is helpful if a client can
+   correlate these notifications based on the recipient address it
+   provided; thus, preservation of the original recipient is important.
+   This specification describes how to preserve the original recipient
+   and updates the MDN and DSN formats to support the new address types.
+
+   NOTE: While this specification updates the experimental versions of
+   this protocol by removing certain constructs (e.g., the "<addr
+   <addr>>" address syntax is no longer permitted), the name of the
+   Address Type "UTF-8" and the media type names message/global,
+   message/global-delivery-status, and message/global-headers have not
+   been changed.
+
+   This specification is a revision of and replacement for [RFC5337].
+   Section 6 of [RFC6530] describes the change in approach between this
+   specification and the previous version.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The formal syntax uses the Augmented Backus-Naur Form (ABNF)
+   [RFC5234] notation including the core rules defined in Appendix B of
+   [RFC5234] and the UTF-8 syntax rules in Section 4 of [RFC3629].
+
+3.  UTF-8 Address Type
+
+   "An Extensible Message Format for Delivery Status Notifications"
+   [RFC3464] defines the concept of an address type.  The address format
+   introduced in "Internationalized Email Headers" [RFC6532] is a new
+   address type.  The syntax for the new address type in the context of
+   status notifications is specified at the end of this section.
+
+   An SMTP [RFC5321] server that advertises both the SMTPUTF8 extension
+   [RFC6531] and the DSN extension [RFC3461] MUST accept a UTF-8 address
+   type in the ORCPT parameter including 8-bit UTF-8 characters.  This
+   address type also includes a 7-bit encoding suitable for use in a
+   message/delivery-status body part or an ORCPT parameter sent to an
+   SMTP server that does not advertise SMTPUTF8.
+
+
+
+Hansen, et al.               Standards Track                    [Page 3]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext,
+   and utf-8-address.  Only the first form is 7-bit safe (only uses
+   ASCII characters [ASCII]).
+
+   The utf-8-address form is only suitable for use in newly defined
+   protocols capable of native representation of 8-bit characters.  That
+   is, the utf-8-address form MUST NOT be used:
+
+   1.  in the ORCPT parameter when the SMTP server doesn't advertise
+       support for SMTPUTF8 (utf-8-addr-xtext MUST be used instead); or
+
+   2.  if the SMTP server supports SMTPUTF8, but the address contains
+       ASCII characters not permitted in the ORCPT parameter (e.g., the
+       ORCPT parameter forbids unencoded SP and the '=' character),
+       (either utf-8-addr-unitext or utf-8-addr-xtext MUST be used
+       instead); or
+
+   3.  in a 7-bit transport environment including a message/
+       delivery-status "Original-Recipient:" or "Final-Recipient:"
+       field, (utf-8-addr-xtext MUST be used instead).
+
+   The utf-8-address form MAY be used in the ORCPT parameter when the
+   SMTP server also advertises support for SMTPUTF8 and the address
+   doesn't contain any ASCII characters not permitted in the ORCPT
+   parameter.  It SHOULD be used in a message/global-delivery-status
+   "Original-Recipient:" or "Final-Recipient:" DSN field, or in an
+   "Original-Recipient:" header field [RFC3798] if the message is a
+   SMTPUTF8 message.
+
+   In addition, the utf-8-addr-unitext form can be used anywhere where
+   the utf-8-address form is allowed.
+
+   When used in the ORCPT parameter, the UTF-8 address type requires
+   that ASCII CTLs, SP, '\', '+', and '=' be encoded using 'unitext'
+   encoding (see below).  This is described by the utf-8-addr-xtext and
+   utf-8-addr-unitext forms in the ABNF below.  The 'unitext' encoding
+   uses "\x{HEXPOINT}" syntax (EmbeddedUnicodeChar in the ABNF below)
+   for encoding any Unicode character outside of ASCII range, as well as
+   for encoding CTLs, SP, '\', '+', and '='.  HEXPOINT is 2 to 6
+   hexadecimal digits.  This encoding avoids the need to use the xtext
+   encoding described in [RFC3461], as any ASCII characters that need to
+   be escaped using xtext encoding never appear in any unitext-encoded
+   string.  When sending data to a SMTPUTF8-capable server, native UTF-8
+   characters SHOULD be used instead of the EmbeddedUnicodeChar syntax
+   described below.  When sending data to an SMTP server that does not
+   advertise SMTPUTF8, then the EmbeddedUnicodeChar syntax MUST be used
+   instead of UTF-8.
+
+
+
+
+Hansen, et al.               Standards Track                    [Page 4]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   When the ORCPT parameter is placed in a message/
+   global-delivery-status "Original-Recipient:" field, the
+   utf-8-addr-xtext form of the UTF-8 address type SHOULD be converted
+   to the utf-8-address form (see the ABNF below) by removing the
+   unitext encoding.  However, if an address is labeled with the UTF-8
+   address type but does not conform to utf-8 syntax, then it MUST be
+   copied into the message/global-delivery-status field without
+   alteration.
+
+   The ability to encode characters with the EmbeddedUnicodeChar
+   encodings should be viewed as a transitional mechanism and avoided
+   when possible.  It is hoped that as systems lacking support for
+   SMTPUTF8 become less common over time, these encodings can eventually
+   be phased out.
+
+   In the ABNF below, all productions not defined in this document are
+   defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
+   [RFC3464].
+
+   utf-8-type-addr     = "utf-8;" utf-8-enc-addr
+
+   utf-8-address       = Mailbox
+     ; Mailbox as defined in [RFC6531].
+
+   utf-8-enc-addr      = utf-8-addr-xtext /
+                         utf-8-addr-unitext /
+                         utf-8-address
+
+   utf-8-addr-xtext    = 1*(QCHAR / EmbeddedUnicodeChar)
+                         ; 7bit form of utf-8-addr-unitext.
+                         ; Safe for use in the ORCPT [RFC3461]
+                         ; parameter even when SMTPUTF8 SMTP
+                         ; extension is not advertised.
+
+   utf-8-addr-unitext  = 1*(QUCHAR / EmbeddedUnicodeChar)
+                       ; MUST follow utf-8-address ABNF when
+                       ; dequoted.
+                       ; Safe for using in the ORCPT [RFC3461]
+                       ; parameter when SMTPUTF8 SMTP extension
+                       ; is also advertised.
+
+   QCHAR              = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e
+                       ; ASCII printable characters except
+                       ; CTLs, SP, '\', '+', '='.
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                    [Page 5]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   QUCHAR              = QCHAR / UTF8-2 / UTF8-3 / UTF8-4
+                       ; ASCII printable characters except
+                       ; CTLs, SP, '\', '+' and '=', plus
+                       ; other Unicode characters encoded in UTF-8
+
+   EmbeddedUnicodeChar =   %x5C.78 "{" HEXPOINT "}"
+                       ; starts with "\x"
+
+   HEXPOINT = ( ( "0"/"1" ) %x31-39 ) / "10" / "20" /
+              "2B" / "3D" / "7F" /         ; all xtext-specials
+              "5C" / (HEXDIG8 HEXDIG) /    ; 2-digit forms
+              ( NZHEXDIG 2(HEXDIG) ) /     ; 3-digit forms
+              ( NZDHEXDIG 3(HEXDIG) ) /    ; 4-digit forms excluding
+              ( "D" %x30-37 2(HEXDIG) ) /  ; ... surrogate
+              ( NZHEXDIG 4(HEXDIG) ) /     ; 5-digit forms
+              ( "10" 4*HEXDIG )            ; 6-digit forms
+              ; represents either "\" or a Unicode code point outside
+              ; the ASCII repertoire
+
+   HEXDIG8             = %x38-39 / "A" / "B" / "C" / "D" / "E" / "F"
+                       ; HEXDIG excluding 0-7
+   NZHEXDIG            = %x31-39 / "A" / "B" / "C" / "D" / "E" / "F"
+                       ; HEXDIG excluding "0"
+   NZDHEXDIG           = %x31-39 / "A" / "B" / "C" / "E" / "F"
+                       ; HEXDIG excluding "0" and "D"
+
+4.  UTF-8 Delivery Status Notifications
+
+   A traditional delivery status notification [RFC3464] comes in a
+   three-part multipart/report [RFC6522] container, where the first part
+   is human-readable text describing the error, the second part is a
+   7-bit-only message/delivery-status, and the optional third part is
+   used for content (message/rfc822) or header (text/rfc822-headers)
+   return.  As the present standard DSN format does not permit the
+   return of undeliverable SMTPUTF8 messages, three new media types have
+   been defined.  ([RFC5337] introduced experimental versions of these
+   media types.)
+
+4.1.  The message/global-delivery-status Media Type
+
+   The first type, message/global-delivery-status, has the syntax of
+   message/delivery-status with three modifications.  First, the charset
+   for message/global-delivery-status is UTF-8, and thus any field MAY
+   contain UTF-8 characters when appropriate (see the ABNF below).  In
+   particular, the "Diagnostic-Code:" field MAY contain UTF-8 as
+   described in SMTPUTF8 [RFC6531]; the "Diagnostic-Code:" field SHOULD
+   be in i-default language [RFC2277].  Second, systems generating a
+   message/global-delivery-status body part SHOULD use the utf-8-address
+
+
+
+Hansen, et al.               Standards Track                    [Page 6]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   form of the UTF-8 address type for all addresses containing
+   characters outside the ASCII repertoire.  These systems SHOULD up-
+   convert the utf-8-addr-xtext or the utf-8-addr-unitext form of a
+   UTF-8 address type in the ORCPT parameter to the utf-8-address form
+   of a UTF-8 address type in the "Original-Recipient:" field.  Third,
+   an optional field called "Localized-Diagnostic:" is added.  Each
+   instance includes a language tag [RFC5646] and contains text in the
+   specified language.  This is equivalent to the text part of the
+   "Diagnostic-Code:" field.  All instances of "Localized-Diagnostic:"
+   MUST use different language tags.  The ABNF for message/
+   global-delivery-status is specified below.
+
+   In the ABNF below, all productions not defined in this document are
+   defined in Appendix B of [RFC5234], in Section 4 of [RFC3629], or in
+   [RFC3464].  Note that <text-fixed> is the same as <text> from
+   [RFC5322], but without <obs-text>.  If or when RFC 5322 is updated to
+   disallow <obs-text>, <text-fixed> should become just <text>.  Also,
+   if or when RFC 5322 is updated to disallow control characters in
+   <text>, <text-fixed> should become a reference to that update
+   instead.
+
+   utf-8-delivery-status-content = per-message-fields
+                         1*( CRLF utf-8-per-recipient-fields )
+        ; "per-message-fields" remains unchanged from the definition
+        ; in RFC 3464, except for the "extension-field",
+        ; which is updated below.
+
+   utf-8-per-recipient-fields =
+         [ original-recipient-field CRLF ]
+         final-recipient-field CRLF
+         action-field CRLF
+         status-field CRLF
+         [ remote-mta-field CRLF ]
+         [ diagnostic-code-field CRLF
+           *(localized-diagnostic-text-field CRLF) ]
+         [ last-attempt-date-field CRLF ]
+             [ final-log-id-field CRLF ]
+         [ will-retry-until-field CRLF ]
+         *( extension-field CRLF )
+     ; All fields except for "original-recipient-field",
+     ; "final-recipient-field", "diagnostic-code-field",
+     ; and "extension-field" remain unchanged from
+     ; the definition in RFC 3464.
+
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                    [Page 7]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   generic-address =/ utf-8-enc-addr
+     ; Only allowed with the "utf-8" address-type.
+     ; Updates Section 3.2.3 of RFC 3798.
+     ;
+     ; This indirectly updates "original-recipient-field"
+     ; and "final-recipient-field".
+
+   diagnostic-code-field =
+        "Diagnostic-Code" ":" diagnostic-type ";" *text-fixed
+
+   localized-diagnostic-text-field =
+        "Localized-Diagnostic" ":" Language-Tag ";" *utf8-text
+     ; "Language-Tag" is a language tag as defined in [RFC5646].
+
+   extension-field =/ extension-field-name ":" *utf8-text
+     ; Updates Section 7 of RFC3798
+
+   text-fixed = %d1-9 /      ; Any ASCII character except for NUL,
+                %d11 /       ; CR, and LF.
+                %d12 /       ; See note above about <text-fixed>
+                %d14-127
+
+   utf8-text = text-fixed / UTF8-non-ascii
+
+   UTF8-non-ascii   = UTF8-2 / UTF8-3 / UTF8-4
+
+4.2.  The message/global Media Type
+
+   The second type, used for returning the content, is message/global,
+   which is similar to message/rfc822, except it contains a message with
+   UTF-8 headers.  This media type is described in [RFC6532].
+
+4.3.  The message/global-headers Media Type
+
+   The third type, used for returning the headers, is message/
+   global-headers and contains only the UTF-8 header fields of a message
+   (all lines prior to the first blank line in a SMTPUTF8 message).
+   Unlike message/global, this body part provides no difficulties for
+   the present infrastructure.
+
+4.4.  Using These Media Types with multipart/report
+
+   Note that as far as a multipart/report [RFC6522] container is
+   concerned, message/global-delivery-status, message/global, and
+   message/global-headers MUST be treated as equivalent to message/
+   delivery-status, message/rfc822, and text/rfc822-headers.  That is,
+
+
+
+
+
+Hansen, et al.               Standards Track                    [Page 8]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   implementations processing multipart/report MUST expect any
+   combinations of the 6 media types mentioned above inside a multipart/
+   report media type.
+
+   All three new types will typically use the "8bit" Content-Transfer-
+   Encoding.  (In the event all content is 7-bit, the equivalent
+   traditional types for delivery status notifications MAY be used.  For
+   example, if information in a message/global-delivery-status part can
+   be represented without any loss of information as message/
+   delivery-status, then the message/delivery-status body part may be
+   used.)  Note that [RFC6532] relaxed a restriction from MIME [RFC2046]
+   regarding the use of Content-Transfer-Encoding in new "message"
+   subtypes.  This specification explicitly allows the use of Content-
+   Transfer-Encoding in message/global-headers and message/
+   global-delivery-status.  This is not believed to be problematic as
+   these new media types are intended primarily for use by newer systems
+   with full support for 8-bit MIME and UTF-8 headers.
+
+4.5.  Additional Requirements on SMTP Servers
+
+   If an SMTP server that advertises both SMTPUTF8 and DSN needs to
+   return an undeliverable SMTPUTF8 message, then it has two choices for
+   encapsulating the SMTPUTF8 message when generating the corresponding
+   multipart/report:
+
+      If the return-path SMTP server does not support SMTPUTF8, then the
+      undeliverable body part and headers MUST be encoded using a 7-bit
+      Content-Transfer-Encoding such as "base64" or "quoted-printable"
+      [RFC2045], as detailed in Section 4.
+
+      Otherwise, "8bit" Content-Transfer-Encoding can be used.
+
+5.  UTF-8 Message Disposition Notifications
+
+   Message Disposition Notifications [RFC3798] have a similar design and
+   structure to DSNs.  As a result, they use the same basic return
+   format.  When generating an MDN for a UTF-8 header message, the third
+   part of the multipart/report contains the returned content (message/
+   global) or header (message/global-headers), same as for DSNs.  The
+   second part of the multipart/report uses a new media type, message/
+   global-disposition-notification, which has the syntax of message/
+   disposition-notification with two modifications.  First, the charset
+   for message/global-disposition-notification is UTF-8, and thus any
+   field MAY contain UTF-8 characters when appropriate (see the ABNF
+   below).  (In particular, the failure-field, the error-field, and the
+   warning-field MAY contain UTF-8.  These fields SHOULD be in i-default
+
+
+
+
+
+Hansen, et al.               Standards Track                    [Page 9]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   language [RFC2277].)  Second, systems generating a message/
+   global-disposition-notification body part (typically a mail user
+   agent) SHOULD use the UTF-8 address type for all addresses containing
+   characters outside the ASCII repertoire.
+
+   The MDN specification also defines the "Original-Recipient:" header
+   field, which is added with a copy of the contents of ORCPT at
+   delivery time.  When generating an "Original-Recipient:" header
+   field, a delivery agent writing a UTF-8 header message in native
+   format SHOULD convert the utf-8-addr-xtext or the utf-8-addr-unitext
+   form of a UTF-8 address type in the ORCPT parameter to the
+   corresponding utf-8-address form.
+
+   The MDN specification also defines the "Disposition-Notification-To:"
+   header field, which is an address header field and thus follows the
+   same 8-bit rules as other address header fields such as "From:" and
+   "To:" when used in a UTF-8 header message.
+
+     ; ABNF for "original-recipient-header", "original-recipient-field",
+     ; and "final-recipient-field" from RFC 3798 is implicitly updated
+     ; as they use the updated "generic-address" as defined in
+     ; Section 4 of this document.
+
+   failure-field = "Failure" ":" *utf8-text
+     ; "utf8-text" is defined in Section 4 of this document.
+
+   error-field = "Error" ":" *utf8-text
+     ; "utf8-text" is defined in Section 4 of this document.
+
+   warning-field = "Warning" ":" *utf8-text
+     ; "utf8-text" is defined in Section 4 of this document.
+
+6.  IANA Considerations
+
+   This specification does not create any new IANA registries.  However,
+   the following items have been registered as a result of this
+   document.
+
+6.1.  UTF-8 Mail Address Type Registration
+
+   The mail address type registry was created by [RFC3464].  The
+   registration template response follows:
+
+   (a) The address-type name.
+
+       UTF-8
+
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 10]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   (b) The syntax for mailbox addresses of this type, specified using
+       BNF, regular expressions, ASN.1, or other non-ambiguous language.
+
+       See Section 3.
+
+   (c) If addresses of this type are not composed entirely of graphic
+       characters from the ASCII repertoire, a specification for how
+       they are to be encoded as graphic ASCII characters in an
+       "Original-Recipient:" or "Final-Recipient:" DSN field.
+
+       This address type has 3 forms (as defined in Section 3):
+       utf-8-addr-xtext, utf-8-addr-unitext, and utf-8-address.  Only
+       the first form is 7-bit safe.
+
+6.2.  Update to 'smtp' Diagnostic Type Registration
+
+   The mail diagnostic type registry was created by [RFC3464] and
+   updated by [RFC5337].  This specification replaces [RFC5337].  The
+   registration for the 'smtp' diagnostic type has been updated to
+   reference RFC 6533 in addition to [RFC3464] and to remove the
+   reference to [RFC5337].
+
+   When the 'smtp' diagnostic type is used in the context of a message/
+   delivery-status body part, it remains as presently defined.  When the
+   'smtp' diagnostic type is used in the context of a message/
+   global-delivery-status body part, the codes remain the same, but the
+   text portion MAY contain UTF-8 characters.
+
+6.3.  message/global-headers
+
+   Type name:  message
+
+   Subtype name:  global-headers
+
+   Required parameters:  none
+
+   Optional parameters:  none
+
+   Encoding considerations:  This media type contains Internationalized
+      Email Headers [RFC6532] with no message body.  Whenever possible,
+      the 8-bit content transfer encoding SHOULD be used.  When this
+      media type passes through a 7-bit-only SMTP infrastructure, it MAY
+      be encoded with the base64 or quoted-printable content transfer
+      encoding.
+
+   Security considerations:  See Section 7.
+
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 11]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   Interoperability considerations:  It is important that this media
+      type is not converted to a charset other than UTF-8.  As a result,
+      implementations MUST NOT include a charset parameter with this
+      media type.  Although it might be possible to down-convert this
+      media type to the text/rfc822-header media type, such conversion
+      is discouraged as it loses information.
+
+   Published specification:  RFC 6533
+
+   Applications that use this media type:  SMTPUTF8 servers and email
+      clients that support multipart/report generation or parsing.
+
+   Additional information:
+
+      Magic number(s):  none
+
+      File extension(s):  In the event this is saved to a file, the
+         extension ".u8hdr" is suggested.
+
+      Macintosh file type code(s):  The 'TEXT' type code is suggested as
+         files of this type are typically used for diagnostic purposes
+         and suitable for analysis in a UTF-8-aware text editor.  A
+         uniform type identifier (UTI) of
+         "public.utf8-email-message-header" is suggested.  This type
+         conforms to "public.utf8-plain-text" and "public.plain-text".
+
+   Person & email address to contact for further information:  See the
+      Authors' Addresses section of this document.
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  This media type contains textual data in the
+      UTF-8 charset.  It typically contains octets with the 8th bit set.
+      As a result, a transfer encoding is required when a 7-bit
+      transport is used.
+
+   Author:  See the Authors' Addresses section of this document.
+
+   Change controller:  IETF Standards Process
+
+6.4.  message/global-delivery-status
+
+   Type name:  message
+
+   Subtype name:  global-delivery-status
+
+   Required parameters:  none
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 12]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   Optional parameters:  none
+
+   Encoding considerations:  This media type contains delivery status
+      notification attributes in the UTF-8 charset.  The 8-bit content
+      transfer encoding MUST be used with this content-type, unless it
+      is sent over a 7-bit transport environment, in which case quoted-
+      printable or base64 may be necessary.
+
+   Security considerations:  See Section 7
+
+   Interoperability considerations:  This media type provides
+      functionality similar to the message/delivery-status content-type
+      for email message return information.  Clients of the previous
+      format will need to be upgraded to interpret the new format;
+      however, the new media type makes it simple to identify the
+      difference.
+
+   Published specification:  RFC 6533
+
+   Applications that use this media type:  SMTP servers and email
+      clients that support delivery status notification generation or
+      parsing.
+
+   Additional information:
+
+      Magic number(s):  none
+
+      File extension(s):  The extension ".u8dsn" is suggested.
+
+      Macintosh file type code(s):  A uniform type identifier (UTI) of
+         "public.utf8-email-message-delivery-status" is suggested.  This
+         type conforms to "public.utf8-plain-text".
+
+   Person & email address to contact for further information:  See the
+      Authors' Addresses section of this document.
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  This is expected to be the second part of a
+      multipart/report.
+
+   Author:  See the Authors' Addresses section of this document.
+
+   Change controller:  IETF Standards Process
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 13]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+6.5.  message/global-disposition-notification
+
+   Type name:  message
+
+   Subtype name:  global-disposition-notification
+
+   Required parameters:  none
+
+   Optional parameters:  none
+
+   Encoding considerations:  This media type contains disposition
+      notification attributes in the UTF-8 charset.  The 8-bit content
+      transfer encoding MUST be used with this content-type, unless it
+      is sent over a 7-bit transport environment, in which case quoted-
+      printable or base64 may be necessary.
+
+   Security considerations:  See Section 7.
+
+   Interoperability considerations:  This media type provides
+      functionality similar to the message/disposition-notification
+      content-type for email message disposition information.  Clients
+      of the previous format will need to be upgraded to interpret the
+      new format; however, the new media type makes it simple to
+      identify the difference.
+
+   Published specification:  RFC 6533
+
+   Applications that use this media type:  Email clients or servers that
+      support message disposition notification generation or parsing.
+
+   Additional information:
+
+      Magic number(s):  none
+
+      File extension(s):  The extension ".u8mdn" is suggested.
+
+      Macintosh file type code(s):  A uniform type identifier (UTI) of
+         "public.utf8-email-message-disposition-notification" is
+         suggested.  This type conforms to "public.utf8-plain-text".
+
+   Person & email address to contact for further information:  See the
+      Authors' Addresses section of this document.
+
+   Intended usage:  COMMON
+
+   Restrictions on usage:  This is expected to be the second part of a
+      multipart/report.
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 14]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   Author:  See the Authors' Addresses section of this document.
+
+   Change controller:  IETF Standards Process
+
+7.  Security Considerations
+
+   Automated use of report types without authentication presents several
+   security issues.  Forging negative reports presents the opportunity
+   for denial-of-service attacks when the reports are used for automated
+   maintenance of directories or mailing lists.  Forging positive
+   reports may cause the sender to incorrectly believe a message was
+   delivered when it was not.
+
+   Malicious users can generate report structures designed to trigger
+   coding flaws in report parsers.  Report parsers need to use secure
+   coding techniques to avoid the risk of buffer overflow or denial-of-
+   service attacks against parser coding mistakes.  Code reviews of such
+   parsers are also recommended.
+
+   Malicious users of the email system regularly send messages with
+   forged envelope return paths, and these messages trigger delivery
+   status reports that result in a large amount of unwanted traffic on
+   the Internet.  Many users choose to ignore delivery status
+   notifications because they are usually the result of "blowback" from
+   forged messages and thus never notice when messages they sent go
+   undelivered.  As a result, support for correlation of delivery status
+   and message disposition notification messages with sent messages has
+   become a critical feature of mail clients and possibly mail stores,
+   if the email infrastructure is to remain reliable.  In the short
+   term, simply correlating Message-IDs may be sufficient to distinguish
+   true status notifications from those resulting from forged originator
+   addresses.  But in the longer term, including cryptographic signature
+   material that can securely associate the status notification with the
+   original message is advisable.
+
+   As this specification permits UTF-8 in additional fields, the
+   security considerations of UTF-8 [RFC3629] apply.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 15]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+8.  References
+
+8.1.  Normative References
+
+   [ASCII]    American National Standards Institute (formerly United
+              States of America Standards Institute), "USA Code for
+              Information Interchange", ANSI X3.4-1968, 1968.
+
+              ANSI X3.4-1968 has been replaced by newer versions with
+              slight modifications, but the 1968 version remains
+              definitive for the Internet.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2277]  Alvestrand, H., "IETF Policy on Character Sets and
+              Languages", BCP 18, RFC 2277, January 1998.
+
+   [RFC3461]  Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
+              Extension for Delivery Status Notifications (DSNs)",
+              RFC 3461, January 2003.
+
+   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
+              for Delivery Status Notifications", RFC 3464,
+              January 2003.
+
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, November 2003.
+
+   [RFC3798]  Hansen, T. and G. Vaudreuil, "Message Disposition
+              Notification", RFC 3798, May 2004.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+              October 2008.
+
+   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
+              October 2008.
+
+   [RFC5646]  Phillips, A. and M. Davis, "Tags for Identifying
+              Languages", BCP 47, RFC 5646, September 2009.
+
+   [RFC6522]  Kucherawy, M., Ed., "The Multipart/Report Media Type for
+              the Reporting of Mail System Administrative Messages", STD
+              73, RFC 6522, January 2012.
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 16]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
+              Internationalized Email", RFC 6530, February 2012.
+
+   [RFC6531]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
+              Email", RFC 6531, February 2012.
+
+   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
+              Email Headers", RFC 6532, February 2012.
+
+8.2.  Informative References
+
+   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part One: Format of Internet Message
+              Bodies", RFC 2045, November 1996.
+
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              November 1996.
+
+   [RFC5337]  Newman, C. and A. Melnikov, "Internationalized Delivery
+              Status and Disposition Notifications", RFC 5337,
+              September 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 17]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+Appendix A.  Changes since RFC 5337
+
+   Changes were made to move from Experimental to Standards Track.  The
+   most significant was the removal of an embedded alternative ASCII
+   address within a utf-8-address, and the reflections of the ABNF
+   changes in [RFC6531].
+
+   Fixed description of utf-8-addr-xtext and utf-8-addr-unitext.
+
+   References to Downgrade and uMailbox removed/fixed.
+
+   ABNF changes and fixed errata submitted by Alfred Hoenes.
+
+   Minor changes to MIME type references.
+
+   Other minor corrections.
+
+Appendix B.  Acknowledgements
+
+   Many thanks for input provided by Pete Resnick, James Galvin, Ned
+   Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, Alfred
+   Hoenes, Kazunori Fujiwara, and members of the EAI working group to
+   help solidify this proposal.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 18]
+
+RFC 6533             Internationalized DSN and MDNs        February 2012
+
+
+Authors' Addresses
+
+   Tony Hansen (editor)
+   AT&T Laboratories
+   200 Laurel Ave.
+   Middletown, NJ  07748
+   US
+
+   EMail: tony+eaidsn@maillennium.att.com
+
+
+   Chris Newman
+   Oracle
+   800 Royal Oaks
+   Monrovia, CA  91016-6347
+   US
+
+   EMail: chris.newman@oracle.com
+
+
+   Alexey Melnikov
+   Isode Ltd
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex  TW12 2BX
+   UK
+
+   EMail: Alexey.Melnikov@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hansen, et al.               Standards Track                   [Page 19]
+