As Opera Software's lead QA for Opera Mail, I get a lot of opportunities to analyze the communication between IMAP clients and servers. Gmail is by far the quirkiest and most troublesome IMAP implementation I've seen to date. Gmail's own documentation describes how clients must work around the deficiencies built into their implementation. I understand that Gmail's IMAP implementation is still in beta (a Google norm), but some of the basic design choices are at the heart of the problem, which leads me to believe they won't be changing. These decisions are anti-IMAP (even the IMAP spec. author finds Gmail's IMAP disappointing) and cause Opera users headaches. Here are some of the specific problems:
- Gmail's labeling system could integrate marvelously with IMAP clients if only it used IMAP keywords. Instead, IMAP mailboxes are used to represent labels. All messages (sent and received) are always available in the "Gmail/[All Mail]" mailbox, so any time a message is labeled, a duplicate message is added to the label's IMAP mailbox. IMAP clients then receive several copies of the same message, none of which integrate with the client-side labeling system. If Gmail had instead used IMAP keywords, only one message would be needed and integration would be seamless.
- Gmail doesn't allow users to change mailbox subscriptions. Unsubscribing from label mailboxes is a sensible work-around for the above design deficiency, but it's inexplicably not allowed.
- Gmail doesn't handle standard IMAP flags, such as "\Deleted", "\Answered", and "\Recent". For instance, instead of intelligent handling of "\Deleted" flags in the web interface, users are required to use a variety of work-arounds to mimic the functionality already built into the IMAP protocol.
In addition to the unfortunate design decisions listed above, Gmail's IMAP implementation has a number of bugs:
- Gmail encodes message headers containing Slavic characters (at least) incorrectly when clients download only message headers. Headers are encoded correctly if a client downloads message bodies and headers together.
- Gmail sometimes sends malformed BODYSTRUCTURE responses (often used to determine the number and size of attachments to a message before it's downloaded).
To their credit, Gmail has already fixed another bug (in the STATUS command response) we reported to them. I hope they rethink their design decisions and fix the remaining bugs soon, enabling a seamless web interface and IMAP client experience. Otherwise, the burden falls on IMAP clients to implement hackish work-arounds for Gmail, rather than relying on open standards.
Special thanks to Arjan van Leeuwen for investigating many of these issues.
