MBOX-Line: From oleung at traversenetworks.com  Tue Sep 27 12:25:51 2005
To: imap-protocol@u.washington.edu
From: Otto Leung <oleung@traversenetworks.com>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] partial fetch
Message-ID: <3D9D02497026344DB100E7D18A6C06E3B5E20F@nbexch01.neubond.com>

The imap server in question is 207.106.47.239:143, and I've just
notified the vendor.

-----Original Message-----
From: mrc@ndcms.cac.washington.edu [mailto:mrc@ndcms.cac.washington.edu]
On Behalf Of Mark Crispin
Sent: Tuesday, September 27, 2005 10:54 AM
To: Otto Leung
Cc: imap-protocol@u.washington.edu
Subject: RE: [Imap-protocol] partial fetch

On Tue, 27 Sep 2005, Otto Leung wrote:
> I am getting:
> * 15 FETCH (BODY[1]<245760> {16384}
> [some binary data...]
> A22 OK FETCH completed
> The reason it hangs seems to be the IMAP server did not send 16384
bytes
> as it specified {16834}.

If your report is correct, that is absolutely, indisputably,
unambiguously 
a bug in that IMAP server.

Please identify the IMAP server in question.  This is important for two 
reasons:

First, the community needs to know about buggy IMAP servers; and the 
vendors of such servers need to know that the buggy nature of their
server 
is known to the community.  Unfortunately, a few vendors have been known

to disregard (and never fix) bugs in their software in the absence of 
community pressure.

Second, if the IMAP server in question is known to be non-buggy, then 
there must be some bug in your client and you need to know this.  The 
diagnosis of "server bug" can not be considered complete without 
verification that your report (and thus your client) is correct.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.


