RFC 5255
Internet Message Access Protocol Internationalization
RFC 5255: Internet Message Access Protocol Internationalization 🦋
okay bestie, so this one is the IMAP internationalization spec 🌈 It's written by C. Newman (Sun Microsystems), A. Gulbrandsen (Oryx Mail Systems GmhH), and A. Melnikov (Isode Limited). It's a Standards Track doc, dated June 2008. There's no "Obsoletes" or "Updates" line up top, so it isn't replacing or updating anything listed there ✨
Status of This Memo 📜
this is an Internet standards track protocol for the whole Internet community, and the authors are literally asking for discussion and suggestions for improvements 🫶 for the standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). and distribution of this memo is unlimited, so go wild 🌸
Abstract 💜
IMAP version 4rev1 already has basic support for non-ASCII characters in mailbox names and search substrings. it also handles non-ASCII message headers and content encoded with MIME 📬 this spec adds a bunch of IMAP extensions that level up international support. that includes language negotiation for international error text, translations for namespace prefixes, and comparator negotiation for search, sort, and thread. it's giving global glow-up 🌍✨
Table of Contents 🗂️
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................3
3. LANGUAGE Extension ..............................................3
3.1. LANGUAGE Extension Requirements ............................4
3.2. LANGUAGE Command ...........................................4
3.3. LANGUAGE Response ..........................................6
3.4. TRANSLATION Extension to the NAMESPACE Response ............7
3.5. Formal Syntax ..............................................8
4. I18NLEVEL=1 and I18NLEVEL=2 Extensions ..........................9
4.1. Introduction and Overview ..................................9
4.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2 ....9
4.3. I18NLEVEL=1 Extension Requirements ........................10
4.4. I18NLEVEL=2 Extension Requirements ........................10
4.5. Compatibility Notes .......................................11
4.6. Comparators and Character Encodings .......................11
4.7. COMPARATOR Command ........................................13
4.8. COMPARATOR Response .......................................14
4.9. BADCOMPARATOR Response Code ...............................14
4.10. Formal Syntax ............................................14
5. Other IMAP Internationalization Issues .........................15
5.1. Unicode Userids and Passwords .............................15
5.2. UTF-8 Mailbox Names .......................................15
5.3. UTF-8 Domains, Addresses, and Mail Headers ................15
6. IANA Considerations ............................................16
7. Security Considerations ........................................16
8. Acknowledgements ...............................................16
9. Relevant Sources of Documents for Internationalized IMAP
Implementations ................................................17
10. Normative References ..........................................17
11. Informative References ........................................181. Introduction 🎀
okay so this spec defines two IMAP4rev1 [RFC3501] extensions that boost international support. they can be advertised and implemented separately, so you don't have to take both 💅
the LANGUAGE extension lets the client ask for a suitable language for protocol error messages. paired with the NAMESPACE extension [RFC2342], it also enables namespace translations 🌸
the I18NLEVEL=2 extension lets the client ask for a suitable collation. that changes how the base spec's SEARCH command behaves, and also the SORT and THREAD extensions [SORT]. it builds on the collation registry [RFC4790] 🧚 the I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use the i;unicode-casemap comparator, as defined in [UCM]. I18NLEVEL=1 is basically the simpler version of I18NLEVEL=2, with no ability to pick a different collation 🦋
2. Conventions Used in This Document 📖
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💖
the formal syntax uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation, including the core rules defined in Appendix A.
the UTF-8-related productions are defined in [RFC3629].
in examples, C: and S: mean lines sent by the client and server respectively. if one C: or S: label covers multiple lines, the line breaks between them are just for editorial clarity and aren't part of the actual protocol exchange 🫶
3. LANGUAGE Extension 🌈
IMAP lets server responses include human-readable text that usually needs to be shown to the user. but the IMAP spec [RFC3501] limits that text to US-ASCII, so older deployed IMAP implementations keep working 🙈 this section explains how an IMAP client can negotiate which language the server uses for that text.
the LANGUAGE extension only handles fixed server strings, like response text and NAMESPACE folder names. if you want localized language aliases for shared mailboxes, that's a job for a separate mechanism, like the proposed METADATA extension (see [METADATA]) 🧚
3.1. LANGUAGE Extension Requirements 📋
IMAP servers that support this extension MUST list the keyword LANGUAGE in their CAPABILITY response, as well as in the greeting CAPABILITY data.
a server that advertises this extension MUST use the language "i-default" as described in [RFC2277] as its default language, until the client negotiates another supported language. a server MUST include "i-default" as one of its supported languages. IMAP servers SHOULD NOT advertise the LANGUAGE extension if they discover that they only support "i-default" 💀
clients and servers that support this extension MUST also support the NAMESPACE extension [RFC2342] 🫶
the LANGUAGE command is valid in all states. clients SHOULD issue LANGUAGE before authentication, since some servers send valuable user information as part of authentication (e.g., "password is correct, but expired") 😭 if a security layer (such as SASL or TLS) is negotiated after that, the client MUST re-issue the LANGUAGE command. that makes sure no earlier active attack (if there was one) on LANGUAGE negotiation affects the error messages that come later. (See Section 7 for a more detailed explanation of the attack.) 👑
3.2. LANGUAGE Command 💬
Arguments: Optional language range arguments.
Response: A possible LANGUAGE response (see Section 3.3).
A possible NAMESPACE response (see Section 3.4).
Result: OK - Command completed
NO - Could not complete command
BAD - Arguments invalidthe LANGUAGE command asks the server to localize its human-readable text to a language that matches one of the language range arguments, as described in Section 2 of [RFC4647] 🌸
if the command succeeds, the server returns human-readable responses in the first supported language that was specified. those responses will be in UTF-8 [RFC3629]. the server MUST send a LANGUAGE response saying which language it's using, and the change takes effect immediately after that LANGUAGE response ✨
if the command fails, the server keeps returning human-readable responses in whatever language it was already using 🙃
the special "default" language range argument means "use whatever language the server administrator has marked as preferred." the preferred language MAY vary based on the currently active user 💅
if a language range doesn't exactly match a known language tag, but does match a language by the rules of [RFC4647], the server MUST send an untagged LANGUAGE response that says which language it selected 🎯
if there aren't any arguments, the server SHOULD send an untagged LANGUAGE response listing the languages it supports. if the server can't enumerate its supported languages, it MAY return a tagged NO response to the enumeration request. and if, after getting a LANGUAGE request, the server finds out it doesn't support any language other than i-default, it MUST return a tagged NO response to the enumeration request 💀
here's the iconic example era 🧚
< The server defaults to using English i-default responses until
the user explicitly changes the language. >
C: A001 LOGIN KAREN PASSWORD
S: A001 OK LOGIN completed
< Client requested MUL language, which no server supports. >
C: A002 LANGUAGE MUL
S: A002 NO Unsupported language MUL
< A LANGUAGE command with no arguments is a request to enumerate
the list of languages the server supports. >
C: A003 LANGUAGE
S: * LANGUAGE (EN DE IT i-default)
S: A003 OK Supported languages have been enumerated
C: B001 LANGUAGE
S: B001 NO Server is unable to enumerate supported languages
< Once the client changes the language, all responses will be in
that language starting after the LANGUAGE response. Note that
this includes the NAMESPACE response. Because RFCs are in US-
ASCII, this document uses an ASCII transcription rather than
UTF-8 text, e.g., "ue" in the word "ausgefuehrt" >
C: C001 LANGUAGE DE
S: * LANGUAGE (DE)
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: C001 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
< If a server does not support the requested primary language,
responses will continue to be returned in the current language
the server is using. >
C: D001 LANGUAGE FR
S: D001 NO Diese Sprache ist nicht unterstuetzt
C: D002 LANGUAGE DE-IT
S: * LANGUAGE (DE-IT)
S: * NAMESPACE (("" "/"))(("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: D002 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
C: D003 LANGUAGE "default"
S: * LANGUAGE (DE)
S: D003 OK Sprachwechsel durch LANGUAGE-Befehl ausgefuehrt
< Server does not speak French, but does speak English. User
speaks Canadian French and Canadian English. >
C: E001 LANGUAGE FR-CA EN-CA
S: * LANGUAGE (EN)
S: E001 OK Now speaking English3.3. LANGUAGE Response 🗣️
the LANGUAGE response shows up as a result of a LANGUAGE command. a LANGUAGE response with a list containing a single language tag means the server is now using that language 🎀 a LANGUAGE response with a list containing multiple language tags means the server is sharing the list of available languages with the client, and the active language hasn't changed 🌈
the next part is where it gets even more iconic, so stay tuned 💜🧚
3.4. TRANSLATION Extension to the NAMESPACE Response
Okay so 💖 if the server has localized versions of the namespace prefixes for the language that got selected, it SHOULD pop them into the TRANSLATION extension on the NAMESPACE response ✨
That TRANSLATION extension hands back one single string: the translated namespace prefix, encoded in modified UTF-7 [RFC3501] 🎀 When the client shows mailbox names to the user, it's the one who swaps between the real prefix and its translation. That's on the client, bestie 💅
Here's an example. The server supports the IMAP4 NAMESPACE command 🦋 Its Personal Namespace has no prefix, its Other Users' Namespace gets the prefix "Other Users", and its one and only Shared Namespace gets "Public Folders". Clients usually display these prefixes, so the server includes translations the user can actually read 🌸
C: A001 LANGUAGE DE-IT
S: * NAMESPACE (("" "/")) (("Other Users/" "/" "TRANSLATION"
("Andere Ben&APw-tzer/"))) (("Public Folders/" "/"
"TRANSLATION" ("Gemeinsame Postf&AM8-cher/")))
S: A001 OK LANGUAGE-Befehl ausgefuehrt3.5. Formal Syntax
This syntax spec borrows ABNF [RFC5234] rules from IMAP4rev1 [RFC3501], IMAP4 Namespace [RFC2342], Tags for the Identifying Languages [RFC4646], UTF-8 [RFC3629], and Collected Extensions to IMAP4 ABNF [RFC4466] 🧚 Here's the grammar, no notes:
command-any =/ language-cmd
; LANGUAGE command is valid in all states
language-cmd = "LANGUAGE" *(SP lang-range-quoted)
response-payload =/ language-data
language-data = "LANGUAGE" SP "(" lang-tag-quoted *(SP
lang-tag-quoted) ")"
namespace-trans = SP DQUOTE "TRANSLATION" DQUOTE SP "(" string ")"
; the string is encoded in Modified UTF-7.
; this is a subset of the syntax permitted by
; the Namespace-Response-Extension rule in [RFC4466]
lang-range-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the language-range rule in [RFC4647]
lang-tag-quoted = astring
; Once any literal wrapper or quoting is removed, this follows
; the Language-Tag rule in [RFC4646]
resp-text = ["[" resp-text-code "]" SP ] UTF8-TEXT-CHAR
*(UTF8-TEXT-CHAR / "[")
; After the server is changed to a language other than
; i-default, this resp-text rule replaces the resp-text
; rule from [RFC3501].
UTF8-TEXT-CHAR = %x20-5A / %x5C-7E / UTF8-2 / UTF8-3 / UTF8-4
; UTF-8 excluding 7-bit control characters and "["4. I18NLEVEL=1 and I18NLEVEL=2 Extensions ✨
4.1. Introduction and Overview
Okay, so the IMAP4rev1 [RFC3501] SEARCH command can find messages that match criteria including human-readable text 🔍 The SORT extension [SORT] lets the client ask the server to order messages based on criteria that include human-readable text too 💜 Both of these need to handle non-English search and sort, so they need internationalization help.
Section 4 defines two IMAP extensions that internationalize IMAP SEARCH, SORT, and THREAD [SORT] using the comparator framework [RFC4790] 🌈
The I18NLEVEL=1 extension updates SEARCH/SORT/THREAD to use the i;unicode-casemap comparator, as defined in [UCM]. See Sections 4.2 and 4.3 for more details 🦋
The I18NLEVEL=2 extension is a superset of I18NLEVEL=1 ✨ On top of that, it adds the ability to figure out the active comparator (more on that below) and to negotiate comparators using the COMPARATOR command. It also adds the COMPARATOR response, which tells you the active comparator and possibly other comparators that are available 💅 See Sections 4.2 and 4.4 for more details.
4.2. Requirements Common to Both I18NLEVEL=1 and I18NLEVEL=2
The "default comparator" is the comparator that SEARCH and SORT use when no negotiation has happened through the COMPARATOR command (see Section 4.7) 🎀 The "active comparator" is the comparator that gets used within a session, for example by SEARCH and SORT. The COMPARATOR command is how you change the active comparator 💖
The active comparator applies to these SEARCH keys: "BCC", "BODY", "CC", "FROM", "SUBJECT", "TEXT", "TO", and "HEADER" 🌸 If the server also advertises the "SORT" extension, the active comparator applies to these SORT keys: "CC", "FROM", "SUBJECT", and "TO" 🧚 If the server advertises THREAD=ORDEREDSUBJECT, the active comparator applies to the ORDEREDSUBJECT threading algorithm. If the server advertises THREAD=REFERENCES, the active comparator applies to the subject field comparisons that the REFERENCES threading algorithm does 🔥 Future extensions may choose to apply the active comparator to their SEARCH keys, too 👑
For SORT and THREAD, the pre-processing needed to pull the base subject text out of a Subject header happens before a comparator gets applied 🫶
A server that advertises the I18NLEVEL=1 or I18NLEVEL=2 extension MUST implement the i;unicode-casemap comparator, as defined in [UCM] 🚨 And it MUST support UTF-8 as a SEARCH charset, no exceptions 💅
4.3. I18NLEVEL=1 Extension Requirements
An IMAP server that satisfies all the requirements in Sections 4.2 and 4.6 (and doesn't support or advertise any other I18NLEVEL=<n> extension where n > 1) MUST list the keyword I18NLEVEL=1 in its CAPABILITY data once IMAP enters the authenticated state 🌈 It MAY list that keyword in other states, too ✨
4.4. I18NLEVEL=2 Extension Requirements
An IMAP server that satisfies all the requirements in Sections 4.2, 4.4, and 4.6-4.10 (and doesn't support or advertise any other I18NLEVEL=<n> extension where n > 2) MUST list the keyword I18NLEVEL=2 in its CAPABILITY data once IMAP enters the authenticated state 💖 It MAY list that keyword in other states as well 🦋
A server that advertises this extension MUST implement the i;unicode-casemap comparator, as defined in [UCM] 🎀 It MAY implement other comparators from the IANA registry established by [RFC4790] 🧚 See also Section 4.5 of this document 💜
A server that advertises this extension SHOULD use i;unicode-casemap as the default comparator 💅 (Note that i;unicode-casemap is the default comparator for I18NLEVEL=1, but not necessarily for I18NLEVEL=2 🙈) The selection of the default comparator MAY be adjustable by the server administrator, and it MAY be sensitive to the current user ✨ Once the IMAP connection enters the authenticated state, the default comparator MUST remain static for the rest of that connection 🔒
Here's a fun constraint: since SEARCH uses the substring operation, IMAP servers can only implement collations that offer the substring operation (see [RFC4790], Section 4.2.2) 🌸 And since SORT uses the ordering operation (which in turn uses the equality operation), IMAP servers that advertise the SORT extension can only implement collations that offer all three operations (see [RFC4790], Sections 4.2.2-4.2.4) 🧠
If the active collation doesn't provide the operations an IMAP command needs, the server MUST respond with a tagged BAD 🚫
4.5. Compatibility Notes
Several server implementations deployed before this spec was published comply with I18NLEVEL=1 (see Section 4.3), but they don't advertise that 🙈 Other legacy servers use the i;ascii-casemap comparator (see [RFC4790]) 🕰️
There's no good way for a client to know which comparator a legacy server uses 😭 If the client has to assume the worst, it may end up doing expensive local operations to get i;unicode-casemap comparisons, even though the server actually implements it 💀
Legacy server implementations that comply with I18NLEVEL=1 should be updated to advertise I18NLEVEL=1 🫶 And all server implementations should eventually be updated to comply with the I18NLEVEL=2 extension 👑
4.6. Comparators and Character Encodings ✨
okay so this is where things get really spicy 🌶️ because we're talking about how a server actually compares and sorts text when the characters aren't just plain ASCII. RFC 3501 has its own rule for this, and I need you to see it first 👀
RFC 3501, Section 6.4.4, says:
In all search keys that use strings, a message matches the key
if the string is a substring of the field. The matching is
case-insensitive.BUT when you run SEARCH, the active comparator replaces that case-insensitive matching 💅 bestie, that's the whole plot twist.
An IMAP server that does collation (that's sorting and comparing, for SEARCH, SORT, and THREAD) follows this procedure, step by step 🧚
(a) MIME encoding has to be removed from the texts being collated, so the server MUST remove it. (See [RFC2047] for headers and [RFC2045] for body parts.)
If MIME encoding removal fails for a message, like when a body part uses an unsupported Content-Transfer-Encoding or uses characters that the Content-Transfer-Encoding doesn't allow, then the collation of that message is undefined by this specification 🙈 It gets handled in an implementation-dependent way.
(b) The decoded text from step (a) MUST be converted to the charset the active comparator expects. Period 💖
(c) For the substring operation, there are two outcomes 🦋
If step (b) fails (say the text is in a charset the server doesn't know, or it has a sequence that isn't valid in that charset), the original decoded text from step (a), the one from before the charset conversion attempt, gets collated using the i;octet comparator (see [RFC4790]).
If step (b) works, the converted text from step (b) gets collated by the active comparator.
For the ordering operation, it gets a little more dramatic 🎀 All the strings that step (b) successfully converted get split off from the ones that failed. Each group gets collated on its own. Then the strings that converted successfully get validated by the active comparator, and the ones that pass validation get collated with the active comparator. Anything that fails step (b) OR fails the active collation's validity check gets collated (after step (a)) with the i;octet comparator (see [RFC4790]). The final sorted list is built by tacking all of those "failed" strings onto the very end, after everything the active comparator sorted 🌈
Here's the example they gave, using the i;unicode-casemap [UCM] comparator. The strings are written in the hexadecimal notation ABNF uses ([RFC5234]) 🍓
(1) %xD0 %xC0 %xD0 %xBD %xD0 %xB4 %xD1 %x80 %xD0 %xB5
%xD0 %xB9 (labeled with charset=UTF-8)
(2) %xD1 %x81 %xD0 %x95 %xD0 %xA0 %xD0 %x93 %xD0 %x95
%xD0 %x99 (labeled with charset=UTF-8)
(3) %xD0 %x92 %xD0 %xB0 %xD1 %x81 %xD0 %xB8 %xD0 %xBB
%xD0 %xB8 %xFF %xB9 (labeled with charset=UTF-8)
(4) %xE1 %xCC %xC5 %xCB %xD3 %xC5 %xCA (labeled with
charset=KOI8-R)So step (b) converts string (4) into these UTF-8 octets:
%xD0 %x90 %xD0 %xBB %xD0 %xB5 %xD0 %xBA %xD1 %x81 %xD0
%xB5 %xD0 %xB9and it REJECTS strings (1) and (3), since they have octets that aren't allowed in charset=UTF-8 🙅♀️
After that, using the i;unicode-casemap collation, string (4) sorts before string (2). Using i;octet on the original strings, string (3) sorts before string (1). So the final ordering is: (4) (2) (3) (1) 👑
If the substring operation (like IMAP SEARCH) of the active comparator returns the "undefined" result (see Section 4.2.3 of [RFC4790]) for either the text in the SEARCH command or the message text, then the operation gets repeated on the result of step (a), using the i;octet comparator 🫶
Last thing for this section: the ordering operation (like IMAP SORT and THREAD) SHOULD collate the following together: strings encoded with unknown or invalid character encodings, strings in unrecognized charsets, and invalid input (as defined by the active collation) 💜
4.7. COMPARATOR Command ✨
Here's the command's template, in all its glory 💅
Arguments: Optional comparator order arguments.
Response: A possible COMPARATOR response (see Section 4.8).
Result: OK - Command completed
NO - No matching comparator found
BAD - Arguments invalidThe COMPARATOR command is valid in the authenticated and selected states 🌸
It's how you check or change the active comparator. If you send it with no arguments, the server replies with a COMPARATOR response showing whichever comparator is active right now 🔍
If you send one or more comparator arguments, it changes the active comparator to match. (If more than one installed comparator matches a single argument, the first argument wins 🥇) The COMPARATOR response lists every matching comparator if more than one of them matches the patterns you gave.
The argument "default" means the server's default comparator. Any other argument is a collation specification, as defined in the Internet Application Protocol Comparator Registry [RFC4790] 🦋
Here's an example. The client asks for a Czech comparator if one is available, or else a generic international comparator that the client thinks works for Czech. The server picks the first one it supports.
C: A001 COMPARATOR "cz;*" i;basic
S: * COMPARATOR i;basic
S: A001 OK Will use i;basic for collation4.8. COMPARATOR Response ✨
Contents: The active comparator. An optional list of available
matching comparatorsThe COMPARATOR response shows up as the result of a COMPARATOR command 🎀 Its first argument is the name of the active comparator. The second argument is a list of comparators that matched any of the arguments to the COMPARATOR command, and it only shows up when more than one match was found.
4.9. BADCOMPARATOR Response Code ✨
This response code SHOULD be returned when the server fails an IMAP command (replying NO) AND the server knows that none of the specified comparators match the requested comparator(s) 🙈
4.10. Formal Syntax ✨
The following syntax spec inherits ABNF [RFC5234] rules from IMAP4rev1 [RFC3501] and from the Internet Application Protocol Comparator Registry [RFC4790] 🧚
command-auth =/ comparator-cmd
resp-text-code =/ "BADCOMPARATOR"
comparator-cmd = "COMPARATOR" *(SP comp-order-quoted)
response-payload =/ comparator-data
comparator-data = "COMPARATOR" SP comp-sel-quoted [SP "("
comp-id-quoted *(SP comp-id-quoted) ")"]
comp-id-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the collation-id rule from [RFC4790]
comp-order-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the collation-order rule from [RFC4790]
comp-sel-quoted = astring
; Once any literal wrapper or quoting is removed, this
; follows the collation-selected rule from [RFC4790]5. Other IMAP Internationalization Issues ✨
This section gives a quick tour of other IMAP internationalization issues 🗺️ None of them get resolved by this specification. They could be sorted out by other standards work, like what the EAI working group is doing (see [IMAP-EAI]) 💖
5.1. Unicode Userids and Passwords ✨
IMAP4rev1 currently limits the userid and password fields of the LOGIN command to US-ASCII 🔒 Those fields stay US-ASCII only until a future standards track RFC says otherwise. Servers are encouraged to check that both fields follow the formal syntax of UTF-8, and to reject the LOGIN command if that syntax is broken. Servers MAY reject the LOGIN command if either the "userid" or "password" field contains an octet with the highest bit set 🫣
When AUTHENTICATE is used, some servers may support Unicode userids and passwords [RFC3490], since SASL (see [RFC4422]) allows it. BUT those userids can't be used as part of email addresses 💀
5.2. UTF-8 Mailbox Names ✨
The modified UTF-7 mailbox naming convention from Section 5.1.3 of RFC 3501 is best seen as a transition away from the status quo 🦋 Back in 1996, when modified UTF-7 was first specified, there was lots of unofficial use of local character sets like ISO-8859-1 and Shift-JIS for non-ASCII mailbox names, and that led to non-interoperability 😭
The requirements in Section 5.1 of RFC 3501 are super important if we're ever going to deploy UTF-8 mailbox names 🌈 Servers are encouraged to enforce them.
5.3. UTF-8 Domains, Addresses, and Mail Headers ✨
There's an IETF standard for "Internationalizing Domain Names in Applications (IDNA)" [RFC3490] 🌸 IMAP clients are free to support it. An argument can be made that it would help simple clients if the IMAP server did this conversion instead (the same argument would apply to MIME header encoding [RFC2047]). BUT it would be unwise to move forward with that work until the work in progress to define the format of international email addresses is finished 🧐
6. IANA Considerations ✨
IANA added LANGUAGE, I18NLEVEL=1, and I18NLEVEL=2 to the IMAP4 Capabilities Registry 📋✨
7. Security Considerations ✨
⚠️ Serious security stuff ahead, bestie. Read this part carefully!
The LANGUAGE extension makes a new command available in the "Not Authenticated" state in IMAP 😱 Some IMAP implementations run with root privilege while the server is in "Not Authenticated" state, and they don't give up that privilege until after authentication is complete. Those implementations are especially vulnerable to buffer overflow security errors at this stage, so they need to parse this command with extra care 🔥
A LANGUAGE command sent before a security layer is active can be hit by an active attack that suppresses or modifies the negotiation. That makes STARTTLS or authentication error messages harder to interpret 💀 This isn't a brand-new attack, since the error messages themselves are already subject to active attack. Clients MUST re-issue the LANGUAGE command once a security layer is active, so that this attack can't affect the protocol operations that come after it 🛡️
The LANGUAGE, I18NLEVEL=1, and I18NLEVEL=2 extensions use the UTF-8 charset, so the security considerations for UTF-8 [RFC3629] are relevant 👀 But neither one uses UTF-8 for identifiers, so the most serious concerns don't apply 🫶
8. Acknowledgements ✨
The LANGUAGE extension is based on a previous document by Mike Gahrns, and a big chunk of the text in that section was written by him 💖 Lots of people have joined discussions about an IMAP Language extension across the various IETF and Internet working group fora, so any list of contributors is bound to be incomplete 🌷 The authors would still like to thank Andrew McCown for early work on the original proposal, John Myers for suggestions about the namespace issue, and Jutta Degener, Mark Crispin, Mark Pustilnik, Larry Osterman, Cyrus Daboo, Martin Duerst, Timo Sirainen, Ben Campbell, and Magnus Nystrom for their many suggestions that made it into this document 🎀
Initial discussion of the I18NLEVEL=2 extension involved input from Mark Crispin and other participants of the IMAP Extensions WG 🧚
9. Relevant Sources of Documents for Internationalized IMAP Implementations ✨
okay bestie, this section is a non-normative reading list 📚 for anyone building i18n-aware IMAP software. Here's what to check out:
- The LANGUAGE and
I18NLEVEL=2extensions to IMAP (this specification). - The 8-bit rules for mailbox naming in Section 5.1 of RFC 3501.
- The Mailbox International Naming Convention in Section 5.1.3 of RFC 3501.
- MIME [RFC2045] for message bodies.
- MIME header encoding [RFC2047] for message headers.
- The IETF EAI working group.
- MIME Parameter Value and Encoded Word Extensions [RFC2231] for filenames. Quality IMAP server implementations will automatically combine multipart parameters when generating the
BODYSTRUCTURE. There is also some deployed non-standard use of MIME header encoding inside double quotes for filenames. 🎀 - IDNA [RFC3490] and punycode [RFC3492] for domain names (currently only relevant to IMAP clients).
- The UTF-8 charset [RFC3629].
- The IETF policy on Character Sets and Languages [RFC2277].
10. Normative References 📖
These are the docs the spec leans on hardest, so no skipping!
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
- [RFC2342] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, May 1998.
- [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
- [RFC4422] Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
- [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
- [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
- [RFC4647] Phillips, A. and M. Davis, "Matching of Language Tags", BCP 47, RFC 4647, September 2006.
- [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, March 2007.
- [SORT] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
- [UCM] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, October 2007.
- [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
- [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
11. Informative References 🌸
These are the extra-helpful reads, not required to get the spec right.
- [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
- [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
- [RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)", RFC 3492, March 2003.
- [METADATA] Daboo, C., "IMAP METADATA Extension", Work in Progress, April 2008.
- [IMAP-EAI] Resnick, P., and C. Newman, "IMAP Support for UTF-8", Work in Progress, November 2007.
Authors' Addresses 🫶
Meet the authors! 💜
Chris Newman
Sun Microsystems
3401 Centrelake Dr., Suite 410
Ontario, CA 91761
US
EMail: chris.newman@sun.comArnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
EMail: arnt@oryx.com
Fax: +49 89 4502 9758Alexey Melnikov
Isode Limited
5 Castle Business Village, 36 Station Road,
Hampton, Middlesex, TW12 2BX, UK
EMail: Alexey.Melnikov@isode.comFull Copyright Statement 📜
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
The legal bit, word for word:
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔥
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5255 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms