mailing list archives

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:

------
Date: Fri, 01 Jan 2010 12:00 -0500
To: x@x.x
From: y@y.y
Subject: download on demand problem
MIME-Version: 1.0
Content-Type: message/rfc822

Date: Fri, 01 Jan 2012 12:00 -0500
To: y@y.y
From: x@x.x
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...

[GMail]:
BODY[TEXT]: The entire inner message
BODY[1]: NIL
BODY[1.1]: NIL
BODY[1.MIME]: NIL
BODY[1.HEADER]: NIL
BODY[1.TEXT]: NIL

[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
BODY[1.TEXT]: The entire 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
BODY[1.MIME]: NIL
BODY[1.HEADER]: NIL
BODY[1.TEXT]: NIL

FWIW, as an aside, I'm currently putting together a testsuite of MIME 
messages in part to be able to do things like ensure correctness of 
things like IMAP servers, even in the face of horribly malformed 
messages. I'm frankly shocked by how not comprehensive the testsuites I 
can find are, which makes it hard to judge whether or not edge cases are 
viable to change or not in handling.

-- 
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth

On Thu, Aug 16, 2012 at 8:46 PM, Joshua Cranmer <Pidgeot18@verizon.net>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:
>
> ------
> Date: Fri, 01 Jan 2010 12:00 -0500
> To: x@x.x
> From: y@y.y
> Subject: download on demand problem
> MIME-Version: 1.0
> Content-Type: message/rfc822
>
> Date: Fri, 01 Jan 2012 12:00 -0500
> To: y@y.y
> From: x@x.x
> 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...
>
> [GMail]:
> BODY[TEXT]: The entire inner message
> BODY[1]: NIL
> BODY[1.1]: NIL
> BODY[1.MIME]: NIL
> BODY[1.HEADER]: NIL
> BODY[1.TEXT]: NIL
>

This looks like the known bug in the way Gmail handles message/rfc822, its
essentially not considering it a container.  See
http://www.ietf.org/mail-archive/web/imapext/current/msg04583.html for the
full break down on the state of that.

[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
> BODY[1.TEXT]: The entire 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
> BODY[1.MIME]: NIL
> BODY[1.HEADER]: NIL
> BODY[1.TEXT]: NIL
>
> FWIW, as an aside, I'm currently putting together a testsuite of MIME
> messages in part to be able to do things like ensure correctness of things
> like IMAP servers, even in the face of horribly malformed messages. I'm
> frankly shocked by how not comprehensive the testsuites I can find are,
> which makes it hard to judge whether or not edge cases are viable to change
> or not in handling.
>
> --
> Beware of bugs in the above code; I have only proved it correct, not tried
> it. -- Donald E. Knuth
>
> ______________________________**_________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.**edu/mailman/listinfo/imap-**protocol<http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20120816/f9a9e44e/attachment.html>

On 17.8.2012, at 6.46, 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:

Undefined also means that the client shouldn't attempt to fetch it.

> ------
> Date: Fri, 01 Jan 2010 12:00 -0500
> To: x@x.x
> From: y@y.y
> Subject: download on demand problem
> MIME-Version: 1.0
> Content-Type: message/rfc822
> 
> Date: Fri, 01 Jan 2012 12:00 -0500
> To: y@y.y
> From: x@x.x
> 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]?

[1.1] is invalid, because the included message isn't multipart.

> 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.HEADER]: Headers of the inner message
> BODY[1.TEXT]: Do you know...

These are correct.

> BODY[1.MIME]: Headers of the outer message
> BODY[1.1]: Do you know...

These don't matter, they could have been anything. The client shouldn't have asked them.

> FWIW, as an aside, I'm currently putting together a testsuite of MIME messages in part to be able to do things like ensure correctness of things like IMAP servers, even in the face of horribly malformed messages. I'm frankly shocked by how not comprehensive the testsuites I can find are, which makes it hard to judge whether or not edge cases are viable to change or not in handling.


