32 lines
1.1 KiB
Plaintext
32 lines
1.1 KiB
Plaintext
MBOX-Line: From tss at iki.fi Fri Apr 20 13:12:07 2012
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:48 2018
|
|
Subject: [Imap-protocol] BODY.PEEK[HEADER] response
|
|
In-Reply-To: <0F7D3273-B2F6-4EC8-BAE5-F08B39A94CBB@ghoti.org>
|
|
References: <0F7D3273-B2F6-4EC8-BAE5-F08B39A94CBB@ghoti.org>
|
|
Message-ID: <264FEBCB-168D-4E62-83C2-FF017E51906D@iki.fi>
|
|
|
|
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.
|
|
|
|
|