MBOX-Line: From tss at iki.fi  Mon Aug 20 14:10:34 2012
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:48 2018
Subject: [Imap-protocol] IMAP part numbering corner case
In-Reply-To: <938843794.54586.1345495728390.JavaMail.root@zimbra.com>
References: <502DBEA4.2070204@verizon.net>
	<alpine.BSO.2.00.1208162109520.13998@morgaine.smi.sendmail.com>
	<938843794.54586.1345495728390.JavaMail.root@zimbra.com>
Message-ID: <3F590CAC-0A89-4B05-B24F-C5714DFADDBE@iki.fi>

On 20.8.2012, at 23.48, Dan Karp wrote:

>>> [Zimbra, specifically 7.2.0_GA_2669]:
>>> BODY[TEXT]: The entire inner message
>>> BODY[1]: The entire inner message
>>> BODY[1.1]: Do you know...
>>> BODY[1.MIME]: Headers of the outer message
>>> BODY[1.HEADER]: Headers of the outer message
>> 
>> This violates this paragraph from RFC 3501, page 55:
>>         The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
>>         specifiers refer to the [RFC-2822] header of the message or
>>         of an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
>> 
>> Since BODY[1] refers to the entire inner message, which is an
>> encapsulated MESSAGE/RFC822 message, BODY[1.HEADER] should be the
>> header of that inner message.
> 
> Thanks for noticing this.  We had a code mis-ordering in our part
> numbering handler that was triggered in exactly this case.  It
> will be fixed in the 8.0.1 release.

BTW. This and various other related tests are now tested by my imaptest tool. I wanted to add such tests a long time ago, but the parser didn't support multi-line replies and it took me a while to add such feature.. I haven't ran the tests against other servers than mine yet, except GMail (which seems to have at least a few non-good reasons for failing, and I didn't look carefully at the search* failures which are the majority of them).

It would be nice if when people noticed a bug in any IMAP server that my tests didn't catch they'd tell me about it and I could add a test case for it. It would help everyone..


