View source for IntroductionToMIME

= A Quick Introduction to Email Formats =

''I originally wrote the following for my employer's wiki, but I stole it and translated it for nemwiki, too -- [[Screwtape|st]]''

An email message, in raw form, has two parts: the headers and the body.

The headers are seperated from the body by exactly one blank line.

== Headers ==

Headers look like this:
 Header-Name: value

Header names are case-insensitive.

Headers can be wrapped onto more than one line by prefixing the second and following lines with whitespace: 
 Header-Name: a very long value
    which must be wrapped
    over several lines

Headers whose names begin with <tt>X-</tt> or <tt>x-</tt> are non-standard. (known simply as [[X-Headers]])

== Body ==
The interpretation of the message body depends on certain headers being present. Normally, the message is assumed to be 7-bit ASCII text. If the message has a <tt>MIME-Version: 1.0</tt> header, then the body is treated as a MIME-encoded message. MIME stands for "Multipurpose Internet Mail Extensions", and it is described in RFC 2045 (http://www.faqs.org/rfcs/rfc2045.html)

A MIME-encoded message should have the following headers:

* '''MIME-Version'''
** The current version of the MIME specification 
* '''Content-Type'''
** Describes the format of the data in the message body. The raw content-type (<tt>text/plain</tt>, for example) can have parameters seperated by semicolons:
 Content-Type: text/plain; charset="ISO-8859-1"
* '''Content-Transfer-Encoding'''
** Some data formats won't fit into 7-bit ASCII - for example, any text that has accented characters, anything written in an east-Asian script, or binary files. MIME-based mail composers can encode the data into a sequence of 7-bit printable ASCII characters, and MIME-based mail readers will automatically decode the sequence before trying to do anything to it (such as save it to disk, or display it).

Along with all the usual values for <tt>Content-Type</tt> (<tt>text/html</tt>, <tt>text/plain</tt>, <tt>image/png</tt>, <tt>audio/mp3</tt>, <tt>application/octet-stream</tt> and so forth) there are two special values that apply to email messages: <tt>multipart/alternative</tt> and <tt>multipart/related</tt>. Messages with these content types contain a number of other messages, each with their own headers and bodies. These sub-messages are assumed to be MIME-format (so they don't need a <tt>MIME-Version</tt> header).

For a <tt>multipart/alternative</tt> message, the mail reader will display the 'best' of the alternatives available, and ignore the others (For example, you might have a <tt>text/html</tt> message and a <tt>text/plain</tt> message. If your mail reader can render HTML it should display the <tt>text/html</tt> message, otherwise it should display the <tt>text/plain</tt> message.

For a <tt>multipart/related</tt> message, all the messages inside should be, well, related. For example, an HTML page that includes images should be grouped with the images in a <tt>multipart/related</tt> section.

Both <tt>multipart/alternative</tt> and <tt>multipart/related</tt> content-types should have a <tt>boundary</tt> parameter that contains a line used (prefixed by <tt>--</tt>) to mark the beginning of message parts. Obviously, it should be a line that does not occur anywhere else in the message. 

Here's a simple MIME message:

<pre>MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="flubblegidget"

Text before the first boundary marker is hidden by MIME mail readers.

--flubblegidget
Content-Type: text/plain

Hello, world!
--flubblegidget
Content-Type: text/html

<html><body><h1>Hello, world!</h1></body></html>
--flubblegidget--
</pre>

'''Note:''' If you copy and paste the above into a file to try it out with, say, Outlook Express, the wiki puts spaces on all the blank lines - you'll have to make sure that all the blank lines really are empty.

[[Category:Bookmark]]