MBOX-Line: From MRC at CAC.Washington.EDU  Tue Sep 27 10:54:14 2005
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:36 2018
Subject: [Imap-protocol] partial fetch
In-Reply-To: <3D9D02497026344DB100E7D18A6C06E3B5E1F5@nbexch01.neubond.com>
References: <3D9D02497026344DB100E7D18A6C06E3B5E1F5@nbexch01.neubond.com>
Message-ID: <Pine.WNT.4.64.0509271048240.8760@Tomobiki-Cho.CAC.Washington.EDU>

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.

