58 lines
2.7 KiB
Plaintext
58 lines
2.7 KiB
Plaintext
MBOX-Line: From tss at iki.fi Thu Aug 16 21:14:56 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: <502DBEA4.2070204@verizon.net>
|
|
References: <502DBEA4.2070204@verizon.net>
|
|
Message-ID: <80122A6E-2516-4E9C-B389-B66E07BE05DB@iki.fi>
|
|
|
|
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.
|