wasm-demo/demo/ermis-f/imap-protocol/cur/1600095062.22759.mbox:2,S

44 lines
1.8 KiB
Plaintext

MBOX-Line: From blong at google.com Sat Oct 22 13:56:55 2011
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun 8 12:34:46 2018
Subject: [Imap-protocol] Apple's iCloud server non-compliant!
In-Reply-To: <20111022200153.GA3907@brong.net>
References: <alpine.OSX.2.00.1110221212460.29979@hsinghsing.panda.com>
<727DCD4D-BA76-4EBA-A582-B0A6853F07BB@iki.fi>
<20111022200153.GA3907@brong.net>
Message-ID: <CABa8R6sVubHKcdV0o_6YRSLOvgUS5MZ+rjOMGNYjNUTcR7bhYg@mail.gmail.com>
On Oct 22, 2011 1:02 PM, "Bron Gondwana" <brong@fastmail.fm> wrote:
>
> On Sat, Oct 22, 2011 at 10:39:35PM +0300, Timo Sirainen wrote:
> > Related: I added http://imapwiki.org/ServerBugs page a while ago and
there are now two servers listed there. The idea is to have a page that
lists major bugs that are unlikely to get fixed in servers (i.e. big
commercial ones that don't really care).
>
> No Gmail yet?
I think we have only one deliberate break from the spec, and that's that we
don't do substring searches.
I know there are other issues, like we sometimes don't get the size quite
right (comes of storing the message with just LF line endings and having to
convert to CRLF), but mostly we tend to bend the spec but not break them...
matching the IMAP mailbox model with the gmail one is tough.
I tried running Timo's tests against gmail, but its pretty hard to debug
failures, and the set of tests isn't quite wide or separable. Its somewhere
on the todo list to work that again.
I would say that our biggest issue with IMAP is that the amount of resources
required for some of the commands is really high, which is hard to optimize
for or to fairly share resources.
Brandon
Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20111022/54022461/attachment.html>