IMAP4r1 Mailbox Names vs. Unicode

Notably, RFC-3501 mandates that mailbox names are 7-bit, however clients are supposed to accept 8-bit data and interpret it as UTF-8. This is apparently contradictory or extraneous, because 7-bit ASCII data need not be encoded.

Let us look at the IMAP4rev1 standard:

This appears to be contradictory, because UTF-7 is not UTF-8. However, a UTF-7 mailbox name is not an 8-bit mailbox name, hence the clause "interpret any 8-bit mailbox names … as UTF-8" does not apply. Mark writes:

by Mark Crispin

8-bit octets are prohibited in mailbox names. Clients MUST use 7-bit names, and servers MUST reject CREATE commands that contain 8-bit octets.

However, clients MUST also interpret any 8-bit names in a list of mailbox names (from LIST or LSUB) as UTF-8.

To understand the history here, we must go back to the 1990s where people (in spite of being told not to do so) were writing IMAP2 clients and servers which used ISO-8859-1 and Shift-JIS mailbox names. At that time, it was by no means certain that UTF-8 would become the standard Internet character set; I played an important role in making that happen, but that was still a few years in the future.

The adoption of UTF-8 offered a chance to exterminate non-UTF-8 8-bit mailbox names, and in 1996 the current rules were adopted. The transition to IMAP4 (which required substantial changes to any IMAP2 servers) provided an opportunity to exterminate these non-interoperable names once and for all.

The modified UTF-7 was a temporary expedient to allow non-ASCII mailbox names while remaining with the 7-bit framework. Had punycode existed at the time, it would have been a much better choice than UTF-7. But punycode did not exist for several years later with IDN. In fact, punycode was created because people learned the problems of UTF-7 from IMAP.

The intent was always to move to a UTF-8 only environment and leave behind UTF-7. When that happens, clients will start encountering UTF-8 names. It is therefore necessary to tell clients that, even though they are not permitted to send them, they need to be written to handle them so they work properly when the restriction is relaxed in the future.

by Mark Crispin

Options for server implementors

From the perspective of a server implementor, you have one of two choices of how to implement MUTF-7:
[editor’s note: Modified UTF-7 as specified by the ensemble of RFC-2152 and RFC-3501]

Servers of type [S1] were far more common in the 1990s. [S2] is more common today. However, a client neither knows, nor cares, which type of server it is because the rules make both servers interoperate the same.

Options for client implementors

This all works, and works well. The routines to do the conversions are quite straightforward. The only thing that you can’t do well are mixed wildcards with strings with non-ASCII names; and that is primarily a curiousity since no clients do that with ASCII names.

by Mark Crispin

RFC-3501 uses RFC-2152 by reference. Some of the confusion on the getmail list arose from the fact that RFC-2152 talks about UCS-2 representation, which is limited to the Basic Multilingual Plane (BMP) range U+0000 to U+FFFF.

However, RFC-2152 also (page 5) refers to the handling of surrogate pairs, which are defined in UTF-16 but not UCS-2.

The correct interpretation is that the wording in RFC-2152 was written at a time when "UCS-2" was interpreted as a synonym for "16-bit value" as opposed to "BMP-only codepoints". This happens frequently in older standards. Since UTF-7 is deprecated, nobody has done the work to update RFC-2152 to clarify this point.

Using surrogate pairs extends the capability of 16-bit words beyond the BMP range.

The 0x0000 to 0xFFFF range comprises so-called surrogates, two character ranges (0xD800 to 0xDBFF and 0xDC00 to 0xDFFF) of 1024 characters (2¹⁰) each. These ranges are technically removed from the BMP (thus there is no such thing as U+D800); and hence the BMP only contains 64,512 possible codepoints.

Both UTF-7 and UTF-16 transformation leverages these ranges to map Unicode code points in the range from U+010000 to U+10FFFF (which is the highest Unicode code point) to a pair of UCS-2 characters in the surrogates ranges.

This happens by first subtracting 0x10000, which maps the input into the range 0x0 to 0xFFFFF, representable in 20 bits. The most significant 10-bit portion is mapped into the range 0xD800…0xDBFF, the least significant 10-bit portion into the range 0xDC00…0xDFFF, and these two 16-bit values are used in this order. UTF-7 does a further step of encoding in modified BASE64.

Thus, UTF-7 and UTF-16 both deal with “16-bit values” and use the same surrogate pair mechanism to access non-BMP codepoints. Although not strictly accurate (the two are technically independent encodings of Unicode), it may be helpful to think of UTF-7 as a further encoding of UTF-16.

UTF-7 is a 7-bit representation of Unicode that makes use of character set shifting. A character that is directly representable represents itself. Other characters are subjected to a modified BASE64-encoding (that omits the padding "=" characters at the end of a group) which is preceded by a "+" character and trailed by a "-" character, which is discarded, or any other character not in the modified BASE64 set, which remains in the stream.

As a special case, the sequence "+-" is a shorthand to represent the "+" character itself.

The modified BASE64 character set uses the characters A-Z, a-z, digits 0-9, and the characters "+" and "/", omitting "=" to avoid collisions with RFC-2047 encoding.

This works similar to UTF-7, but mandates that printable ASCII characters 0x20…0x7E except 0x26 (the ampersand "&") represent themselves, and uses yet another BASE64 alphabet consisting of the upper- and lowercase letters, the digits, and the characters "+" and ",", with some further rules specified in RFC-3501. The leading shift character is replaced by the ampersand "&", the trailing remains "-", and the "&" can be encoded as "&-".