Post Office Protocol Version 3 (POP3) Support for UTF-8
obsoletes
- rfc-5721 — POP3 Support for UTF-8
Extracted elements (24)
The specification aims to deprecate RFC 2047 MIME Message Header Extensions and RFC 2231 extended MIME parameter encodings (7-bit encoding mechanisms) in the future, as they have caused interoperability problems and have seen limited deployment compared to the hoped-for prevalence of native UTF-8 header support.
The USER capability and non-ASCII credential support are optional because the implementation burden of SASLprep is not well understood, and mandating it in all cases could negatively impact deployment of the overall UTF-8 extension.
MIME binary content-transfer-encoding (RFC 2045 Section 6.2) remains prohibited even in UTF-8 mode; only MIME 8bit content-transfer-encoding (8BITMIME, RFC 6152) is permitted for non-ASCII content.
When a server is not in UTF-8 mode and receives a request for a message requiring UTF-8, it MAY reject the command with an -ERR response (using the UTF8 response code) or may attempt to create and deliver a surrogate form of the message as described in Section 7 of RFC 6855 (IMAP Support for UTF-8).
A client or server that supports APOP and permits UTF-8 in usernames or passwords MUST apply SASLprep to the username and password used to compute the APOP digest.
Clients MUST NOT issue the STLS command after issuing UTF8. Servers MAY enforce this by rejecting with -ERR any STLS command issued after a successful UTF8 command.
Clients MUST NOT use UTF-8 characters when authenticating if the server did not include the USER argument in the UTF8 capability response.
In UTF-8 mode, if the maildrop encoding is a format other than UTF-8 or ASCII, the messages' encoding format SHOULD be converted to UTF-8 before being sent to the client.
Servers that include the USER argument in the UTF8 capability SHOULD apply SASLprep (RFC 4013) or a Standards Track successor to the arguments of the USER and PASS commands.
The octet count of a message reported in a LIST response SHOULD match the actual number of octets sent in a RETR response (not counting byte-stuffing).
The server MUST reject UTF-8 usernames or passwords that fail to comply with the formal UTF-8 syntax defined in RFC 3629.
When applying SASLprep, servers MUST reject UTF-8 usernames or passwords containing a UTF-8 character listed in Section 2.3 of SASLprep. USER/PASS/APOP username arguments MUST be treated as query strings; APOP password arguments MUST be treated as stored strings.
When UTF-8 mode has not been enabled, character strings outside the ASCII repertoire MUST NOT be sent to the client as-is. If a client requests a UTF-8 message without enabling UTF-8 mode, the server MUST either send a surrogate compliant message or fail with -ERR.
The LANG command takes a basic language range argument (RFC 4647). On success, the server returns +OK followed by a space, the selected language tag, another space, and a human-readable confirmation in the chosen language encoded as UTF-8. On failure, -ERR is returned and the previous language remains in effect.
The LANG POP3 extension capability (CAPA tag: LANG) adds the LANG command, valid in both AUTHORIZATION and TRANSACTION states, allowing the client to negotiate the language used in human-readable +OK and -ERR response text.
The special 'LANG *' argument requests the server's administrator-preferred language, which MAY vary by active user. When issued with no argument, the server returns a language listing: one line per supported language tag, optionally followed by a space and a human-readable UTF-8 description of that language.
The USER argument to the UTF8 capability indicates the server accepts UTF-8 usernames and passwords with the USER, PASS, and APOP commands. Clients MUST NOT use UTF-8 credentials unless the server advertised this argument.
The 'UTF8' command has no parameters and must be issued in the AUTHORIZATION state. It affects the USER, PASS, APOP, LIST, TOP, and RETR commands. Once issued, clients MUST NOT subsequently issue the STLS command.
The UTF8 POP3 extension capability (CAPA tag: UTF8) adds a new command 'UTF8' that switches the session from ASCII-only mode to UTF-8 mode, enabling UTF-8 strings in headers, bodies, usernames, and passwords. The capability may carry an optional 'USER' argument indicating the server accepts UTF-8 credentials.
The UTF8 response code is a new -ERR response code valid for LIST, TOP, and RETR commands. It indicates failure because the requested message content contains UTF-8 strings but the client has not entered UTF-8 mode. The client MAY reissue the command after issuing the UTF8 command.
This document updates the POP3 capability registry (RFC 2449) with two capabilities: 'UTF8' (with optional USER argument) and 'LANG'. It also adds the 'UTF8' response code to the POP3 response codes registry (RFC 2449).
A man-in-the-middle attacker can insert a LANG command in the command stream, rendering diagnostic responses unintelligible to the user. Clients should issue the STLS command before the LANG command to protect session integrity.
Modifications to server authentication code to support non-ASCII strings must be done carefully to avoid introducing vulnerabilities such as string parsing or matching bugs, particularly when the native databases or mailstore use a character set other than Unicode in UTF-8.
The 'LANG *' command may reveal a user's existence and preferred language to an active attacker if the active language changes in response to USER, PASS, or APOP commands before credentials are validated. Servers are strongly advised to implement a configuration option to prevent this exposure.