Context
E-mail has evolved through time. While there is a standard for the syntax of mail messages
MIME Messages
Overview
Mail messages E-mail messages are structured in a hierarchy. Each piece of the message is a 'part'. Each part has a type, such as:
- text/plain: Just text! No fancy formatting. Encoding can affect line-wrapping (search for "format=flowed").
- text/html:
Details
There is a very nice wikipedia article at
- References
- RFC's:
- RFC 5322: Internet Message Format obsoletes rfc2822 and rfc822.
- RFC 2045: MIME Part One: Format of Internet Message Bodies - Encoding non-ASCII stuff: content-transfer-encoding header, content-type header parameters, quoted printable encoding, base64 encoding, content-id header
- RFC 2046: MIME Part Two: Media Types - leaf content types (text/*, image/*, audio/*, video/*, application/*), composite types (multipart/*, message/*), content-type charset parameter, boundary delimiters, multipart/mixed, multipart/alternative, multipart/digest, multipart/parallel (deadish), message/rfc822, message/partial (deadish), message/external-body (deadish)
- RFC 2047: MIME Part Three: Message Header Extensions for Non-ASCII Text - MIME Encoded Words. The things that look like =?ENCODING?Q?gibberish?= or =?ENCODING?B?base64gibberish?=
- [http://tools.ietf.org/html/rfc2231 RFC 2231:
MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations] - Parameter encoding of long-values with character set encoding and language-expressing features (continuations).
- RFC 2387: The MIME Multipart/Related Content-type - content-type start parameter, content-type start-info parameter, content-type type parameter (redundant weirdness), content-disposition header
- RFC 1847: Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted - S/MIME, multipart/signed, multipart/encrypted
- RFC 3156: MIME Security with OpenPGP - Hate S/MIME? Try PGP!