Subject: Ryan Finnie's MIME Torture Test v1.0
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 23:28:34 -0700

Welcome to Ryan Finnie's MIME torture test.  This message was designed
to introduce a couple of the newer features of MIME-aware MUAs, features
that have come around since the days of the original MIME torture test.

Just to be clear, this message SUPPLEMENTS the original torture test,
not replaces it.  The original test is still very much valid these days,
and new MUAs should strive to first pass the original test, then this
one.

By the way, the message/rfc822 parts have Content-Descriptions
containing Futurama quotes.  Bonus points if the MUA display these
somewhere.

Have fun!

Ryan Finnie

Subject: plain jane message
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 22:25:56 -0700

Subject: plain jane message
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Content-Type: text/plain
Message-Id: <1066973156.4264.42.camel@localhost>
Mime-Version: 1.0
Date: 23 Oct 2003 22:25:56 -0700
Content-Transfer-Encoding: 7bit

This is a plain text/plain message.  Nothing fancy here...

Subject: messages inside messages inside...
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 23:15:11 -0700

While a message/rfc822 part inside another message/rfc822 part in a
message isn't too strange, 200 iterations of that would be.  The MUA
should have some sense when to stop looping through.

Subject: the original message
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 23:09:05 -0700

by this point, I should be the 3rd layer deep!

I also have an attachment.

Subject: this message JUST contains an attachment
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 22:40:49 -0700

Subject: Attachment filename vs. name
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 23:09:16 -0700

In this message's attachment, the Content-Disposition has a
filename of blah1.gz, while the Content-Type has a name of
blah2.gz.  What should be done?  Well, since this is an attachment
(as indicated in the Content-Disposition), the MUA should
suggest a filename of blah1.gz.  The MUA *COULD* find a way to
represent the name of blah2.gz somewhere else, it's not needed.

Subject: No filename? No problem!
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 23:09:21 -0700

When searching for a suitable name to suggest for a filename,
the MUA should probably follow this order.  First, look for
Content-Disposition's filename attribute.  If that is missing,
look for Content-Type's file attribute.  If that is also missing,
I would recomment taking the Content-Description, stripping off
any characters that cannot be used in a filename, and suggesting
that.

If none of those fields are available, the MUA could just make
up a random filename.  SOMETHING is better than nothing.

Subject: html and text, both inline
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 22:40:45 -0700

This is the HTML part.

It should be displayed inline.

This is the text part.
It should ALSO be displayed inline.

Subject: text and text, both inline
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 22:41:29 -0700

This is the first text part.
It should be displayed inline.
This is the second text part.
It should also be displayed inline.

Subject: HTML and... HTML?
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 22:39:17 -0700

Bold!!!

What do we have here... This message is an HTML message. Also attached
is an HTML FILE. Both of these are in a multipart/mixed part.

Now, the first HTML part (what you're reading now) should be displayed
if the MUA is HTML-capable. If it is not, the MUA could possibly offer
this part up as an attachment to download, seeing as how no plaintext
part is offered as an alternative.

However, the second HTML part is listed with a disposition as
attachment. Therefore, it should be offered as an attachment, not
displayed inline.

Subject: smiley!
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 22:23:16 -0700

If this sentence is red, you are viewing the HTML part.
Wow, what a complicated message.  This message is laid out as so:

multipart/signed
| multipart/mixed
| | mutipart/related
| | | multipart/alternative
| | | | text/plain
| | | | text/html
| | | image/png (smiley)
| | image/gif (dot)
| application/pgp-signature

:)

A smiley face should be embedded into the HTML part above (if you are
viewing the HTML part), while the red square dot should be attached, not
displayed inline.  Additionally, this whole message is PGP signed.

This message introduces a few tricks that the MUA should cope with. 
First of all, the related / alternative combination doesn't make much
sense.  Here's the current setup in pseudo-code:

relationship between (alternative: HTML or text part) and PNG part

Why would the text part be related in anyway to the PNG?  Instead, the
correct and more logical way to do things would be:

alternative: (relationship between HTML and PNG parts) or text part

However, many MUAs compose a message using the first method, so this
should be taken care of when parsing the message.

Additionally, notice that the inline image has a disposition of
"attachment".  Despite this being in there, the smiley should be
embedded inline in the HTML part, not offered as an attachment. 
Conversely, the GIF image should be offered as an attachment, not
displayed inline.

If the MUA is not PGP capable, at the very least it should recognize
multipart/signed the same as multipart/mixed, and offer the
application/pgp-signature part as an attachment.

Subject: the PROPER way to do alternative/related
From: Ryan Finnie <[email-masked]>
To: [email-masked]
Date: 23 Oct 2003 22:32:37 -0700

If this sentence is green, you're viewing the HTML part.

Now, this is the way that all MUAs SHOULD treat this kind of situation.
The layout is like so:

multipart/alternative
| text/plain
| multipart/related
| | text/html
| | image/gif

See?  The GIF (which by the way should be inline towards the top of this
message) is related to the HTML, and that whole block is an alternative
to a text/plain part.  This is the opposite of the way shown in the
previous email.

Also, the embedded image here does not have a filename.  As mentioned
above, the MUA should suggest something as a filename, even here (the
user may want to save the embedded image, so a filename would be
helpful).  In this case, I would recommend appending the random text
to be suggested to the user with the part's subtype, in this case
something like c20vsidlkvm.gif.