[Tickets #10442] Re: Mailbox listing failed: Bad IMAP request: Command Error. 10

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/10442
------------------------------------------------------------------------------
  Ticket             | 10442
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Mailbox listing failed: Bad IMAP request: Command
                     | Error. 10
  Queue              | IMP
  Version            | 5.0.9
  Type               | Bug
  State              | Not A Bug
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2011-08-24 05:42) wrote:

>> This is a bug/fault in Exchange.  Unfortunately, there is no way to
>> work around.
>
> I wonder about the second statement.  I had the user try roundcube and using
> re-sorting in that environment, and there was never a problem displaying the
> message list within roundcube.

Please don't compare us with roundcube. :)  Especially in terms of  
performance.

Here's a fun trick (haven't looked at their IMAP code in awhile,  Did  
so to answer your question below, and analysis of their IMAP logs  
alarmed me).  In IMP 5 and Roundcube, open a mailbox with 20,000  
messages.

IMP should open in less than a second. (well.. depends a bit on  
whether the IMAP server-side cache is primed, but it is approximate).
Roundcube... well, let's just say you could go a brew a cup of coffee  
before the first results came up (in my local test, it took 2 minutes  
and 24 seconds).

Roundcube can only display X number of messages in a page (in other  
words, it does not have seamless scrolling like IMP).  However, for  
some reason, it downloads ALL of this information for EVERY message in  
the mailbox:

(UID RFC822.SIZE FLAGS INTERNALDATE BODY.PEEK[HEADER.FIELDS (DATE FROM  
TO SUBJECT CONTENT-TYPE LIST-POST DISPOSITION-NOTIFICATION-TO REPLY-TO  
IN-REPLY-TO CC BCC MESSAGE-ID CONTENT-TRANSFER-ENCODING REFERENCES  
X-PRIORITY X-DRAFT-INFO MAIL-FOLLOWUP-TO MAIL-REPLY-TO RETURN-PATH)])

ACK!  Why the hell is it doing this?  Why do you need  
"Disposition-Notification-To" data when displaying mailbox information  
(A: you don't).  Why do you need to download all of this data for  
every message in the mailbox, when you are only displaying the first X  
messages (A: you don't).  Etc, etc.

There's a specific command in IMAP to provide all (or most) of the  
information needed to display a mailbox listing: ENVELOPE.  The fact  
that they are not using this at all?  That is extremely disturbing.

For the record, here is what we request from the IMAP server on a  
mailbox listing:

(ENVELOPE FLAGS RFC822.SIZE BODY.PEEK[HEADER.FIELDS (IMPORTANCE  
LIST-POST X-PRIORITY CONTENT-TYPE)])

>  Maybe roundcube have a workaround or somehow
> dodge the bug?

No.  Quite honestly, they just happen to be lucky that they are not  
triggering the bug.  They are using horribly inefficient queries that,  
for whatever reason, do not tickle the bug on the Exchange server.   
But that is neither intentional, nor desired behavior.

> We'll probably direct users to Exchange's OWA website, or remove exchange
> from our list of supported sites if there are too many problems.   
> But it would be
> great if horde/imp can handle what other email clients can somehow manage.

I would love to workaround.  Bur right now, I don't even know what the  
problem is.  You would have to investigate for me to figure out what  
precisely is triggering the bug.  Does Exchange not like IMAP commands  
that only return INTERNALDATE?  Or maybe it is only triggered if we do  
INTERNALDATE searches on a message list over 2,000 (e.g. it is not  
triggered if the queries are done are smaller subsets of the message  
list).