120 lines
4.1 KiB
Plaintext
120 lines
4.1 KiB
Plaintext
MBOX-Line: From gullo at m4ss.net Wed Jul 30 09:33:42 2014
|
|
To: imap-protocol@u.washington.edu
|
|
From: Davide Gullo <gullo@m4ss.net>
|
|
Date: Fri Jun 8 12:34:53 2018
|
|
Subject: [Imap-protocol] Gmail size fail
|
|
In-Reply-To: <42e6254c-76ec-4d2e-8f95-5dc407db8eea@flaska.net>
|
|
References: <CANVPb6vp-KDjeUQBkgz9d74p-2aEg3Pvam+vZqrx_o1HhS2dWw@mail.gmail.com>
|
|
<CABa8R6uQw+NafV=KtZFW3X3g_cJfpPb0zNp2y4B4cAYZfXJXjQ@mail.gmail.com>
|
|
<CANVPb6tjjRyxKK+7NDpFqeqSwN68OxLAie=WOPoFZyTs1WcEWQ@mail.gmail.com>
|
|
<20140729163645.Horde.h5gjOOLwGbpVI_dHXPMKnQ6@bigworm.curecanti.org>
|
|
<EBBF558390C949C08A544E0D7555F7B1@gmail.com>
|
|
<CANVPb6vn6nL_4jmafo3OFjKY3ev+f1z3rB40RiHK_OXs7f2oiA@mail.gmail.com>
|
|
<42e6254c-76ec-4d2e-8f95-5dc407db8eea@flaska.net>
|
|
Message-ID: <CANVPb6ta9pVnE6g8f9CDTDDLV+56ByerB9d--+J5AObBRbOpUA@mail.gmail.com>
|
|
|
|
Ok Jan, I understand what you mean but the problem comes from the missed
|
|
RFC822.
|
|
The server does not send it, why?
|
|
|
|
|
|
2014-07-30 15:50 GMT+02:00 Jan Kundr?t <jkt@flaska.net>:
|
|
|
|
> On Wednesday, 30 July 2014 15:20:06 CEST, Davide Gullo wrote:
|
|
>
|
|
>> 29.07.14 17:07 >>> >>>>>>> send >>>>>>
|
|
>> 29.07.14 17:07 >>> 5 UID FETCH 7848:7853 (UID X-GM-MSGID FLAGS RFC822.SIZE
|
|
>> ENVELOPE BODY.PEEK[HEADER.FIELDS (References)] BODYSTRUCTURE RFC822)
|
|
>> 29.07.14 17:07 >>> >>>>>>> end send >>>>>>
|
|
>> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
|
|
>> 29.07.14 17:07 <<< * 1 FETCH (X-GM-MSGID 1345148067064026772 UID 7848
|
|
>> RFC822.SIZE 1372 BODY[HEADER.FIELDS (References)] {2}
|
|
>> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<
|
|
>> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
|
|
>> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<
|
|
>> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
|
|
>>
|
|
>
|
|
> I don't see any problem in this log. Chances are that your client's IMAP
|
|
> parser does not properly support literals. Please note that the server says
|
|
> that the "BODY[HEADER.FIELDS (References)]" item which you are fetching
|
|
> contains exactly two bytes, the CR followed by LF. In C-syntax, that would
|
|
> be "\r\n".
|
|
>
|
|
> So this is how the data sent by the server look like on the wire (again,
|
|
> using the C-style escaping of non-printable character):
|
|
>
|
|
> BODY[HEADER.FIELDS (References)] {2}\r\n\r\n)\r\n
|
|
>
|
|
> Let's break it down:
|
|
>
|
|
> 1) "BODY[HEADER.FIELDS (References)]" -- that's an identification what
|
|
> you're about to read.
|
|
>
|
|
> 2) SP (a space, " ") -- delimiter, as defined by the FETCH response format
|
|
>
|
|
> 3) "{2}\r\n" -- this means that a LITERAL follows. The overal size of the
|
|
> literal is two bytes. You *must* stop reading in a line-oriented manner
|
|
> right now, and switch to reading the exact number of bytes which the server
|
|
> tells you -- two bytes in this case.
|
|
>
|
|
> 4) "\r\n", i.e. CR LF -- actual header data. The header is missing, so the
|
|
> server sends just the CR LF which is the separator between the header and
|
|
> the body of a MIME message.
|
|
>
|
|
> 5) ")" -- consitutes the end of the FETCH response data
|
|
>
|
|
> 6) CR LF -- end of the line, end of the response
|
|
>
|
|
> Let's see it in action:
|
|
>
|
|
>
|
|
> BODY[HEADER.FIELDS (References)] {2}
|
|
>> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<
|
|
>>
|
|
>
|
|
> ...at this point you know it's a literal. You should switch from
|
|
> read-until-end-of-line mode into reading-number-of-binary-bytes mode right
|
|
> now, and read two bytes in that mode.
|
|
>
|
|
>
|
|
> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
|
|
>> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<
|
|
>>
|
|
>
|
|
> Your code silently ignores CR LF line ends. You have a bug right here.
|
|
>
|
|
> OK, you've read two bytes, you should switch to the standard mode of
|
|
> reading until EOL:
|
|
>
|
|
>
|
|
> 29.07.14 17:07 <<< <<<<<<< read <<<<<<
|
|
>> 29.07.14 17:07 <<< )
|
|
>> 29.07.14 17:07 <<< <<<<<<< end read <<<<<<
|
|
>>
|
|
>
|
|
> Right, end of response, everything is OK.
|
|
>
|
|
> Cheers,
|
|
> Jan
|
|
>
|
|
> --
|
|
> Trojit?, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
|
|
>
|
|
> _______________________________________________
|
|
> Imap-protocol mailing list
|
|
> Imap-protocol@u.washington.edu
|
|
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
|
|
>
|
|
|
|
|
|
|
|
--
|
|
Davide Gullo, Consulente Web (professionista disciplinato ai sensi della
|
|
legge 4/2013)
|
|
http://www.m4ss.net
|
|
gullo@m4ss.net
|
|
-------------- next part --------------
|
|
An HTML attachment was scrubbed...
|
|
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140730/96dab94d/attachment.html>
|