I added your case to my tester: http://hg.dovecot.org/imaptest/rev/191e7c11d02e

If you want to write more of those I'd be happy to include them. A few days ago I added many other tests cases.

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: x@x.x
> From: y@y.y
> Subject: download on demand problem
> MIME-Version: 1.0
> Content-Type: message/rfc822
> 
> Date: Fri, 01 Jan 2012 12:00 -0500
> To: y@y.y
> From: x@x.x
> 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

On 17.8.2012, at 7.17, Philip Guenther wrote:

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

Is it valid? 1.1 makes sense when it's a multipart, in which case it refers to the first MIME part, but is it valid when ther's no multipart? Looks like UW-IMAP allows it, but not 1.1.1, so maybe it was meant to be valid. I could add it to my tests..

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

   https://bugzilla.zimbra.com/show_bug.cgi?id=77048

- Dan

On Fri, 17 Aug 2012, Timo Sirainen wrote:
> On 17.8.2012, at 7.17, Philip Guenther wrote:
> >> [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.
> 
> Is it valid? 1.1 makes sense when it's a multipart, in which case it 
> refers to the first MIME part, but is it valid when ther's no multipart? 
> Looks like UW-IMAP allows it, but not 1.1.1, so maybe it was meant to be 
> valid. I could add it to my tests..

Flip it around.  Given a message, if you nest it inside another message as 
a message/rfc822 part, the addressing of its parts are formed by 
concatenating the addressing of the part it is nested as and the parts 
inside it.

Given this message
-----
Date: Fri, 01 Jan 2012 12:00 -0500
To: y@y.y
From: x@x.x
Subject: Blast from the future
MIME-Version:1.0
Content-Type: text/plain

Do you know what to do when you see this message?

-----

it has a single part, which can be addressed with the specifier "1".  So, 
if you nest it

-----
Date: Fri, 01 Jan 2010 12:00 -0500
To: x@x.x
From: y@y.y
Subject: download on demand problem
MIME-Version: 1.0
Content-Type: message/rfc822

Date: Fri, 01 Jan 2012 12:00 -0500
To: y@y.y
From: x@x.x
Subject: Blast from the future
MIME-Version:1.0
Content-Type: text/plain

Do you know what to do when you see this message?

-----

The entire inner message is "1", so the text of the inner message is the 
concatenation "1.1".


Philip Guenther

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

On 17.8.2012, at 7.51, Philip Guenther wrote:

>>> 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.
>> 
>> Is it valid? 1.1 makes sense when it's a multipart, in which case it 
>> refers to the first MIME part, but is it valid when ther's no multipart? 
>> Looks like UW-IMAP allows it, but not 1.1.1, so maybe it was meant to be 
>> valid. I could add it to my tests..
> 
> Flip it around.  Given a message, if you nest it inside another message as 
> a message/rfc822 part, the addressing of its parts are formed by 
> concatenating the addressing of the part it is nested as and the parts 
> inside it.

Yes, after thinking about it for a while I agree. Added it to my tests. Anyway, [1.MIME] isn't a valid request in Joshua's test mail. I also changed Dovecot to return an empty string for it and for [1.1.1], maybe it'll help to avoid client developer confusion in future. :)

On Fri, 17 Aug 2012, Timo Sirainen wrote:
...
> Anyway, [1.MIME] isn't a valid request in Joshua's test mail. 

Chapter and verse, please?

(There are specific restrictions on when HEADER and TEXT are valid, but no 
such restrictions are specified for the MIME part specifier...)


Philip Guenther

On 17.8.2012, at 8.16, Philip Guenther wrote:

> On Fri, 17 Aug 2012, Timo Sirainen wrote:
> ...
>> Anyway, [1.MIME] isn't a valid request in Joshua's test mail. 
> 
> Chapter and verse, please?
> 
> (There are specific restrictions on when HEADER and TEXT are valid, but no 
> such restrictions are specified for the MIME part specifier...)

Well, I'm not sure if it's really a BAD-type of invalid, but [x.MIME] refers to the part's MIME headers, and if the parent isn't a multipart, there are no MIME headers, so the proper result is empty.

On Fri, 17 Aug 2012, Timo Sirainen wrote:
> On 17.8.2012, at 8.16, Philip Guenther wrote:
> > On Fri, 17 Aug 2012, Timo Sirainen wrote:
> > ...
> >> Anyway, [1.MIME] isn't a valid request in Joshua's test mail. 
> > 
> > Chapter and verse, please?
> > 
> > (There are specific restrictions on when HEADER and TEXT are valid, 
> > but no such restrictions are specified for the MIME part specifier...)
> 
> Well, I'm not sure if it's really a BAD-type of invalid, but [x.MIME] 
> refers to the part's MIME headers, and if the parent isn't a multipart, 
> there are no MIME headers, so the proper result is empty.

Well, RFC 3501 says:
         The MIME part specifier refers to the [MIME-IMB] header for
         this part.

[MIME-IMB] is a reference to RFC 2045.  That RFC doesn't define "header" 
itself, but does describe headers on not just body parts but entities:

2.4.  Entity
...
   <...>  Any sort of field may be present in the header of an entity,
   but only those fields whose names begin with "content-" actually have
   any MIME-related meaning.  Note that this does NOT imply thay they
   have no meaning at all -- an entity that is also a message has non-
   MIME header fields whose meanings are defined by RFC 822.

That implies to me that "header" doesn't necessarily mean "header on body 
part".

Also, RFC 3501 refers to [MIME-IMB] header fields in the description of 
the BODYSTRUCTURE fetch item, wherein message/rfc822 parts do have their 
header parsed to fill in the various fields.


So, I would argue that RFC 3501 does specify that .MIME work on all parts 
and, in the particular case of message/rfc822 part, is equivalent to 
asking for HEADER one level higher.


Philip Guenther


(In case that last "one level higher" doesn't make sense, here's a longer 
example:

------------------------------------------------------
Date: Fri, 01 Jan 2010 12:00 -0500
To: x@x.x
From: y@y.y
Subject: download on demand problem
MIME-Version: 1.0
Content-Type: message/rfc822

Date: Fri, 01 Jan 2012 12:00 -0500
To: y@y.y
From: x@x.x
Subject: Blast from the future
MIME-Version:1.0
Content-Type: multipart/mixed; boundary=foo

--foo

Do you know what to do when you see this message?

--foo
Content-Type: text/html

<HTML><BODY>Blah blah blah</BODY></HTML>
--foo
Content-Type: multipart/digest; boundary=bar

--bar

Subject: blah
Foo: bar

sdlfkj
sdlfkj
sdlfkj

--bar--

--foo--
------------------------------------------------------

In that, [1.3.1] is the digest message, starting at the "Subject: blah" 
line and continuing through the three "sdlfkj" lines.  [1.3.1.1] is just 
the three "sdlfkj" lines.  [1.3.1.1.MIME] is the same as [1.3.1.HEADER], 
which is the header of the digest message, being "Subject: blah", "Foo: 
bar", and the blank line after.)

I think this is somewhat ambiguous.. Servers probably should do what you suggest (I changed mine to do it it again, only a few days of not doing it), but then again clients shouldn't rely on it, since some servers are known not to allow it (UW-IMAP at least).

Somewhat related to this, I've been wondering about adding optional levels of testing to imaptest, where by default it tests only how all the servers should really behave, and with more options it could test some more strict features that maybe aren't really so relevant anymore (e.g. substring searches).

On 18.8.2012, at 3.13, Philip Guenther wrote:

> On Fri, 17 Aug 2012, Timo Sirainen wrote:
>> On 17.8.2012, at 8.16, Philip Guenther wrote:
>>> On Fri, 17 Aug 2012, Timo Sirainen wrote:
>>> ...
>>>> Anyway, [1.MIME] isn't a valid request in Joshua's test mail. 
>>> 
>>> Chapter and verse, please?
>>> 
>>> (There are specific restrictions on when HEADER and TEXT are valid, 
>>> but no such restrictions are specified for the MIME part specifier...)
>> 
>> Well, I'm not sure if it's really a BAD-type of invalid, but [x.MIME] 
>> refers to the part's MIME headers, and if the parent isn't a multipart, 
>> there are no MIME headers, so the proper result is empty.
> 
> Well, RFC 3501 says:
>         The MIME part specifier refers to the [MIME-IMB] header for
>         this part.
> 
> [MIME-IMB] is a reference to RFC 2045.  That RFC doesn't define "header" 
> itself, but does describe headers on not just body parts but entities:
> 
> 2.4.  Entity
> ...
>   <...>  Any sort of field may be present in the header of an entity,
>   but only those fields whose names begin with "content-" actually have
>   any MIME-related meaning.  Note that this does NOT imply thay they
>   have no meaning at all -- an entity that is also a message has non-
>   MIME header fields whose meanings are defined by RFC 822.
> 
> That implies to me that "header" doesn't necessarily mean "header on body 
> part".
> 
> Also, RFC 3501 refers to [MIME-IMB] header fields in the description of 
> the BODYSTRUCTURE fetch item, wherein message/rfc822 parts do have their 
> header parsed to fill in the various fields.
> 
> 
> So, I would argue that RFC 3501 does specify that .MIME work on all parts 
> and, in the particular case of message/rfc822 part, is equivalent to 
> asking for HEADER one level higher.
> 
> 
> Philip Guenther
> 
> 
> (In case that last "one level higher" doesn't make sense, here's a longer 
> example:
> 
> ------------------------------------------------------
> Date: Fri, 01 Jan 2010 12:00 -0500
> To: x@x.x
> From: y@y.y
> Subject: download on demand problem
> MIME-Version: 1.0
> Content-Type: message/rfc822
> 
> Date: Fri, 01 Jan 2012 12:00 -0500
> To: y@y.y
> From: x@x.x
> Subject: Blast from the future
> MIME-Version:1.0
> Content-Type: multipart/mixed; boundary=foo
> 
> --foo
> 
> Do you know what to do when you see this message?
> 
> --foo
> Content-Type: text/html
> 
> <HTML><BODY>Blah blah blah</BODY></HTML>
> --foo
> Content-Type: multipart/digest; boundary=bar
> 
> --bar
> 
> Subject: blah
> Foo: bar
> 
> sdlfkj
> sdlfkj
> sdlfkj
> 
> --bar--
> 
> --foo--
> ------------------------------------------------------
> 
> In that, [1.3.1] is the digest message, starting at the "Subject: blah" 
> line and continuing through the three "sdlfkj" lines.  [1.3.1.1] is just 
> the three "sdlfkj" lines.  [1.3.1.1.MIME] is the same as [1.3.1.HEADER], 
> which is the header of the digest message, being "Subject: blah", "Foo: 
> bar", and the blank line after.)
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
>

In a communication on this mailing list of 24-Jan-2011, Mark Crispin 
wrote:  "For all body parts that are not children of a MULTIPART, the 
'MIME' specifier returns the empty string (not NIL)."  At the time, I 
fixed my server to comply with this.  I think it would be no bad 
thing if "MIME" meant get the MIME headers (and only MIME headers) 
for any old part but that seems clearly not the intention (and not 
the way that most servers have it implemented) so I am inclined to 
stick with this rule.

Pete Maclean

At 05:20 PM 8/20/2012, Timo Sirainen wrote:
>I think this is somewhat ambiguous.. Servers probably should do what 
>you suggest (I changed mine to do it it again, only a few days of 
>not doing it), but then again clients shouldn't rely on it, since 
>some servers are known not to allow it (UW-IMAP at least).
>
>Somewhat related to this, I've been wondering about adding optional 
>levels of testing to imaptest, where by default it tests only how 
>all the servers should really behave, and with more options it could 
>test some more strict features that maybe aren't really so relevant 
>anymore (e.g. substring searches).
>
>On 18.8.2012, at 3.13, Philip Guenther wrote:
>
> > On Fri, 17 Aug 2012, Timo Sirainen wrote:
> >> On 17.8.2012, at 8.16, Philip Guenther wrote:
> >>> On Fri, 17 Aug 2012, Timo Sirainen wrote:
> >>> ...
> >>>> Anyway, [1.MIME] isn't a valid request in Joshua's test mail.
> >>>
> >>> Chapter and verse, please?
> >>>
> >>> (There are specific restrictions on when HEADER and TEXT are valid,
> >>> but no such restrictions are specified for the MIME part specifier...)
> >>
> >> Well, I'm not sure if it's really a BAD-type of invalid, but [x.MIME]
> >> refers to the part's MIME headers, and if the parent isn't a multipart,
> >> there are no MIME headers, so the proper result is empty.
> >
> > Well, RFC 3501 says:
> >         The MIME part specifier refers to the [MIME-IMB] header for
> >         this part.
> >
> > [MIME-IMB] is a reference to RFC 2045.  That RFC doesn't define "header"
> > itself, but does describe headers on not just body parts but entities:
> >
> > 2.4.  Entity
> > ...
> >   <...>  Any sort of field may be present in the header of an entity,
> >   but only those fields whose names begin with "content-" actually have
> >   any MIME-related meaning.  Note that this does NOT imply thay they
> >   have no meaning at all -- an entity that is also a message has non-
> >   MIME header fields whose meanings are defined by RFC 822.
> >
> > That implies to me that "header" doesn't necessarily mean "header on body
> > part".
> >
> > Also, RFC 3501 refers to [MIME-IMB] header fields in the description of
> > the BODYSTRUCTURE fetch item, wherein message/rfc822 parts do have their
> > header parsed to fill in the various fields.
> >
> >
> > So, I would argue that RFC 3501 does specify that .MIME work on all parts
> > and, in the particular case of message/rfc822 part, is equivalent to
> > asking for HEADER one level higher.
> >
> >
> > Philip Guenther
> >
> >
> > (In case that last "one level higher" doesn't make sense, here's a longer
> > example:
> >
> > ------------------------------------------------------
> > Date: Fri, 01 Jan 2010 12:00 -0500
> > To: x@x.x
> > From: y@y.y
> > Subject: download on demand problem
> > MIME-Version: 1.0
> > Content-Type: message/rfc822
> >
> > Date: Fri, 01 Jan 2012 12:00 -0500
> > To: y@y.y
> > From: x@x.x
> > Subject: Blast from the future
> > MIME-Version:1.0
> > Content-Type: multipart/mixed; boundary=foo
> >
> > --foo
> >
> > Do you know what to do when you see this message?
> >
> > --foo
> > Content-Type: text/html
> >
> > <HTML><BODY>Blah blah blah</BODY></HTML>
> > --foo
> > Content-Type: multipart/digest; boundary=bar
> >
> > --bar
> >
> > Subject: blah
> > Foo: bar
> >
> > sdlfkj
> > sdlfkj
> > sdlfkj
> >
> > --bar--
> >
> > --foo--
> > ------------------------------------------------------
> >
> > In that, [1.3.1] is the digest message, starting at the "Subject: blah"
> > line and continuing through the three "sdlfkj" lines.  [1.3.1.1] is just
> > the three "sdlfkj" lines.  [1.3.1.1.MIME] is the same as [1.3.1.HEADER],
> > which is the header of the digest message, being "Subject: blah", "Foo:
> > bar", and the blank line after.)
> > _______________________________________________
> > Imap-protocol mailing list
> > Imap-protocol@u.washington.edu
> > http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
> >
>
>_______________________________________________
>Imap-protocol mailing list
>Imap-protocol@u.washington.edu
>http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol