[Dovecot] Possible header parsing problem

[Eric Stadtherr]

On Thu, 23 Oct 2008 19:06:19 +0300, Timo Sirainen <tss at iki.fi> wrote:
> On Wed, 2008-10-22 at 20:59 -0600, Eric Stadtherr wrote:
>>     Content-Type: multipart/alternative; boundary="=_alternative
>>       006F3A73872574E8_="
> 
> Is there one space, two spaces or a TAB at the beginning of the second
> line?
> 
>> I did a little bit of tracing through the parsing code 
>> (message-header-parser.c:message_parse_header_next()) and it appeared 
>> that the boundary in the Content-Type header was not parsed correctly, 
>> evidently because the header line was folded in the middle of the 
>> boundary string. RFC 822 appears to allow folding in a quoted string 
>> like this (§3.3 "quoted-string"), so I'm curious whether the parsing is

>> working correctly.
> 
> Fixed: http://hg.dovecot.org/dovecot-1.1/rev/25b0cf7c62d3
> 
> But I'm not sure if I should convert the following TAB to a space.
> UW-IMAP seems to do that, but RFC just says that the CRLF should be
> dropped.

I grabbed a snapshot of the CM baseline with that fix, but that message
still doesn't display correctly. I ran it through the message_parser test
case and your fix look like it resulted in correct header values and
correct body parsing, but the BODYSTRUCTURE response from the server still
only contains the first part (plus the boundary name).

Any suggestions where to look? I looked through the code that handles the
BODYSTRUCTURE fetch command and it looked like it eventually filtered down
to the same parser functions used by the test case, so I'm not sure where
else the problem could be introduced...



-- 
Eric Stadtherr
estadtherr at gmail.com