mailing list archives

Thanks for all the replies.

The reason I asked is that the client software is having problems with
partial fetch.  It hangs when it tries to get an attachment that's
bigger than the chunk size.

The imap server I am connecting to is giving me:

When I send:
A22 FETCH 15 (BODY[1]<245760.16384>)

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}.

I turned off the partial fetch property when I connected to the same
IMAP server, and I could get the attachment successfully.  It appears to
me that the partial fetch implement has a bug on the server side. 

-----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:13 AM
To: Otto Leung
Cc: imap-protocol@u.washington.edu
Subject: Re: [Imap-protocol] partial fetch

On Tue, 27 Sep 2005, Otto Leung wrote:
> Why is Partial Fetch important to be implemented on the server side?

It is documented as mandatory-to-implement in the specification. 
Consequently, there are clients which depend upon it being implemented, 
and these clients will not function if it is not implemented.

An IMAP server implementation MUST implement all mandatory-to-implement 
facilities in the base specification.  Unless something is explicitly 
documented as optional (or "MAY") in the base specification, then it is 
mandatory-to-implement.

In general, the only optional facilities in the IMAP base specification 
are the ability to reference non-INBOX mailboxes (the server can reply
NO 
to some other mailbox name) and the ability to SEARCH character sets
other 
than US-ASCII and UTF-8.

-- Mark --

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

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.

On Tue, 27 Sep 2005, Otto Leung wrote:
: 
: The reason I asked is that the client software is having problems with
: partial fetch.  It hangs when it tries to get an attachment that's
: bigger than the chunk size.

I have seen something very similar to this when the attachment has been
corrupted on disk by a crash. (Or anything else that would cause
corruption.) If the attachment contains a null byte, 8 zero bits, this can
mess up the octet count between client and server. Since null bytes are
never supposed to be written to an IMAP store, some IMAP programs assume
they will never get a null byte from a disk read and if they do they will
transmit the null byte over the wire, which is a BIG no-no.

So, are your attachments corrupt or do they contain null bytes?

-- 
I am disrespectful to dirt!