RFC 5337

Internationalized Delivery Status and Disposition Notifications

📅 published September 2008, from ietf

RFC 5337: Internationalized Delivery Status and Disposition Notifications 💌

  • Network Working Group 🌸
  • Authors: C. Newman (Sun Microsystems) and A. Melnikov, Ed. (Isode Ltd) 🧁
  • Category: Experimental 🧪. This is an experiment, not an Internet standard.
  • Date: September 2008 📅
  • Updates: RFC 3461, RFC 3464, and RFC 3798 🔄
  • Obsoletes: nothing is listed in the title block 🙅‍♀️

Status of This Memo ✨

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Feedback and suggestions for improvement are super welcome. Distribution of this memo is unlimited. 🦋

Abstract 🌈

Delivery status notifications (DSNs) are a huge deal for email. The whole system depends on them working right 😭. The problem is that the existing Draft Standards (RFC 3461, RFC 3462, RFC 3464) only handle US-ASCII text in the machine-readable parts. This spec adds a new address type for international email addresses, so an original recipient address with non-US-ASCII characters can survive even after it gets downgraded 🫶. It also brings updated content return media types for delivery status notifications and message disposition notifications, so the new address type actually works with them 💖.

This document experimentally extends RFC 3461, RFC 3464, and RFC 3798. 🔥

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

1. Introduction 🧚

So when an email goes out using the UTF8SMTP [RFC5336] extension and Internationalized Email Headers [RFC5335], sometimes you need to send that message back or generate a Message Disposition Notification (MDN) [RFC3798]. 📨 A message sent to several recipients can produce a status and disposition notification for each one. That means it really helps if a client can match these notifications to the recipient address it originally gave, so keeping the original recipient around is important 🎀. This spec explains how to preserve the original recipient, and it 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 💌

[RFC3464] (the Extensible Message Format for Delivery Status Notifications) already has the idea of an address type. The address format from Internationalized Email Headers [RFC5335] is a brand-new address type ✨. Its syntax for status notifications is at the very end of this section 👇.

If an SMTP [RFC2821] server advertises both UTF8SMTP [RFC5336] and the DSN extension [RFC3461], it MUST accept a UTF-8 address type in the ORCPT parameter, and that includes 8-bit UTF-8 characters 🦋. This address type also has a 7-bit encoding that works in a message/delivery-status body part, or in an ORCPT parameter sent to a server that doesn't advertise UTF8SMTP 🌈.

There are 3 forms: utf-8-addr-xtext, utf-8-addr-unitext, and utf-8-address. The first 2 are 7-bit safe 🛡️.

The utf-8-address form is only for newly defined protocols that can natively handle 8-bit characters 💖. In other words, the utf-8-address form MUST NOT be used in the ORCPT parameter when the SMTP server doesn't advertise support for UTF8SMTP. It also MUST NOT be used when the server does support UTF8SMTP but the address contains US-ASCII characters that the ORCPT parameter doesn't allow (for example, the ORCPT parameter forbids unencoded SP and the = character). It MUST NOT be used in a 7-bit transport environment either, which includes a message/delivery-status Original-Recipient or Final-Recipient field 🙅‍♀️. In the former case (the first one), the utf-8-addr-xtext form (see below) MUST be used instead. In the latter case (the second one), 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 UTF8SMTP support and the address doesn't contain any US-ASCII characters that the ORCPT parameter doesn't allow 🍓. 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 🎀.

The utf-8-addr-unitext form can be used anywhere the utf-8-address form is allowed too 🧁.

When you use this address type in the ORCPT parameter, it requires that US-ASCII CTLs, SP, , +, and = get encoded using xtext encoding, as described in [RFC3461] 💅. The utf-8-addr-xtext form in the ABNF below describes this. 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 you're sending data to a UTF8SMTP-capable server, native UTF-8 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax, which is described in detail below 🫶. When you're 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 goes into a message/global-delivery-status Original-Recipient field, the utf-8-addr-xtext form SHOULD be converted to the utf-8-address form (see the ABNF below). You do that by removing all the xtext encoding first, which leaves you with the utf-8-addr-unitext form, and then removing the unitext encoding 🧼. However, if an address is labeled with the UTF-8 address type but doesn't follow utf-8 syntax, then it MUST be copied into the message/global-delivery-status field without alteration 🔒.

The EmbeddedUnicodeChar encodings should be viewed as a transitional mechanism 🦋. The hope is that as systems without UTF8SMTP support become less common over time, these encodings can eventually be phased out 🌷.

In the ABNF below, every production not defined in this document is 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       = 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"

4. UTF-8 Delivery Status Notifications ✨

