doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc5337.txt b/doc/rfc/rfc5337.txt
new file mode 100644
index 0000000..b1e6726
--- /dev/null
+++ b/doc/rfc/rfc5337.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                          C. Newman
+Request for Comments: 5337                              Sun Microsystems
+Updates: 3461, 3464, 3798                               A. Melnikov, Ed.
+Category: Experimental                                         Isode Ltd
+                                                          September 2008
+
+
+    Internationalized Delivery Status and Disposition Notifications
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   Delivery status notifications (DSNs) are critical to the correct
+   operation of an email system.  However, the existing Draft Standards
+   (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-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-US-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 experimentally extends RFC 3461, RFC 3464, and RFC
+   3798.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                      [Page 1]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+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.  Additional Requirements on SMTP Servers  . . . . . . . . .  8
+   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  . . . . . . . . . 13
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
+   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
+     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
+     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
+   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                      [Page 2]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+1.  Introduction
+
+   When an email message is transmitted using the UTF8SMTP [RFC5336]
+   extension and Internationalized Email Headers [RFC5335], 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.
+
+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 use the Augmented Backus-Naur Form (ABNF) [RFC5234]
+   notation including the core rules defined in Appendix B of RFC 5234
+   [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 [RFC5335] 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 [RFC2821] server that advertises both the UTF8SMTP extension
+   [RFC5336] 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 UTF8SMTP.
+
+   This address type has 3 forms: utf-8-addr-xtext, utf-8-addr-unitext,
+   and utf-8-address.  The first 2 forms are 7-bit safe.
+
+   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 in the ORCPT parameter
+   when the SMTP server doesn't advertise support for UTF8SMTP or the
+   SMTP server supports UTF8SMTP, but the address contains US-ASCII
+   characters not permitted in the ORCPT parameter (e.g., the ORCPT
+   parameter forbids unencoded SP and the = character), or in a 7-bit
+
+
+
+Newman & Melnikov             Experimental                      [Page 3]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+   transport environment including a message/delivery-status Original-
+   Recipient or Final-Recipient field.  In the former case, the utf-8-
+   addr-xtext form (see below) MUST be used instead; in the latter case,
+   the utf-8-addr-unitext form MUST be used.  The utf-8-address form MAY
+   be used in the ORCPT parameter when the SMTP server also advertises
+   support for UTF8SMTP and the address doesn't contain any US-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 UTF8SMTP message.
+
+   In addition, the utf-8-addr-unitext form can be used anywhere where
+   the utf-8-address form is allowed.
+
+   When using in the ORCPT parameter, the UTF-8 address type requires
+   that US-ASCII CTLs, SP, \, +, and = be encoded using xtext encoding
+   as described in [RFC3461].  This is described by the utf-8-addr-xtext
+   form in the ABNF below.  Unicode characters MAY be included in a
+   UTF-8 address type using a "\x{HEXPOINT}" syntax
+   (EmbeddedUnicodeChar), where HEXPOINT is 2 to 6 hexadecimal digits.
+   When sending data to a UTF8SMTP-capable server, native UTF-8
+   characters SHOULD be used instead of the EmbeddedUnicodeChar syntax
+   described in details below.  When sending data to an SMTP server that
+   does not advertise UTF8SMTP, then the EmbeddedUnicodeChar syntax MUST
+   be used instead of UTF-8.
+
+   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 all xtext encoding
+   first (which will result in the utf-8-addr-unitext form), followed by
+   removal of 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.  It is hoped
+   that as systems lacking support for UTF8SMTP 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].
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                      [Page 4]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+  utf-8-type-addr     = "utf-8;" utf-8-enc-addr
+
+  utf-8-address       = uMailbox [ 1*WSP "<" Mailbox ">" ]
+    ; uMailbox is defined in [RFC5336].
+    ; Mailbox is defined in [RFC2821].
+
+  utf-8-enc-addr      = utf-8-addr-xtext /
+                        utf-8-addr-unitext /
+                        utf-8-address
+
+  utf-8-addr-xtext    = xtext
+                    ; xtext is defined in [RFC3461].
+                    ; When xtext encoding is removed,
+                    ; the syntax MUST conform to
+                    ; utf-8-addr-unitext.
+
+  utf-8-addr-unitext  = 1*(QUCHAR / EmbeddedUnicodeChar)
+                      ; MUST follow utf-8-address ABNF when
+                      ; dequoted
+
+  QUCHAR              = %x21-2a / %x2c-3c / %x3e-5b / %x5d-7e /
+                        UTF8-2 / UTF8-3 / UTF8-4
+                      ; US-ASCII printable characters except
+                      ; CTLs, SP, '\', '+' and '=', plus
+                      ; other Unicode characters in UTF-8
+
+  EmbeddedUnicodeChar =   %x5C.78 "{" HEXPOINT "}"
+                      ; starts with "\x"
+
+  HEXPOINT = "5C" / (HEXDIG8 HEXDIG) /    ; 2 digit forms
+             ( NZHEXDIG 2(HEXDIG) ) /     ; 3 digit forms
+             ( NZDHEXDIG 3(HEXDIG) ) /
+             ( "D" %x30-37 2(HEXDIG) ) /
+                      ; 4 digit forms excluding surrogate
+             ( NZHEXDIG 4(HEXDIG) ) /     ; 5 digit forms
+                     ( "10" 4*HEXDIG )    ; 6 digit forms
+             ; represents either "\" or a Unicode code point outside the
+             ; US-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"
+
+
+
+
+
+
+Newman & Melnikov             Experimental                      [Page 5]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+4.  UTF-8 Delivery Status Notifications
+
+   A traditional delivery status notification [RFC3464] comes in a
+   three-part multipart/report [RFC3462] 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 DSN format does not permit returning of
+   undeliverable UTF8SMTP messages, three new media types are needed.
+
+   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 UTF8SMTP [RFC5336]; the Diagnostic-Code field SHOULD be in
+   i-default language [DEFAULTLANG].  Second, systems generating a
+   message/global-delivery-status body part SHOULD use the utf-8-address
+   form of the UTF-8 address type for all addresses containing
+   characters outside the US-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, a
+   new optional field called Localized-Diagnostic is added.  Each
+   instance includes a language tag [LANGTAGS] 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].
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                      [Page 6]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+    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 ]
+         [ 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.
+
+   generic-address =/ utf-8-enc-addr
+     ; Only allowed with the "utf-8" address-type.
+     ;
+     ; 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 [LANGTAGS].
+
+   extension-field =/ extension-field-name ":" *utf8-text
+
+   text-fixed = %d1-9 /      ; Any Unicode character except for NUL,
+               %d11 /       ; CR and LF, encoded in UTF-8
+               %d12 /
+               %d14-127
+     ; Same as <text> from [RFC2822], but without <obs-text>.
+     ; If/when RFC 2822 is updated to disallow <obs-text>,
+     ; this should become just <text>
+     ; Also, if/when RFC 2822 is updated to disallow control characters
+     ; this should become a reference to RFC 2822upd instead.
+
+   utf8-text = text-fixed / UTF8-non-ascii
+
+   UTF8-non-ascii   = UTF8-2 / UTF8-3 / UTF8-4
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                      [Page 7]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+   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 [RFC5335].
+
+   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 UTF8SMTP message).
+   Unlike message/global, this body part provides no difficulties for
+   the present infrastructure.
+
+   Note that as far as multipart/report [RFC3462] 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,
+   implementations processing multipart/report MUST expect any
+   combinations of the 6 MIME types mentioned above inside a multipart/
+   report MIME 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 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 [RFC5335] relaxed restriction from MIME [RFC2046]
+   regarding use of Content-Transfer-Encoding in new "message" subtypes.
+   This specification explicitly allows use of Content-Transfer-Encoding
+   in message/global-headers and message/global-delivery-status.  This
+   is not believed to be problematic as these new MIME types are
+   intended primarily for use by newer systems with full support for
+   8-bit MIME and UTF-8 headers.
+
+4.1.  Additional Requirements on SMTP Servers
+
+   If an SMTP server that advertises both UTF8SMTP and DSN needs to
+   return an undeliverable UTF8SMTP message, then it MUST NOT downgrade
+   [DOWNGRADE] the UTF8SMTP message when generating the corresponding
+   multipart/report.  If the return path SMTP server does not support
+   UTF8SMTP, 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.
+
+
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                      [Page 8]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+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
+   language [DEFAULTLANG].)  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 US-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, which is an address header and thus follows the same 8-bit
+   rules as other address headers 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.
+
+
+
+
+
+
+Newman & Melnikov             Experimental                      [Page 9]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+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 RFC 3464.  The
+   registration template response follows:
+
+   (a) The proposed address-type name.
+
+       UTF-8
+
+   (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 US-ASCII repertoire, a specification for how
+       they are to be encoded as graphic US-ASCII characters in a DSN
+       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.  The first 2
+       forms are 7-bit safe.
+
+   The utf-8-address form MUST NOT be used
+
+   1.  in the ORCPT parameter when the SMTP server doesn't advertise
+       support for UTF8SMTP;
+
+   2.  or the SMTP server supports UTF8SMTP, but the address contains
+       US-ASCII characters not permitted in the ORCPT parameter (e.g.,
+       the ORCPT parameter forbids SP and the = characters);
+
+   3.  or in a 7-bit transport environment including a message/
+       delivery-status Original-Recipient or Final-Recipient field.
+
+   The utf-8-addr-xtext form MUST be used instead in the first case; the
+   utf-8-addr-unitext form MUST be used in the other two cases.  The
+   utf-8-address form MAY be used in the ORCPT parameter when the SMTP
+   server also advertises support for UTF8SMTP and the address doesn't
+   contain any US-ASCII characters not permitted in the ORCPT parameter;
+
+
+
+
+
+Newman & Melnikov             Experimental                     [Page 10]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+   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 UTF8SMTP message.
+
+   In addition, the utf-8-addr-unitext form can be used anywhere where
+   the utf-8-address form is allowed.
+
+6.2.  Update to 'smtp' Diagnostic Type Registration
+
+   The mail diagnostic type registry was created by RFC 3464.  The
+   registration for the 'smtp' diagnostic type should be updated to
+   reference RFC 5337 in addition to RFC 3464.
+
+   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 [RFC5335] 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.
+
+   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 downconvert this
+      media type to the text/rfc822-header media type, such conversion
+      is discouraged as it loses information.
+
+   Published specification:  RFC 5337
+
+
+
+
+
+Newman & Melnikov             Experimental                     [Page 11]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+   Applications that use this media type:  UTF8SMTP 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
+
+   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
+
+
+
+Newman & Melnikov             Experimental                     [Page 12]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+   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 5337
+
+   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
+
+6.5.  message/global-disposition-notification
+
+   Type name:  message
+
+   Subtype name:  global-disposition-notification
+
+   Required parameters:  none
+
+   Optional parameters:  none
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                     [Page 13]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+   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 5337
+
+   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.
+
+   Author:  See the Authors' Addresses section of this document.
+
+   Change controller:  IETF Standards Process
+
+
+
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                     [Page 14]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+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.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2821]      Klensin, J., "Simple Mail Transfer Protocol",
+                  RFC 2821, April 2001.
+
+   [RFC2822]      Resnick, P., "Internet Message Format", RFC 2822,
+                  April 2001.
+
+
+
+
+
+Newman & Melnikov             Experimental                     [Page 15]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+   [RFC3461]      Moore, K., "Simple Mail Transfer Protocol (SMTP)
+                  Service Extension for Delivery Status Notifications
+                  (DSNs)", RFC 3461, January 2003.
+
+   [RFC3462]      Vaudreuil, G., "The Multipart/Report Content Type for
+                  the Reporting of Mail System Administrative Messages",
+                  RFC 3462, 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.
+
+   [RFC5335]      Yang, A., Ed., "Internationalized Email Headers",
+                  RFC 5335, September 2008.
+
+   [RFC5336]      Yao, J., Ed. and W. Mao, Ed., "SMTP Extension for
+                  Internationalized Email Addresses", RFC 5336,
+                  September 2008.
+
+   [LANGTAGS]     Phillips, A. and M. Davis, "Tags for Identifying
+                  Languages", RFC 4646, September 2006.
+
+   [DEFAULTLANG]  Alvestrand, H., "IETF Policy on Character Sets and
+                  Languages", RFC 2277, January 1998.
+
+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.
+
+   [DOWNGRADE]    Fujiwara, K. and Y. Yoneya, "Downgrading mechanism for
+                  Email Address Internationalization", Work in Progress,
+                  July 2008.
+
+
+
+
+Newman & Melnikov             Experimental                     [Page 16]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+Appendix A.  Acknowledgements
+
+   Many thanks for input provided by Pete Resnick, James Galvin, Ned
+   Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, and
+   members of the EAI WG to help solidify this proposal.
+
+Authors' Addresses
+
+   Chris Newman
+   Sun Microsystems
+   800 Royal Oaks
+   Monrovia, CA  91016-6347
+   US
+
+   EMail: chris.newman@sun.com
+
+
+   Alexey Melnikov (editor)
+   Isode Ltd
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex  TW12 2BX
+   UK
+
+   EMail: Alexey.Melnikov@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                     [Page 17]
+
+RFC 5337             Internationalized DSN and MDNs       September 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Newman & Melnikov             Experimental                     [Page 18]
+