Internationalized Delivery Status and Disposition Notifications
obsoletes
- rfc-5337 — Internationalized Delivery Status and Disposition Notifications
updates
- rfc-3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
- rfc-3464 — An Extensible Message Format for Delivery Status Notifications
- rfc-3798 — Message Disposition Notification
- rfc-6522 — The Multipart/Report Media Type for the Reporting of Mail System Administrative Messages
Extracted elements (30)
The EmbeddedUnicodeChar encoding (\x{HEXPOINT}) is explicitly described as a transitional mechanism to avoid xtext encoding for non-ASCII characters; it is expected to be phased out as SMTPUTF8 support becomes universal and systems requiring 7-bit fallback become less common.
RFC 6533 obsoletes RFC 5337 (Experimental) by removing the embedded alternative ASCII address syntax within utf-8-address (the '<addr <addr>>' form is no longer permitted) and aligning ABNF with RFC 6531; media type names from RFC 5337 are preserved unchanged.
The three new media types (message/global-delivery-status, message/global, message/global-headers) must be treated as functionally equivalent to the legacy types (message/delivery-status, message/rfc822, text/rfc822-headers) by multipart/report processors, enabling gradual deployment without breaking existing infrastructure.
All instances of the Localized-Diagnostic field within a single per-recipient block MUST use different language tags.
An SMTP server that advertises both SMTPUTF8 and DSN MUST accept a UTF-8 address type in the ORCPT parameter, including 8-bit UTF-8 characters.
If an address is labeled with the UTF-8 address type but does not conform to UTF-8 syntax, it MUST be copied into the message/global-delivery-status field without alteration.
If an SMTP server advertising both SMTPUTF8 and DSN needs to return an undeliverable SMTPUTF8 message to a return-path server that does not support SMTPUTF8, the undeliverable body and headers MUST be encoded using a 7-bit Content-Transfer-Encoding such as base64 or quoted-printable.
Implementations MUST NOT include a charset parameter with the message/global-headers media type, as it must not be converted to a charset other than UTF-8.
Implementations processing multipart/report MUST treat message/global-delivery-status, message/global, and message/global-headers as equivalent to message/delivery-status, message/rfc822, and text/rfc822-headers respectively, and MUST expect any combination of the six media types inside a multipart/report.
The 8-bit Content-Transfer-Encoding MUST be used with message/global-delivery-status and message/global-disposition-notification, unless sent over a 7-bit transport environment, in which case quoted-printable or base64 may be necessary.
The utf-8-address form MUST NOT be used in the ORCPT parameter when the SMTP server does not advertise SMTPUTF8, when the address contains ASCII characters forbidden in ORCPT (e.g., SP or '='), or in a 7-bit transport environment including message/delivery-status fields; utf-8-addr-xtext MUST be used instead in those cases.
The utf-8-address form SHOULD be used in a message/global-delivery-status Original-Recipient or Final-Recipient field, and in an Original-Recipient header field if the message is a SMTPUTF8 message.
When sending data to a SMTPUTF8-capable server, native UTF-8 characters SHOULD be used instead of EmbeddedUnicodeChar syntax; when sending to a server that does not advertise SMTPUTF8, EmbeddedUnicodeChar MUST be used instead of raw UTF-8.
The Localized-Diagnostic field is an optional per-recipient DSN field containing language-tagged (RFC 5646) diagnostic text in UTF-8; it is equivalent to the text portion of Diagnostic-Code but may appear multiple times with distinct language tags.
The message/global-delivery-status media type extends message/delivery-status with UTF-8 charset support, allowing UTF-8 in all fields including Diagnostic-Code, use of utf-8-address form for addresses, and the new optional Localized-Diagnostic field carrying language-tagged diagnostic text.
The message/global-disposition-notification media type extends message/disposition-notification with UTF-8 charset, permitting UTF-8 in failure-field, error-field, and warning-field, and requiring use of the UTF-8 address type for non-ASCII addresses.
The message/global-headers media type contains only the UTF-8 header fields of a message (all lines prior to the first blank line in a SMTPUTF8 message), providing a header-only return type for internationalized DSNs.
The message/global media type is used for returning the full content of an undeliverable SMTPUTF8 message; it is similar to message/rfc822 but contains a message with UTF-8 headers as defined in RFC 6532.
The UTF-8 address type has three forms: utf-8-addr-xtext (7-bit safe, suitable for all transports), utf-8-addr-unitext (safe for ORCPT when SMTPUTF8 is advertised), and utf-8-address (native 8-bit form, only for protocols capable of native 8-bit representation).
The message/global-delivery-status MIME type has been registered; it carries UTF-8 DSN attributes, MUST use 8-bit CTE (or base64/QP over 7-bit transport), is expected as the second part of multipart/report, and carries the suggested file extension .u8dsn.
The message/global-disposition-notification MIME type has been registered; it carries UTF-8 MDN attributes, MUST use 8-bit CTE (or base64/QP over 7-bit transport), is expected as the second part of multipart/report, and carries the suggested file extension .u8mdn.
The message/global-headers MIME type has been registered; it carries UTF-8 email headers with no body, SHOULD use 8-bit CTE, MUST NOT include a charset parameter, and carries the suggested file extension .u8hdr.
The 'smtp' diagnostic type registration (originally in RFC 3464, updated by RFC 5337) has been updated to reference RFC 6533; when used in message/global-delivery-status context, the text portion MAY contain UTF-8 characters.
The UTF-8 mail address type has been registered in the mail address type registry (created by RFC 3464) with three encoding forms: utf-8-addr-xtext (7-bit safe), utf-8-addr-unitext, and utf-8-address.
Automated use of DSN/MDN report types without authentication enables denial-of-service via forged negative reports (disrupting directory/mailing-list maintenance) and false confidence via forged positive reports indicating delivery when none occurred.
Because forged envelope return paths cause widespread DSN blowback that erodes trust in delivery notifications, correlation of notifications with sent messages (short-term via Message-ID, long-term via cryptographic signatures) has become critical for email reliability.
Malicious users can craft report structures that trigger buffer overflow or denial-of-service vulnerabilities in report parsers; secure coding techniques and code reviews of parsers are required.
The EmbeddedUnicodeChar encoding uses the syntax \x{HEXPOINT} where HEXPOINT is 2 to 6 hexadecimal digits representing a Unicode code point; it encodes characters outside ASCII and ASCII special characters (CTLs, SP, '\', '+', '=') for use in utf-8-addr-xtext and utf-8-addr-unitext forms.
The utf-8-delivery-status-content ABNF consists of per-message-fields followed by one or more CRLF-separated utf-8-per-recipient-fields blocks, extending RFC 3464 to permit utf-8-enc-addr in generic-address and utf8-text in extension-field and diagnostic-code-field.
utf-8-addr-xtext is the 7-bit safe form consisting of QCHAR (ASCII printable excluding CTLs, SP, '\', '+', '=') and EmbeddedUnicodeChar sequences; utf-8-addr-unitext additionally allows UTF8-2/3/4 multi-byte sequences (QUCHAR) and must conform to utf-8-address when dequoted.