41 lines
1.6 KiB
Plaintext
41 lines
1.6 KiB
Plaintext
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.
|
|
|