wasm-demo/demo/ermis-f/imap-protocol/cur/1600095173.23059.mbox:2,S

55 lines
1.8 KiB
Plaintext

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.