Okay bestie, so a traditional delivery status notification [RFC3464] is a three-part multipart/report [RFC3462] container 📦. Part one is human-readable text explaining the error. Part two is a 7-bit-only message/delivery-status. Part three is optional and carries either the returned content (message/rfc822) or just the headers (text/rfc822-headers). The catch is that the current DSN format can't return undeliverable UTF8SMTP messages 😭, so we need three brand new media types 🦋.

The first one, message/global-delivery-status, has the same syntax as message/delivery-status with three glow-ups ✨. First, its charset is UTF-8, so any field MAY contain UTF-8 characters when it makes sense (check the ABNF). The Diagnostic-Code field MAY contain UTF-8 as described in UTF8SMTP [RFC5336], and it SHOULD be in i-default language [DEFAULTLANG]. Second, systems generating this body part SHOULD use the utf-8-address form of the UTF-8 address type for any address with characters outside the US-ASCII repertoire. Those systems SHOULD also up-convert the utf-8-addr-xtext or utf-8-addr-unitext form in the ORCPT parameter into the utf-8-address form in the Original-Recipient field. Third, there's a new optional field called Localized-Diagnostic 🌍. Each instance has a language tag [LANGTAGS] and text in that language, which is basically the text part of Diagnostic-Code. Every instance MUST use a different language tag, so no doubles, periodt. The ABNF for message/global-delivery-status is below.

In the ABNF, anything not defined in this document is 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.

 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

The second new type is message/global, which is basically message/rfc822 but holds a message with UTF-8 headers 💌. It's used for returning the content, and it's described in [RFC5335]. The third type is message/global-headers, which is for returning headers. It holds only the UTF-8 header fields of a message, meaning every line before the first blank line in a UTF8SMTP message 📝. Unlike message/global, this one gives the current infrastructure zero drama 💅.

Now, as far as the 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. So implementations processing multipart/report MUST expect any combination 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 💫. If all the content is 7-bit, the old traditional DSN types MAY be used instead. For example, if the info in a message/global-delivery-status part can be represented with zero loss as message/delivery-status, then the message/delivery-status body part may be used. Also, [RFC5335] relaxed a restriction from MIME [RFC2046] about Content-Transfer-Encoding in new "message" subtypes. This spec explicitly allows Content-Transfer-Encoding in message/global-headers and message/global-delivery-status. That's not expected to be a problem, since these new types are meant mainly for newer systems with full 8-bit MIME and UTF-8 headers 🦋.

4.1. Additional Requirements on SMTP Servers

Okay this one is important, bestie 🚨. If an SMTP server advertises both UTF8SMTP and DSN and needs to return an undeliverable UTF8SMTP message, then it MUST NOT downgrade [DOWNGRADE] the UTF8SMTP message when generating the matching multipart/report 🙅‍♀️. If the return path SMTP server doesn't support UTF8SMTP, then the undeliverable body part and headers MUST be encoded with 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 very similar design and structure to DSNs, so they use the same basic return format 💖. When generating an MDN for a UTF-8 header message, the third part of the multipart/report holds the returned content (message/global) or header (message/global-headers), same as for DSNs. The second part uses a new media type, message/global-disposition-notification, which has the syntax of message/disposition-notification with two modifications. First, its charset is UTF-8, so any field MAY contain UTF-8 characters when appropriate (see the ABNF). The failure-field, error-field, and warning-field MAY contain UTF-8 too, and these SHOULD be in i-default language [DEFAULTLANG]. Second, systems generating a message/global-disposition-notification body part (usually a mail user agent) SHOULD use the UTF-8 address type for all addresses with characters outside the US-ASCII repertoire 🌸.

The MDN spec also defines the Original-Recipient header field, which gets a copy of the ORCPT contents at delivery time. When a delivery agent writing a UTF-8 header message in native format generates an Original-Recipient header field, it SHOULD convert the utf-8-addr-xtext or utf-8-addr-unitext form of the UTF-8 address type in the ORCPT parameter to the matching utf-8-address form ✨.

Last one: the MDN spec also defines the Disposition-Notification-To header, which is an address header. So it follows the same 8-bit rules as other address headers like From and To when it's 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 spec doesn't create any new IANA registries 🙌. However, the following items got registered because of this document.

6.1. UTF-8 Mail Address Type Registration

The mail address type registry was created by RFC 3464 🗂️. Here's the registration template response:

