IMAP Support for UTF-8
Extracted elements (20)
The IMAP base specification forbids 8-bit characters in atoms or quoted-strings, requiring UTF-8 to be sent as literals, which adds extra round trips unless the server supports non-synchronizing literals (RFC 2088). The "UTF8=ACCEPT" extension was introduced to allow UTF-8 directly in quoted-strings and reduce this overhead.
The "UTF8=ONLY" capability mechanism was chosen over a "just-send-UTF-8 IMAP" approach because diagnosing interoperability problems caused by an implicit UTF-8 mode is difficult. Explicit capability announcement makes problems visible and easier to diagnose, even though a "just-send-UTF-8" approach might work with some legacy clients.
When a server supporting this extension is accessed by a legacy client that does not enable UTF-8 capability, the server may hide problematic messages, create surrogate messages, or provide notifications. Surrogate messages cannot serve as actual substitutes and may break digital signatures and UIDVALIDITY assumptions.
When an IMAP server uses a mailbox format that supports UTF-8 headers and permits selection without first issuing "ENABLE UTF8=ACCEPT", it is the server's responsibility to comply with RFC 3501 and RFC 5322 for all header information transmitted over the wire.
A client MUST use the "ENABLE" command with the "UTF8=ACCEPT" option to indicate acceptance of UTF-8 in quoted-strings. The "ENABLE UTF8=ACCEPT" command is only valid in the authenticated state.
A client that sends a message with UTF-8 headers MUST use the "UTF8" data extension to the APPEND command. If the client has not issued "ENABLE UTF8=ACCEPT", the server MUST reject with a "NO" response any APPEND command that includes 8-bit characters in message header fields.
A server advertising "UTF8=ONLY" will reject with a "NO [CANNOT]" response any command that might require UTF-8 support and is not preceded by an "ENABLE UTF8=ACCEPT" command. Clients MUST use "ENABLE UTF8=ACCEPT" before using such a server.
All IMAP servers supporting "UTF8=ACCEPT" SHOULD accept UTF-8 in mailbox names; servers that also support the Mailbox International Naming Convention MUST accept UTF8-quoted mailbox names and convert them to the appropriate internal format.
Implementations that choose to perform message downgrading for legacy clients SHOULD use one of the standardized algorithms provided in RFC 6857 (Post-Delivery Message Downgrading) or RFC 6858 (Simplified POP and IMAP Downgrading).
Mailbox names MUST comply with the Net-Unicode Definition (RFC 5198, Section 2) and MUST NOT contain control characters (U+0000–U+001F, U+0080–U+009F), a delete character (U+007F), a line separator (U+2028), or a paragraph separator (U+2029).
Once an IMAP client has enabled UTF-8 support with "ENABLE UTF8=ACCEPT", it MUST NOT issue a SEARCH command containing a charset specification; if the server receives such a command, it SHOULD reject it with a "BAD" response due to conflicting charset labels.
This specification does not extend the IMAP LOGIN command to support UTF-8 usernames and passwords. Whenever a client needs to use UTF-8 usernames or passwords, it MUST use the IMAP AUTHENTICATE command, which is already capable of passing UTF-8 usernames and credentials.
When a client is upgraded from non-"UTF8=ACCEPT"-aware to aware, it MUST discard its cache of messages downloaded from the server, to cope with the case where a compliant server returns the same UIDVALIDITY to both legacy and UTF8=ACCEPT-aware clients.
When the extended UTF-8 quoting mechanism is used, the server MUST reject with a "BAD" response any octet sequences with the high bit set that fail to comply with the formal syntax of UTF-8 (RFC 3629). The server MUST NOT send UTF-8 in quoted-strings unless the client has issued "ENABLE UTF8=ACCEPT".
The "UTF8=ACCEPT" capability indicates that the server supports opening mailboxes containing internationalized messages via SELECT and EXAMINE, and can provide UTF-8 responses to LIST, LSUB, NAMESPACE, and ACL commands. A server supports "UTF8=ACCEPT" if it advertises either "UTF8=ACCEPT" or "UTF8=ONLY".
The UTF8 APPEND data extension allows a client to send messages with UTF-8 headers to the server using the syntax: utf8-literal = "UTF8" SP "(" literal8 ")". This extends both the APPEND command and the CATENATE extension (RFC 4469).
The "UTF8=ONLY" capability indicates that the server requires UTF-8 support from clients, will send UTF-8 in quoted-strings, and will not accept the older modified UTF-7 mailbox name convention. It implies "UTF8=ACCEPT", so at most one of these appears in the capability string.
This document redefines two capabilities ("UTF8=ACCEPT" and "UTF8=ONLY") in the "IMAP 4 Capabilities" registry, referencing RFC 6855. Three capabilities from the experimental predecessor RFC 5738 — "UTF8=ALL", "UTF8=APPEND", and "UTF8=USER" — are now marked OBSOLETE.
The security considerations of UTF-8 (RFC 3629) and SASLprep (RFC 4013) apply, particularly regarding use of UTF-8 in usernames and passwords. Special security considerations arise when a server conforming to this specification is accessed by a non-conforming client or when the same message is accessed by multiple clients using different protocols or capabilities.
The extended quoted-string syntax adds uQUOTED-CHAR = QUOTED-CHAR / UTF8-2 / UTF8-3 / UTF8-4, allowing multi-byte UTF-8 sequences (as defined in RFC 3629 Section 4) inside IMAP quoted-strings when UTF8=ACCEPT is enabled.