Simplified POP and IMAP Downgrading for Internationalized Email
updates
- rfc-3501 — INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
Extracted elements (18)
The surrogate message is not intended to convey any information to client software that would require or enable special handling. Client authors wishing to handle internationalized messages are encouraged to implement full UTF-8 support via RFC6856 (POP) or RFC6855 (IMAP) instead.
This specification values simplicity of implementation over fidelity of representation. Implementing a high-fidelity downgrade algorithm (RFC6857) is considered more work than implementing proper UTF-8 support for POP/IMAP, so this simpler approach is provided for servers that need a quick path.
DOWNGRADED does not necessarily mention all internationalized messages in the mailbox — only those that were synthesized during the specific FETCH operation. A message not listed may still contain internationalized content in fields not fetched (e.g., an internationalized Subject but non-internationalized From/To/Cc).
For POP, the number of lines specified in the TOP command (RFC1939) refers to the surrogate message. The message size reported by LIST may refer to either the internationalized or the surrogate message, giving servers flexibility.
This document updates RFC3501 (IMAP4rev1) by relaxing the requirement that sizes returned for messages be exact, permitting servers to return the original internationalized message size for surrogate messages, and by adding the DOWNGRADED response code reporting requirement.
The format of the display-name replacing an internationalized address is explicitly unspecified — anything that informs the user is acceptable, but anything that could produce an email address belonging to someone else is prohibited.
This specification relaxes the RFC3501 requirement that IMAP-reported message sizes be exact. When a conventional client requests size information for an internationalized message, the IMAP server is permitted to return the size of the original internationalized message even though the surrogate message differs in size.
Any header field that cannot be presented to the client, even after applying the address replacement, MIME parameter excision, and Subject encoding modifications, is silently excised from the surrogate message.
Any MIME parameter (RFC2045) in the message header or a body part header that cannot be presented to the client exactly as it appears in the incoming message is silently excised. For example, 'Content-Disposition: attachment; filename=FOO' becomes 'Content-Disposition: attachment'.
Each internationalized email address in the header fields Bcc, Cc, From, Reply-To, Resent-Bcc, Resent-Cc, Resent-From, Resent-Sender, Resent-To, Return-Path, Sender, and To is replaced with an invalid email address (using the .invalid TLD) whose display-name communicates what happened. Addresses in other fields such as Received are not affected.
If the Subject field cannot be presented to the client exactly as it appears in the incoming message, the server presents a representation encoded as specified in RFC 2047 (MIME header extensions for non-ASCII text).
When an IMAP server performs downgrading as part of generating FETCH responses, it MUST report which messages were synthesized using the DOWNGRADED response code with an attendant UID set. Example: 'a OK [DOWNGRADED 70,105,108,109] Done'. The message-set argument contains UIDs of downgraded messages.
When an internationalized message must be presented to a conventional client, the server synthesizes a 'surrogate message' — a conventional message containing most of the original information. The surrogate is intended to convey important information to the user, not to signal special handling to client software.
IANA has added the DOWNGRADED response code to the 'IMAP Response Codes' registry, as defined in this document for reporting which messages were synthesized as surrogate messages during FETCH operations.
Clients that cache messages for a long time (e.g., stock Android client) must not serve a cached surrogate message after the client is upgraded to support internationalized email; they must retrieve the real message from the server instead.
Excised header fields may include 'Message-Id:', 'In-Reference-To:', and 'References:', which can cause loss of threading context for the recipient. Any excised information simply does not arrive at the recipient.
If the internationalized message uses any signature covering header fields, the surrogate message's signature is almost certainly invalid because the header fields have been modified. Despite being invalid, signatures SHOULD NOT be removed from the surrogate message, to preserve as much information as possible. Full discussion is in RFC6857.
POP and IMAP clients such as Fetchmail that download messages and delete the server copies may cause permanent loss of information when the only remaining version is the surrogate message, which lacks the full internationalized content.