The Exchange protocol is orders of magnitude richer than IMAP, but it's not standard (which is why it's totally proprietary :)).
Well, sure. I was mostly thinking about the mail-receiving part of Exchange protocol. IMAP obviously doesn't support sending messages, calendaring and whatever. There's other protocols for those and I don't think it really gains anything to group them all in one, except to have less TCP connections and somewhat less source code.
For example, it natively supports calendaring,
CAP is hopefully soon here. Nothing prevents IMAP server from being tightly integrated with CAP server.
threading,
IMAP's THREAD extension?
asynchronous notifications,
Of what? Sieve + [ALERT]s could be a nice kludgy way to do that :) Anyway, probably more related to calendaring than emails.
multiple message stores,
IMAP's mailbox-referrals?
incremental content synchronization (at the property level),
CONDSTORE?
multiple simultaneous client access,
As does IMAP.
public and private message folder stores, etc.
As does IMAP, and NAMESPACE even says what is what.
It also supports compression of the wire format, encryption of the datastream, etc.
TLS.
It allows message submission with rich message send options (deferred send,
etc).
I don't know about these. It's not IMAP's job anyway.
It allows for message filtering, client and server side rules, etc.
What does client side rules have to do with protocol? Sieve for server side.
It allows for content indexing,
What does this have to do with protocol?
dynamic searching
There's SEARCH? (though I still wish for the non-exact text searching extension)
and sorting of the message store.
SORT extension.
It allows for notifications of new folder creation and deletion.
Ah, you got at least one :) I don't see this really bad though. They don't happen often and you can always poll with LIST once in a while.
Many of these things can be done with IMAP, but rely on extensions to both IMAP and SMTP.
Sure, but nothing prevents you from creating a fully featured IMAP server and an IMAP client which _requires_ all those extensions. If there's no extension for something, create one yourself and preferrably make it public. It's still better than creating completely proprietary protocol.
Open standards almost always are written to the lowest
common denominator. As a really simple example, how many times has MRC
mentioned that a particular feature can't be implemented because the
legacy Unix message store can't support that feature?
In base IMAP protocol yes, but there's many extensions that can't be implemented with legacy Unix message store.
As a corollary,
how many times has a client vendor wanted to implement some cool feature
but discovered that the protocol didn't allow it? Proprietary systems
don't have that problem - since it's a proprietary system, the protocol
can simply be changed (if you care about legacy clients, you need to
make sure that the change is upwards compatible, but...).
Proprietary extensions neither have this problem :)
