[Alpine-info] alpine 2.00 and Exchange 2007

[Mark Crispin]

On Wed, 3 Jun 2009, John Hodrien wrote:

> Set-ImapSettings -EnableExactRFC822Size:$true


This was supposed to have been made the default (and only) setting years 
ago.


> Otherwise, patching alpine to ignore the size is a reasonable response. 

> Alpine only checks to see that you got at least as much as the server 

> said you would rather than checking for the exact amount, and since 

> there's no checksumming etc, you're already winging it as far as being 

> sure it's saved correctly.


IMAP is stream-based, not segment based; TCP and the lower levels take 
care of reliable transmission and flow control.  The only validation check 
that is needed is that of size.

The problem is that Exchange lies about the size.  This is a big problem, 
since Alpine can split the fetch into multiple smaller requests.  Alpine 
can detect if Exchange sent a long count, but not a short count (it'll 
never try to fetch more bytes than Exchange said were there).

So, you had better set "Prevent Partial Fetching" in your configuration as 
well.  Otherwise you run the risk of losing data!


> There are other problems that *will* bite.  Exchange 2007 will return the

> content-encoding as part of the bodystructure response as NIL.


Bug in Exchange and protocol syntax error.  From RFC 3501, page 83:

body-fld-enc    = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
                   "QUOTED-PRINTABLE") DQUOTE) / string


> Thunderbird

> seems to interpret this as 7BIT,


Bug in Thunderbird.


> while alpine does not enjoy this, and as a

> result you'll be unable to read some multipart messages.  A one line patch to

> alpine fixes this by assuming 7BIT, but it's not ideal.


Basically, it implements the same bug.  Your patch is probably relatively 
harmless, but there is no guarantee that it won't cause problems in the 
future.


> multipart/signed messages result in a broken bodystructure response that 

> makes your message unreadable.  Save it to a local mailbox and read it 

> from there...


Another Exchange bug.


> If you filter on more than about 4 search terms you'll find that you get

> disconnected from Exchange.  Exchange returns BAD in response to an

> excessively nested search and disconnects clients who cause too many BAD

> responses (seemingly).


And another....


> If you have a near empty mail folder and received new mail, pine doesn't like

> the response.  Effectively you get:

>

> (starting from having one read message in your inbox):

>

> alpine:     NOOP

> exchange: RECENT 5

> exchange: EXISTS 6


Another Exchange bug and protocol error.  Messages can not be referenced 
in any way until they are defined to exist.

Once again, your patch is probably relatively harmless, but there is no 
guarantee that it won't cause problems in the future.

Exchange has a more serious bug in that some versions present EXISTS and 
EXPUNGE values out of order.  That actually causes real harm because the 
client will interpret it in the wrong way.  There's no way to patch around 
that problem; if you can't get a patch from MS to fix the problem in 
Exchange you are screwed.

You've only scratched the surface of Exchange bugs...

Microsoft follows the same strategy with IMAP that it has used with HTML, 
Kerberos, and other open-standards protocols: adopt, extend, destroy. 
They deliberately mis-implemented IMAP with the specific intent of 
breaking (non-MS) clients that use anything but the most basic aspects of 
IMAP.

MS has no intention of playing nice with non-MS software, and does so only 
when forced by governments under heavy threat of legal sanctions.  Even 
then, they try to worm out of it.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.