Post Office Protocol Version 3 (POP3) Support for UTF-8
This specification extends the Post Office Protocol version 3 (POP3) to support international strings encoded in UTF-8 in usernames, passwords, mail addresses, message headers, and protocol-level text strings.
Replaces RFC 5721: POP3 Support for UTF-8.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 9 must, 3 should, 6 may.
2.1 The "UTF8" Command
- SHOULDIn UTF-8 mode, if the character encoding format of maildrops is UTF-8 or ASCII, the messages are sent to the client as is; if the character encoding format of maildrops is a format other than UTF-8 or ASCII, the messages' encoding format SHOULD be converted to be UTF-8 before they are sent to the client.
- MUST NOTWhen UTF-8 mode has not been enabled, character strings outside the ASCII repertoire MUST NOT be sent to the client as is.
- MUSTIf a client requests a UTF-8 message when UTF-8 mode is not enabled, the server MUST either send the client a surrogate message that complies with unextended POP and Internet Mail Format without UTF-8 mode support, or fail the request with an -ERR response.
- MAYThe server MAY respond to the "UTF8" command with an -ERR response.
- SHOULDThe octet count (size) of a message reported in a response to the "LIST" command SHOULD match the actual number of octets sent in a "RETR" response (not counting byte-stuffing).
- MAYthe user may be confused by being able to access the message through some means and not others, is that a server MAY choose to reject the command to retrieve the message as discussed in Section 5.
- MUST NOTClients MUST NOT issue the "STLS" command [RFC2595] after issuing UTF8; servers MAY (but are not required to) enforce this by rejecting with an -ERR response an "STLS" command issued subsequent to a successful "UTF8" command.
2.2 USER Argument to "UTF8" Capability
- SHOULDServers that include the USER argument in the "UTF8" capability response SHOULD apply SASLprep [RFC4013] or one of its Standards Track successors to the arguments of the "USER" and "PASS" commands.
- MUSTA client or server that supports APOP and permits UTF-8 in usernames or passwords MUST apply SASLprep or one of its Standards Track successors to the username and password used to compute the APOP digest.
- MUSTWhen applying SASLprep, servers MUST reject UTF-8 usernames or passwords that contain a UTF-8 character listed in Section 2.3 of SASLprep.
- MUSTWhen applying SASLprep to the USER argument, the PASS argument, or the APOP username argument, a compliant server or client MUST treat them as a query string [RFC3454].
- MUSTWhen applying SASLprep to the APOP password argument, a compliant server or client MUST treat them as a stored string [RFC3454].
- MAYIf the server includes the USER argument in the UTF8 capability response, the client MAY use UTF-8 characters with a "USER", "PASS", or "APOP" command; the client MAY do so before issuing the "UTF8" command.
- MUST NOTClients MUST NOT use UTF-8 characters when authenticating if the server did not include the USER argument in the UTF8 capability response.
- MUSTThe server MUST reject UTF-8 usernames or passwords that fail to comply with the formal syntax in UTF-8 [RFC3629].
3.2 Discussion
- MAYThe preferred language MAY vary based on the currently active user.
4 Non-ASCII Character Maildrops
- MAYWhen the server is not in UTF-8 mode and the message requires that mode, requests to download the message MAY be rejected (as specified in the next section) or the various alternatives outlined in Section 2.1 above, including creation and delivery of surrogates for the original message, MAY be considered.
5 "UTF8" Response Code
- MAYThe client MAY reissue the command after entering UTF-8 mode.