MIME 101

 Back in the day, emails were very rigid in how they could be composed. Simply put, emails were nothing but a lump of plain text. RFC 822 defines those standards. They could use only limited fonts and font sizes, there were no attachments and secure emails were still a few development cycles away. Further, emails couldn’t use international character sets. It wasn’t possible to send emails containing non-Latin characters. 

 If you wanted to send an attachment, you needed to convert it to plain text, then add that plain text to the body of the email. The recipient needed to do the opposite, extract the portion of text representing the attachment, then convert it back to the original format. Sometimes it even worked. 

 A further limitation of RFC 822 is that it does not define the structure of an email or its data format. At the start, since all you got was a single large chunk of ASCII characters, defining a structure was not necessary. 

 However, the situation has radically changed. Email can now be presented in web page format, international character sets are common, attachments can be of virtually any type, and there are sophisticated security environments for email, both built into the email client and as separate stand-alone applications.

 The prime mover in these developments has been Multipurpose Internet Mail Extensions, better known as MIME. RFC 822 still defines the email format, but MIME makes it possible to easily use the common types of email we see today. 

 What is MIME and how does it work?

 MIME sets out several protocols for the composition and format of an email. Not a formal standard, but one that has been universally adopted by all except perhaps Microsoft on some occasions. There are several RFC documents setting out the protocols, including RFCs 2045 and 2822. RFCs are not formally adopted standards, but are usually recognized as the very next best thing. Among other things they define:

 An email structure that allows for multiple data types in a single message, for example, text and images;

  •  Non-Latin and multiple character sets;

  •  Messages in rich text and HTML (web) formats; and 

  •  Attachments.

 There are also several other RFCs defining how email servers deal with MIME, particularly with SMTP, RFCs 3030 and 6152.

 Before we discuss how MIME works, please remember that RFC 822 is still the formal definition of an email message. MIME extends it by converting what we see and think of as an email message to that lump of plain text defined nearly 50 years ago. 

 The process is fairly simple, but as usual, the devil lies in the detail.

 The first step is for the MIME processor to examine the message. If it is simple text, then it is encoded with a header telling the recipient’s email client to expect plain text only. 

 If not, and this is usually the case nowadays, each part of the message is treated separately and the resulting ASCII text used to build the outgoing email message. Each part is contained in an envelope of a header and a footer. 

 The header defines the content type, what it is, and any other information needed, such as the original file name. Non-Latin characters or images are converted to an ASCII equivalent. There is also special handling for data file attachments from common applications such as Excel or Word to preserve formatting. 

 This allows for messages containing mixed content, those with attachments and reply messages with the original message attached.

 As an example, the contents of an RFC 822 message could include:

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier


This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain


This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=genome.jpeg;
modification-date="Wed, 12 Feb 2017 16:29:51 -0500";


PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--

 Many thanks to Wikipedia for the example

 If the message is to be encoded, it is passed to the security processor before being sent. 

 At the other end, the recipient’s email client does the same thing, but in reverse to reassemble the message as originally created. 

 Each part of the message is identified by the envelope header and footer. The information provided by the header defines how the data is to be decoded and displayed. The “Content-Disposition” example shown above defines the content as a jpeg picture attachment. It will be shown in the reconstructed email as an attachment which the user will need to click to open. 

 To summarise, MIME turns emails into the common format of an ASCII email that can be sent using the RFC822 standard and rebuilds incoming emails to their original format. That basically is MIME in a nutshell. 
Email Client SoftwareEmail Server Software