I've been working on some email stuff and I think probably four things are vexing about IMAP: - The …

> I think this all means probably every non-web email client treats IMAP like POP and keeps its own store. I haven't done a survey or anything, but I'd be surprised if that weren't true. Pretty sure mutt doesn't. It only caches the headers.

I've found the server-side search functionality works very well, if you have good server implementation. Dovecot's, for example. And as for treating IMAP like POP, yes, there are clients that only pay lip service to "having IMAP support", only so that they can have one more green checkbox in feature list that their present in their marketing. But there are also more serious clients.

> - There's functionality that you basically shouldn't use; the big one is search. Even the specs more or less say "good luck using this". Message sequence numbers. Every folder in IMAP has its emails numbered from 1-N, with no holes, so if you delete a message, everything after it has its message sequence number decremented to close the hole. Except IMAP is multiclient, and the message can be deleted by other connections than the one you're currently on. But the server is only allowed to tell you about message deletions at certain points, so now the server has to keep essentially per-client message sequence number state and carefully make sure that everyone is kept in sync... and it's a recipe for disasters in practice. Any sane client will instead use UIDs for everything (and any sane server will implement all the UID extensions to let UIDs be used for everything). The other fun corner…

> You can send lots of requests to a server and you have to tag them so you can match them up with responses later Yes, you can match the final OK/NO/BAD responses with the original command based on the tag. The annoying thing is that each command typically sends most of its data in "untagged responses". And IMAP servers can send unsolicited untagged responses at any time too. It's quite tricky to handle all those responses correctly in email clients. Indeed, normally you just want to send a command, and get all the data for that command back until the finishing response. IMAP clients typically open multiple connections to isolate commands.

You can group all this under the a heading of "we thought people would use this over telnet" No, the grammar is too convoluted for that. It's more like "we thought text-based protocols are better". POP3 and SMTP are relatively easy to use manually. IMAP is not.