In May 2010, some confusion arose on the getmail mailing list around a bug report to Debian that complained getmail4 wouldn’t allow non-ASCII characters in an IMAP folder name Debian Bug#513116, and the interpretation of support of international mailbox names vs. RFC-3501. It seemed at first glance that IMAP4rev1 were limited to the Basic Multilingual Plane of 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:
5.1. Mailbox Naming
Mailbox names are 7-bit. Client implementations MUST NOT attempt to create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox names returned by LIST or LSUB as UTF-8. Server implementations SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for more information on how to represent non-ASCII mailbox names. […]
5.1.3. Mailbox International Naming Convention
By convention, international mailbox names in IMAP4rev1 are specified using a modified version of the UTF-7 encoding described in [UTF-7]. Modified UTF-7 may also be usable in servers that implement an earlier version of this protocol. […]
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]
Ignore it; just forbid 8-bit octets in the CREATE command.
Convert mailbox names in commands from MUTF-7 to UTF-8. When doing a LIST or LSUB, convert mailbox names from UTF-8 to MUTF-7 before sending them to the client.
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
Ignore it; you’re an ASCII client.
Convert mailbox names from UTF-8 to MUTF-7 when sending a command. When receiving a listing of mailboxes, convert MUTF-7 to UTF-8.
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.
Incomplete specification:This section and its subsections are not normative references, and are insufficient to implement UCS-2, UTF-16 or UTF-7 based software.
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 (210) 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 "&-".
IMAP Clients that want to support international mailbox names should send UTF-7, and be prepared to handle UTF-7 (if no 8-bit data is found) and UTF-8 (if 8-bit data is found).
Modified UTF-7 as per the IMAP RFC #3501 is not limited to the Unicode Basic Multilingual Plane, but maps the entire Unicode range.