IMAP Support for UTF-8
This specification extends the Internet Message Access Protocol, specifically IMAP4rev1 (RFC 3501), to support UTF-8 encoded international characters in user names, mail addresses, and message headers. This specification replaces RFC 6855. This specification does not extend IMAP4rev2 (RFC 9051), since that protocol includes everything in this extension.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 11 must, 4 should, 2 may.
3 "UTF8=ACCEPT" IMAP Capability and UTF-8 in IMAP Quoted-Strings
- MUSTA client MUST use the "ENABLE" command [RFC5161] with the "UTF8=ACCEPT" option (defined in Section 4 below) to indicate to the server that the client accepts UTF-8 in quoted-strings and supports the "UTF8=ACCEPT" extension.
- MUSTWhen this extended quoting mechanism is used by the client, 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 [RFC3629].
- MUST NOTThe IMAP server MUST NOT send UTF-8 in quoted-strings to the client unless the client has indicated support for that syntax by using the "ENABLE UTF8=ACCEPT" command.
- MAYIf the server supports "UTF8=ACCEPT", the client MAY use extended quoted syntax with any IMAP argument that permits a string (including astring and nstring).
- SHOULDAll IMAP servers that support "UTF8=ACCEPT" SHOULD accept UTF-8 in mailbox names, and those that also support the Mailbox International Naming Convention described in [RFC3501], Section 5.1.3, MUST accept UTF-8 in mailbox names and convert them to the appropriate internal format.
- MUSTMailbox names MUST comply with the Net-Unicode Definition ([RFC5198], Section 2) with the specific exception that they MUST NOT contain control characters (U+0000 - U+001F and U+0080 - U+009F), a delete character (U+007F), a line separator (U+2028), or a paragraph separator (U+2029).
- MUST NOTOnce an IMAP client has enabled UTF-8 support with the "ENABLE UTF8=ACCEPT" command, it MUST NOT issue a "SEARCH" command that contains a charset specification.
- SHOULDIf an IMAP server receives such a "SEARCH" command in that situation, it SHOULD reject the command with a "BAD" response (due to the conflicting charset labels).
- SHOULDFor commands with a mandatory charset field, such as SORT and THREAD, servers SHOULD reject charset values other than UTF-8 with a "BAD" response (due to the conflicting charset labels).
4 "APPEND" Command
- MUSTIf an IMAP server supports "UTF8=ACCEPT" and the IMAP client has not issued the "ENABLE UTF8=ACCEPT" command, the server MUST reject, with a "NO" response, an "APPEND" command that includes any 8-bit character in message header fields.
5 "LOGIN" Command and UTF-8
- MUSTWhenever 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.
6 FETCH BODYSTRUCTURE and message/global
- MAYWhen IMAP4rev1 and UTF8=ACCEPT has been enabled, the server MAY treat message/global like message/rfc822 when computing the body structure, but MAY also treat it as described in [RFC3501].
- MUSTClients MUST accept both cases.
- MUSTWhen IMAP4rev2 and UTF8=ACCEPT are in use, the server MUST behave as described in [RFC9051].
7 "UTF8=ONLY" Capability
- MUSTBecause these are incompatible changes to IMAP, explicit server announcement and client confirmation are necessary: clients MUST use the "ENABLE UTF8=ACCEPT" command before using this server.
8 Dealing with Legacy Clients
- SHOULDImplementations that choose to perform downgrading SHOULD use one of the standardized algorithms provided in [RFC6857] or [RFC6858].
- MUSTAdditionally, in order to cope with the case when a server compliant with this extension returns the same UIDVALIDITY to both legacy and "UTF8=ACCEPT"-aware clients, a client upgraded from being non-"UTF8=ACCEPT"-aware MUST discard its cache of messages downloaded from the server.