mailing list archives

I think I may be dealing with a buggy server but I wanted to verify my assumptions first.

upon making this request to a particular server, I'm seeing this kind of response:

C: 3 fetch 1 body.peek[header]
S: * 1 FETCH (BODY[HEADER] {2006}
S: <data>
S: <data>
S: 
S: 
S: )
S: 3 OK FETCH complete

this seems like one newline too many in the response, but I can't find anything specific that dictates how many newlines are acceptable at the end of a BODY[HEADER] request.

when doing the same request against a Dovecot server I see only one trailing newline pair:

C: 3 fetch 1 body.peek[header]
S: * 1 FETCH (BODY[HEADER] {2004}
S: <data>
S: <data>
S: 
S: )
S: 3 OK FETCH complete


but is that just convention or is this server breaking some part of the spec? if so, which part?


Ashley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4798 bytes
Desc: not available
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120418/a4972057/attachment.p7s>

On 19.4.2012, at 3.32, Ashley Clark wrote:

> I think I may be dealing with a buggy server but I wanted to verify my assumptions first.

Yes, I'd say so.

> upon making this request to a particular server, I'm seeing this kind of response:
> 
> C: 3 fetch 1 body.peek[header]
> S: * 1 FETCH (BODY[HEADER] {2006}
> S: <data>
> S: <data>
> S: 
> S: 
> S: )
> S: 3 OK FETCH complete
> 
> this seems like one newline too many in the response, but I can't find anything specific that dictates how many newlines are acceptable at the end of a BODY[HEADER] request.

BODY[HEADER] sends the message header. The RFC 822 header ends with an empty line. The next newline belongs to message body, so it can't be part of the header.

On Apr 20, 2012, at 1:12 PM, Timo Sirainen wrote:

> On 19.4.2012, at 3.32, Ashley Clark wrote:
> 
>> I think I may be dealing with a buggy server but I wanted to verify my assumptions first.
> 
> Yes, I'd say so.
> 
>> upon making this request to a particular server, I'm seeing this kind of response:
>> 
>> C: 3 fetch 1 body.peek[header]
>> S: * 1 FETCH (BODY[HEADER] {2006}
>> S: <data>
>> S: <data>
>> S: 
>> S: 
>> S: )
>> S: 3 OK FETCH complete
>> 
>> this seems like one newline too many in the response, but I can't find anything specific that dictates how many newlines are acceptable at the end of a BODY[HEADER] request.
> 
> BODY[HEADER] sends the message header. The RFC 822 header ends with an empty line. The next newline belongs to message body, so it can't be part of the header.



That's the same conclusion I came to, but I wanted to make sure I wasn't overlooking some detail in the specs elsewhere.


Thanks.
Ashley