Re: [Imap-protocol] IMAP part numbering corner case

On Thu, 16 Aug 2012, Joshua Cranmer wrote:
> For various reasons, I've been writing my own custom MIME parser. One 
> goal I had was to be able to match IMAP's part numbering for all parts, 
> so I don't have to pass metadata around on part numbers all the time. 
> The parser I've been cribbing off of uses a rather different numbering 
> scheme (effectively, anything that can hold a subpart gets a number, so 
> the part identified as 3.1 in the example is actually part 1.3.1.1 in 
> the internal numbering scheme), so following its logic was completely 
> out of the question. On a careful reading of the spec, however, it seems 
> that a critical part of the algorithm goes completely undefined. This is 
> not noticeable except on an evil message like the following:

Hmm, can you clarify what part of this you think is undefined?  Not well 
*implemented*, sure, but let's look at this in the spec...


> ------
> Date: Fri, 01 Jan 2010 12:00 -0500
> To: [email protected]
> From: [email protected]
> Subject: download on demand problem
> MIME-Version: 1.0
> Content-Type: message/rfc822
> 
> Date: Fri, 01 Jan 2012 12:00 -0500
> To: [email protected]
> From: [email protected]
> Subject: Blast from the future
> MIME-Version:1.0
> Content-Type: text/plain
> 
> Do you know what to do when you see this message?
> -------
> 
> What should FETCH BODY[1] return for this message? BODY[1.TEXT]? BODY[1.1]?
> 
> I tested the results on 4 different IMAP servers and got 4 different answers:
> [Unknown server, ID returns NIL]
> 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 inner message
> BODY[1.TEXT]: Do you know...

This is the correct behavior.


> [GMail]:
> BODY[TEXT]: The entire inner message
> BODY[1]: NIL
...

This violates this paragraph from RFC 3501, page 55:
         Every message has at least one part number.  Non-[MIME-IMB]
         messages, and non-multipart [MIME-IMB] messages with no
         encapsulated message, only have a part 1.


> [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.


> [Outlook, I'm pretty sure, but it doesn't implement ID]:
> BODY[TEXT]: The entire inner message
> BODY[1]: The entire inner message
> BODY[1.1]: NIL

This violates this paragraph from RFC 3501, page 55:   
         A part of type MESSAGE/RFC822 also has nested part numbers,
         referring to parts of the MESSAGE part's body.

...which when combined with the first quote above, means that "1.1" should 
be a valid specifier for the inner message's content.


Philip Guenther
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol