MBOX-Line: From aclark at ghoti.org  Fri Apr 20 13:46:17 2012
To: imap-protocol@u.washington.edu
From: Ashley Clark <aclark@ghoti.org>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] BODY.PEEK[HEADER] response
In-Reply-To: <264FEBCB-168D-4E62-83C2-FF017E51906D@iki.fi>
References: <0F7D3273-B2F6-4EC8-BAE5-F08B39A94CBB@ghoti.org>
	<264FEBCB-168D-4E62-83C2-FF017E51906D@iki.fi>
Message-ID: <07E57B47-FD3F-4904-8FCE-73F5DA4702CB@ghoti.org>

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


