Post-Delivery Message Downgrading for Internationalized Email Messages
Extracted elements (25)
All encoded-words generated during downgrading use UTF-8 as their charset. This choice allows the original non-ASCII Unicode content to be preserved in encoded form within ASCII-only header fields, enabling receivers to recognize that a message was internationalized.
Post-delivery downgrading is described as an interim 'least bad' solution while clients are upgraded. It converts internationalized messages to all-ASCII representation so legacy POP/IMAP clients can receive them, but cannot generally preserve enough information for lossless replies.
Many deployed encoded-word implementations fail to correctly handle whitespace between adjacent encoded words per RFC 2047. Implementations MAY use overly long encoded words to work around these faulty implementations, but SHOULD provide an optional mechanism to limit line length to 78 characters.
The Group Syntax document (RFC 6854) updates RFC 5322 to allow empty <group> elements in From: and Sender: header fields; this is required because the downgrading procedure for those fields may generate empty <group> elements.
Applying Encapsulation to the 'Received:' header field is prohibited. Only Message-ID, In-Reply-To, References, Original-Recipient, and Final-Recipient fields may use encapsulation downgrading.
For address header fields (From, Sender, To, Cc, Bcc, Reply-To, Return-Path, Disposition-Notification-To, and Resent-* variants), downgrading must first apply Comment and Display-Name downgrading, then Group downgrading for non-ASCII group addresses, then Mailbox downgrading for non-ASCII mailbox addresses.
For Message-ID, Resent-Message-ID, In-Reply-To, and References: if non-ASCII strings appear in <id-left> or <id-right> elements, perform Encapsulation; otherwise perform Comment downgrading.
For the Received header field, perform Domain downgrading for U-labels and Comment downgrading for non-ASCII comments. After those steps, if the FOR clause contains a non-ASCII local-part, remove the FOR clause; if the ID clause contains a non-ASCII value, remove the ID clause.
For unknown or implementation-specific header fields containing non-ASCII strings, perform Unstructured downgrading by default. Software that understands a field's structure and can apply a more specific downgrading algorithm SHOULD use that algorithm instead.
Comment downgrading converts non-ASCII strings in <comment> fields to encoded-word encoding, applicable to many header fields that are otherwise ASCII-only except in comments.
Delivery status notification downgrading applies Type-Addr downgrading to Original-Recipient and Final-Recipient header fields when they contain non-ASCII strings.
Domain downgrading rewrites non-ASCII U-label domain names into ASCII A-labels using IDNA (RFC 5891) for any <domain> elements containing U-labels.
Encapsulation (last resort) deletes unconvertible header fields and replaces them with Downgraded-* header fields whose values are the original field values encoded as encoded-words. Defined fields are: Downgraded-Message-Id, Downgraded-Resent-Message-Id, Downgraded-In-Reply-To, Downgraded-References, Downgraded-Original-Recipient, and Downgraded-Final-Recipient.
Group downgrading: if a <group> element contains a mailbox with a non-ASCII local-part, the entire <group-list> is encoded as encoded-words and rewritten as 'display-name ENCODED_WORD :;'. If local-parts are ASCII-only, non-ASCII domain names in mailboxes are rewritten using A-labels.
Mailbox downgrading: if <local-part> is ASCII-only, non-ASCII domains are converted to A-labels. If <local-part> contains non-ASCII characters (which have no ASCII equivalent), the entire <addr-spec> is encoded as encoded-words and rewritten as 'ENCODED-WORD :;'.
MIME body part header field downgrading parses the message's MIME structure at all levels; Content-ID, Content-Type, Content-Disposition, and Content-Description body part header fields containing non-ASCII strings are downgraded using the same methods as the corresponding top-level header fields.
MIME-Value downgrading removes CFWS outside DQUOTE from <value> elements containing non-ASCII strings, then encodes those elements as extended MIME parameter encodings (RFC 2231) with empty language information.
Type-Addr downgrading converts <utf-8-type-addr> containing raw non-ASCII strings from utf-8-address form to utf-8-addr-xtext form (RFC 6533); if the address type is unrecognized and contains non-ASCII strings, the entire header field is encapsulated.
Unstructured downgrading converts non-ASCII strings in <unstructured> header field elements by applying encoded-word encoding (RFC 2047), resulting in ASCII-only header field values.
Word downgrading converts non-ASCII strings in <word> fields to encoded-word encoding. Display-Name downgrading uses the same algorithm.
Five new standard header fields were registered in the Permanent Message Header Field Names registry: Downgraded-Message-Id, Downgraded-In-Reply-To, Downgraded-References, Downgraded-Original-Recipient, and Downgraded-Final-Recipient, all applicable to the mail protocol and defined in Section 3.1.10.
IANA changed the status of all Downgraded-* header fields previously registered as experimental under RFC 5504 to 'obsoleted' in the Permanent Message Header Field Names registry, lifting the prior restriction on new Downgraded-* registrations.
As much information as possible from the original internationalized message SHOULD be preserved during downgrading. The mechanism allows receivers to know a message was internationalized, though it does not generally permit lossless replies.
Downgrading invalidates digital signatures over any part of the message, breaking DKIM and possibly S/MIME and PGP. The downgrade mechanism SHOULD NOT remove signatures even if they will fail validation after downgrading; MUAs may use Authentication-Results header fields to assess pre-downgrade validity.
Rewriting header fields during downgrading increases opportunities for undetected spoofing by malicious senders. Downgraded-* header fields are not inspected by traditional MUAs and may be less trustworthy than standard header fields; they could have been inserted with malicious content unrelated to the original header fields.