IMAP Support for UTF-8
obsoletes
- rfc-6855 — IMAP Support for UTF-8
Extracted elements (21)
APPEND's UTF8 data item from RFC 6855 was removed to align with IMAP4rev2 (RFC 9051) syntax and simplify client code for supporting both protocol versions. No client could reliably determine whether a stored message used the UTF8 item, and the only known client using it did so incorrectly (sending it for all messages regardless of UTF-8 content).
The FETCH BODYSTRUCTURE media-message syntax was made optional (MAY treat message/global like message/rfc822) because IMAP4rev1 and IMAP4rev2 differ slightly in this area, and implementers were not previously informed of the difference. Clients must parse both varieties to support both protocol versions anyway.
The 'UTF8=ONLY' capability mechanism was chosen over the simpler approach of 'just-send-UTF-8' because diagnosing interoperability problems caused by an undeclared UTF-8 mode is difficult. Explicit server announcement and client confirmation simplify failure diagnosis when legacy support is absent.
Surrogate (downgraded) messages cannot be actual substitutes for originals: digital signatures over the original will often fail verification on the surrogate. Servers serving the same user via multiple clients (POP, webmail, IMAP) must exert extreme care to ensure UIDVALIDITY behaves as expected.
A client MUST use the 'ENABLE' command with the 'UTF8=ACCEPT' option to indicate acceptance of UTF-8 in quoted-strings. This command is only valid in the authenticated state.
A client upgraded from non-UTF8=ACCEPT-aware status MUST discard its cache of messages downloaded from the server, to cope with the case where a server returns the same UIDVALIDITY to both legacy and UTF8=ACCEPT-aware clients.
All servers supporting UTF8=ACCEPT SHOULD accept UTF-8 in mailbox names. Those also supporting the Mailbox International Naming Convention (RFC 3501, Section 5.1.3) MUST accept UTF-8 mailbox names and convert them to the appropriate internal format. Mailbox names MUST comply with Net-Unicode (RFC 5198, Section 2) and MUST NOT contain control characters, delete, line separator (U+2028), or paragraph separator (U+2029).
Clients MUST use the 'ENABLE UTF8=ACCEPT' command (never 'ENABLE UTF8=ONLY') before using a UTF8=ONLY server. A server advertising UTF8=ONLY will include at most one of UTF8=ACCEPT or UTF8=ONLY in its capability string, never both.
If an IMAP server supports UTF8=ACCEPT and 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.
Implementations that choose to perform downgrading of internationalized messages for legacy clients SHOULD use one of the standardized algorithms in RFC 6857 (Post-Delivery Message Downgrading) or RFC 6858 (Simplified POP and IMAP Downgrading).
Once a client has enabled UTF-8 support with 'ENABLE UTF8=ACCEPT', it MUST NOT issue a SEARCH command containing a charset specification. Servers SHOULD reject such commands with 'BAD'. For commands with mandatory charset fields (SORT, THREAD), servers SHOULD reject non-UTF-8 charset values with 'BAD'.
The IMAP server MUST NOT send UTF-8 in quoted-strings to the client unless the client has indicated support by issuing 'ENABLE UTF8=ACCEPT'.
This specification does not extend the IMAP LOGIN command to support UTF-8 usernames or passwords. Whenever a client needs to use UTF-8 credentials, it MUST use the IMAP AUTHENTICATE command, which is already capable of passing UTF-8 usernames and credentials.
When a client uses the extended quoting mechanism, the server MUST reject with a 'BAD' response any octet sequences with the high bit set that fail to comply with the formal syntax requirements of UTF-8 (RFC 3629).
When IMAP4rev1 and UTF8=ACCEPT are enabled, the server MAY treat message/global like message/rfc822 for body structure, or MAY treat it as per RFC 3501. Clients MUST accept both cases. When IMAP4rev2 and UTF8=ACCEPT are in use, the server MUST behave as described in RFC 9051.
The 'UTF8=ACCEPT' capability indicates server support for opening internationalized mailboxes via SELECT/EXAMINE and for UTF-8 responses to LIST/LSUB. It also affects NAMESPACE, ACL, and other extensions that return mailbox names.
The 'UTF8=ONLY' capability implies UTF8=ACCEPT and signals that the server requires UTF-8 support from clients. It will send UTF-8 in quoted-strings and will not accept modified UTF-7 mailbox names. Servers advertising UTF8=ONLY reject commands that require UTF-8 support without a preceding 'ENABLE UTF8=ACCEPT' with 'NO [CANNOT]'.
IANA has updated the 'IMAP Capabilities' registry to reference this document (RFC 9755) instead of RFC 6855 for the following entries: UTF8=ACCEPT, UTF8=ALL (OBSOLETE), UTF8=APPEND (OBSOLETE), UTF8=ONLY, and UTF8=USER (OBSOLETE).
The security considerations of UTF-8 (RFC 3629) and PRECIS Usernames and Passwords (RFC 8265) apply, particularly for UTF-8 in usernames and passwords. Mixed-client access scenarios—where one client supports UTF8=ACCEPT and another does not—create additional security-relevant complexity discussed in Section 8.
The media-message ABNF production is extended to: DQUOTE "MESSAGE" DQUOTE SP DQUOTE ("RFC822" / "GLOBAL") DQUOTE, aligning IMAP4rev1 with IMAP4rev2 (RFC 9051) for handling message/global body structure responses.
When UTF8=ACCEPT is active, IMAP quoted-strings are extended via uQUOTED-CHAR, which adds UTF8-2, UTF8-3, and UTF8-4 (as defined in RFC 3629) to the existing QUOTED-CHAR production. The base QUOTED-CHAR non-terminal is not modified.