(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 another non-ambiguous language: See Section 3.

(c) If addresses of this type are not made up 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 🛡️.

Now the tea ☕. 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 when the SMTP server supports UTF8SMTP but the address contains US-ASCII characters that aren't 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.

So the utf-8-addr-xtext form MUST be used instead in the first case, and 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 that aren't permitted in the ORCPT parameter. It MAY also 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 🎉.

And one more bonus: the utf-8-addr-unitext form can be used anywhere the utf-8-address form is allowed 💜.

6.2. Update to 'smtp' Diagnostic Type Registration

The mail diagnostic type registry was also 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 a message/delivery-status body part, it stays exactly as it's presently defined. When it's used in a message/global-delivery-status body part, the codes stay 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: okay so this type is basically Internationalized Email Headers [RFC5335] with no message body at all 🫶 Whenever possible, the 8-bit content transfer encoding SHOULD be used. If it goes through a 7-bit-only SMTP setup, it MAY be encoded with base64 or quoted-printable instead.
  • Security considerations: see Section 7 💀
  • Interoperability considerations: the charset has to stay UTF-8, so implementations MUST NOT include a charset parameter with this media type 🙅‍♀️ You could downconvert it to text/rfc822-header, but it's discouraged because you lose information, and that's just sad 😭
  • Published specification: RFC 5337
  • 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): if it gets saved to a file, the extension .u8hdr is suggested 📁
    • Macintosh file type code(s): the 'TEXT' type code is suggested, since these files are mostly used for diagnostics and open nicely in a UTF-8 aware text editor ✨ A uniform type identifier (UTI) of public.utf8-email-message-header is suggested too. It 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 one has textual data in the UTF-8 charset, and it usually has octets with the 8th bit set 🌈 So 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 type holds delivery status notification attributes in the UTF-8 charset 💜 The 8-bit content transfer encoding MUST be used with this content-type, unless it's sent over a 7-bit transport environment. In that case, quoted-printable or base64 may be necessary.
  • Security considerations: see Section 7
  • Interoperability considerations: this is giving the same vibe as the message/delivery-status content-type for email message return information 🦋 Clients of the previous format will need to be upgraded to read the new one. The good news is that the new media type makes it super easy to tell the two apart.
  • 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
  • Encoding considerations: this type carries disposition notification attributes in the UTF-8 charset ✨ The 8-bit content transfer encoding MUST be used with this content-type, unless it's sent over a 7-bit transport environment. Then quoted-printable or base64 may be necessary.
  • Security considerations: see Section 7.
  • Interoperability considerations: this one's 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. Again, 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

7. Security Considerations 🚨

Okay bestie, this part is seriously important, so read it carefully 🥺 Automated use of report types without authentication opens up several security issues. Forged negative reports can lead to denial-of-service attacks when they're used to automatically maintain directories or mailing lists. Forged positive reports may make the sender incorrectly believe a message was delivered when it wasn't 💀

Malicious users can build report structures designed to trigger coding flaws in report parsers. Parsers need to use secure coding techniques so they don't end up with a buffer overflow or denial-of-service risk from their own mistakes. Code reviews of these parsers are also recommended 🔍

Here's the tea: malicious users of the email system regularly send messages with forged envelope return paths 🙃 Those messages then trigger delivery status reports that flood the Internet with a huge amount of unwanted traffic. A lot of users ignore delivery status notifications because they're usually "blowback" from forged messages, so they never notice when their own messages don't get delivered. That's why correlating delivery status and message disposition notifications with sent messages has become a critical feature for mail clients and possibly mail stores, if email is going to stay reliable 🔥 In the short term, correlating message-IDs may be enough to tell real status notifications apart from the ones caused by forged originator addresses. In the longer term, including cryptographic signature material that can securely tie the status notification to the original message is advisable 🔐

As this specification allows 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.
  • [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.

Appendix A. Acknowledgements 🫶

Huge thank-yous to Pete Resnick, James Galvin, Ned Freed, John Klensin, Harald Alvestrand, Frank Ellermann, SM, and the members of the EAI WG 💖 Your input helped make this proposal solid, and we love you for it ✨

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

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 💅

okay so the IETF is not picking a side on whether any intellectual property rights or other rights someone might claim over the tech in this doc are valid, or how far they reach 🤷‍♀️ it's also not saying whether a license for them is even available. and it's not claiming it did its own digging to find any of those rights 🔍 if you want the deets on how rights work for RFC docs, check out BCP 78 and BCP 79 📚

the IPR disclosures that get sent to the IETF Secretariat are stored in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️ that's also where you'll find any assurances of licenses that will be made available, plus the results of any attempt to get a general license or permission for implementers or users to use those proprietary rights 💜

and the IETF really wants to hear from you ✨ if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard, send the info to the IETF at ietf-ipr@ietf.org 🫶 literally that's the whole vibe, bestie 💖

📦 where this page comes from