Re: [imap5] Where is IMAP5 ?

["Bron Gondwana" <[e-mail]>]

On Mon, 18 Jul 2011 11:21:46 +0200, Giovanni Panozzo <[e-mail]>  
wrote:

> Hi, I just landed in this mailing list after searching news on IMAP  
> protocol.
>
> Is this ML dead ?
> Is Microsoft Active-Sync taking over IMAP ?
>
> I'm a system integrator as main job, and sometimes a developer, C, Java,  
> PHP for hobby. I manage some IMAP servers, mainly based on  
> linux+dovecot+postfix.
> But I can see that IMAP is being replaced by the simpler to configure,  
> more features rich Microsoft Active Sync.
>
> I have read the IMAP whishlist of "Philip Van Hoof", posted back in  
> 2008. It's a programmer's point of view whishlist, I like it, but I  
> would like to contribute with my end-user and system configurator point  
> of viwe. I also can contribute with debugging and testing.
>
> But I can't see any traffic in this ML since 2010 :(
>
> Is there anyone ? :)

I think it got declared "too hard" and pretty much died - nobody could
agree on the important set of things to include.  Little things like:

"If you move 10,000 messages to Archive.2011 then all other clients
  shouldn't need to download everything again"

"If you rename a folder then every other client shouldn't need to
  download everything again"

Which in my opinion are important got jumped on by Mark "you don't
understand IMAP" Crispin - who has very fixed ideas about which problems
IMAP should be solving, and the ability to cache full mailbox state
locally for offline work is not one of them!

And then there's the "don't send the whole message up the wire twice on
compose" problem, which has been solved badly in a few ways but nobody
seems to be willing to look at "extend the APPEND syntax to add: also
send via SMTP on successful append", which is bloody trivial compared to
extending the SMTP server to make an authenticated request back to the
IMAP server and fetch out the body of the message, which is so complex
that approximately nobody gets it right, and certainly nobody actually
makes it easy for a mom-and-pop toaster server to set up.

Not to mention "move messages" - the number of times people run into
"I was trying to move these big messages to an archive folder and got
told I was over quota".  That's because IMAP doesn't do that, you COPY
first and then STORE+EXPUNGE the original messages.  A move command
that did nothing more than that but skipped the quota lookup if they
were both within the quotaroot would be enough.  It still has the
rare failure mode where a server problem during the copy+delete would
leave the message in BOTH mailboxes, but that's no different than if
the client crashes or loses network part way through the process.  So
what.  At least it would give a nice user experience in the common
case, and no extra downsides.


But there doesn't appear to be any will to actually solve these problems
on this list any more, and my proposal of a standard way to fetch the
digest of a message (DIGEST=SHA1) got shot down, so I kind of gave up
and just do my own thing now... and try to get upstream Cyrus to follow
all the standards that it can at the same time.


I notice gmail do pretty much the same, they don't care too much about
standards, but have some IMAP extensions that let you see that a message
is the same original message after a rename.  Their folders are a bit
funky as well, but they do expose the stuff to allow you to use them
efficiently.  The problem is, you can fetch DIGEST.SHA1 from FastMail,
you can fetch X-GM-MSGID from Gmail, and you can't rely on ANYTHING
in the general case, because you might wind up talking to an old
Lotus Notes server, and all bets are off.

That's the biggest problem that an IMAP5 would be good at solving,
lift the baseline so that clients don't need to work around lack of
UIDPLUS, CONDSTORE, etc.  Meaning they can get consistent semantics
without having to keep fallback codepaths that guess about what happened.

Bron.