Internationalized Delivery Status and Disposition Notifications
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 notificat
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 14 must, 9 should, 8 may.
3 UTF-8 Address Type
- MUSTAn 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.
- MUST NOTThat is, the utf-8-address form MUST NOT be used:
- MUSTin the ORCPT parameter when the SMTP server doesn't advertise support for SMTPUTF8 (utf-8-addr-xtext MUST be used instead); or
- MUSTif 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
- MUSTin a 7-bit transport environment including a message/ delivery-status "Original-Recipient:" or "Final-Recipient:" field, (utf-8-addr-xtext MUST be used instead).
- MAYThe 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.
- SHOULDIt 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.
- SHOULDWhen sending data to a SMTPUTF8-capable server, native UTF-8 characters SHOULD be used instead of the EmbeddedUnicodeChar syntax described below.
- MUSTWhen sending data to an SMTP server that does not advertise SMTPUTF8, then the EmbeddedUnicodeChar syntax MUST be used instead of UTF-8.
- SHOULDWhen 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.
- MUSTHowever, 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.
- MUSTutf-8-addr-unitext = 1*(QUCHAR / EmbeddedUnicodeChar) ; MUST follow utf-8-address ABNF when ; dequoted.
4.1 The message/global-delivery-status Media Type
- MAYFirst, 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).
- MAYIn 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].
- SHOULDSecond, systems generating a message/global-delivery-status body part SHOULD use the utf-8-address
- SHOULDThese 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.
- MUSTAll instances of "Localized-Diagnostic:" MUST use different language tags.
4.4 Using These Media Types with multipart/report
- MUSTNote 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.
- MUSTimplementations processing multipart/report MUST expect any combinations of the 6 media types mentioned above inside a multipart/ report media type.
- MAY(In the event all content is 7-bit, the equivalent traditional types for delivery status notifications MAY be used.
4.5 Additional Requirements on SMTP Servers
- MUSTIf 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.
5 UTF-8 Message Disposition Notifications
- MAYFirst, 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).
- MAY(In particular, the failure-field, the error-field, and the warning-field MAY contain UTF-8.
- SHOULDThese fields SHOULD be in i-default
- SHOULDlanguage [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.
- SHOULDWhen 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.
6.2 Update to 'smtp' Diagnostic Type Registration
- MAYWhen 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.
- SHOULDWhenever possible, the 8-bit content transfer encoding SHOULD be used.
- MAYWhen this media type passes through a 7-bit-only SMTP infrastructure, it MAY be encoded with the base64 or quoted-printable content transfer encoding.
- MUST NOTAs a result, implementations MUST NOT include a charset parameter with this media type.
- MUSTThe 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.