> ...and a bias against newer, larger-scale email servers like Gmail and Exchange -- servers that, I'm sure, would happily support IMAP in a conformant way if it were at all possible for them to do so...

I do not know of anything in IMAP that would be difficult for Gmail to theoretically implement efficiently except for how EXPUNGE interacts with message sequence numbers (which actually came up on the imap-protocol mailing list a few days ago, although I had seen the problem myself with my server a few months ago; I even came up with something that might be a good solution to it for a Gmail-style infrastructure, although I haven't implemented this evil magic yet and if I do will probably not tell anyone how I did it for a while).

Can you thereby please explain what it is that is so difficult about IMAP to implement that is holding back these companies? It seems much easier to fathom that they simply don't care much, as there are very few real IMAP clients out there other than Thunderbird; Microsoft managed to get everyone to just let them implement ActiveSync into their clients (even the iPhone comes with an ActiveSync implementation by default), and Google has gone on record as saying they only care about what Thunderbird and Outlook bother doing with the protocol.

That said, though, as far as I understand (from having read all of the related discussions I could get my hands on a few months ago), the primary (and totally benign) reason that Gmail doesn't support IMAP terribly well is actually an even simpler reason than even that: it is just because they don't want to spend the resources to go back through old e-mail and fix weird mistakes and old decisions in how various e-mails were parsed (there was a good quote about this somewhere, but I'm having a difficult time finding it :(); though, these are kind of inane details that I'm not even certain you are complaining about.

As some examples, they did weird LF->CRLF conversions only some of the time that cause their "how many bytes is this part of the message" to be inaccurate and they didn't parse through RFC822 attachments and so cannot return envelope structures for them. Otherwise, they are actually pretty good: their known incompatibilities list is actually very short. The one everyone pokes them about are things involving not supporting IMAP flags, but they aren't even really incompatible with their implementation: just "strange" for people who like older clients.

Now, yes: it would be nice if they supported CONDSTORE/QRESYNC, but that would require storing more data per message, keeping an extra secondary index, and changing some of the transaction management code for how they store flags, and they don't seem prepared to do that: however, IMAP works fine without those extensions, and those extensions surround offline synchronization (something that one can appreciate Gmail not having been designed from the beginning to ever support).

Ok, and I guess also combined with some amount of "dunno" on behalf of the Gmail team. ;P

"""Yes, we have an open bug for this one, I'm not sure why there hasn't been any progress on it.""" -- Brandon Long (Gmail) http://mailman2.u.washington.edu/pipermail/imap-protocol/201...

As for pine+IDLE, while Mark often has expansive explanations for what people are trying to with IDLE and how it caused interactions and problems with other systems over the years, I think you totally mischaracterize the "why IDLE was never implemented for pine" situation... as far as I could ever tell it always, in the end, came down to a technical detail of his existing codebase and API; his server, certainly, supported it, and even worked around bugs he found quite irritating in the Outlook implementation of the feature.

"""I'll look at it, but I can't promise that I would adopt it. Nor can I promise that if I adopt it, that it wouldn't have a different interface. c-client is fundamentally synchronous in its implementation of IMAP, and
IDLE is very much asynchronous. It'll need careful consideration.""" -- http://mailman2.u.washington.edu/pipermail/imap-uw/2005-Dece...

Please give this guy the benefit of the doubt here: he's been doing this very long, and seems to actually be quite intelligent with regards to not just how these features were planned to be used but how they ended up being used in practice. The IMAP protocol isn't actually that difficult to implement: it might seem daunting if you don't know much about implementing parsers, but it took about two quick days for me to, entirely from scratch, write a parser combinator library implementation and IMAP->structure parser; everything else was just mapping inputs to outputs.

If nothing else, this seems like a mean time to be disparaging about someone over such little things. :(