wasm-demo/demo/ermis-f/imap-protocol/cur/1600094991.22583.mbox:2,S

37 lines
1.8 KiB
Plaintext

MBOX-Line: From Pidgeot18 at verizon.net Thu Jul 16 22:10:09 2015
To: imap-protocol@u.washington.edu
From: Joshua Cranmer <Pidgeot18@verizon.net>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] MIME parsing and part numbering
In-Reply-To: <55A87BA1.25167.5CD5348F@David.Harris.pmail.gen.nz>
References: <55A87BA1.25167.5CD5348F@David.Harris.pmail.gen.nz>
Message-ID: <55A88E31.7000002@verizon.net>
On 7/16/2015 10:50 PM, David Harris wrote:
> As I mentioned last week, I'm in the process of replacing my existing MIME parser.
>
> I'm putting together a commandline version of this parser that spits out a full MIME
> parse including all IMAP-specific parts and part numbers, offsets, and octet and line
> counts. I propose to make this application publicly available in the hope that it might
> assist new IMAP developers to come to terms with the way MIME and IMAP
> interact with each other, particularly in regard to part numbering.
>
> I have a library of over a million mail messages I can use to test it out, but if you
> have a few interesting boundary-case messages, or hugely complex messages that
> you would be willing to share with me for testing purposes only, I'd be glad to
> receive them (although please be aware that I run my mail server with a 4MB per
> message limit). Please zip them if possible.
Several years ago, I tested a message where the body was a
message/rfc822 part. On four different IMAP servers, I got four
different results for the part numbering. I don't have an actual copy of
it as an evil message, but it is an evil edge case worth considering.
It's also worth considering as potential edge cases TNEF, uuencode,
message/news, message/global.
--
Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth