Overview of MIME Messages

[previous] [next] [table of contents] [index]

This section starts by explaining the overall purposes of MIME. Next it shows a simple MIME message and introduces the basic parts of a MIME message.

Purposes of MIME

With MIME, you can: Let's look at a MIME message as it would arrive in your MH inbox. The message in the next Example was encoded by the sender; this is how it is actually stored on disk by the recipient's MTA (mail transfer agent), waiting for someone to read it. This is also how the message will look to a person who does not have a MIME-capable MUA (mail user agent):

Example: Encoded MIME message

From: Jerry Peek <jerry@ora.com>
To: carlos@entelfam.cl
Subject: Un d'ia dif'icil
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Carlos, estoy en la casa de mi amigo.  Pero, =A1qu=E9 d=EDa dif=EDcil!
Tom=E9 un taxi entre al aeropuerto y el hotel.  "=A1Tenga cuidado!",
me dijo el chofer.  "=A1Esta parte de la ciudad es peligrosa!"  Fue
evidente para m=ED.  Yo o=EDa que la ciudad tiene partes malas, y esa
parte pareci=F3 as=ED.  Los edificios ten=EDan barrotes sobre sus
ventanas, hubo gente sospechosa en la calle, y todas las puertas estaban
cerrada con llave.  "=A1Vaya con di=F3s!"  =C9l se fue.
Before we dig into that message, here's one thing you should be aware of. RFC 1521, the MIME specification that MH supports, only tells how to transfer non-ASCII text and graphics in the message body. Although RFC 1521 adds fields like MIME-Version: to a message header -- it doesn't tell how to put non-ASCII text in a message header. So, in my message Subject:, I had to write the word da as d'ia. (In the body, that word would have been encoded d=EDa.) RFC 1522 -- which MH doesn't support (at least, not yet) -- is a standard for non-ASCII text in the header.

MIME Header Fields

The header field MIME-Version: 1.0 in the previous Example tells that the message is in MIME format. It's a signal to mail programs that the message meets the requirements of RFC 1521. (Unfortunately, a few mail programs add that header field to messages that aren't in MIME format.)

Here's an overview of the other header fields that a MIME message may have. I'll toss in some MIME philosophy along the way. We can't cover everything in the MIME spec; it's close to 100 pages long! Other sections of this chapter, and sections of later Chapters, have more MIME information. The Section More About MIME explains how to find all the gory details.

The list of content subtypes changes a lot. Quite a few subtypes are for non-UNIX computers. This book doesn't cover every content subtype; examples use some of the most common subtypes from RFC 1521. Your MH setup probably doesn't need to support all subtypes:

MIME Encoding

MIME messages are designed to be readable by all existing RFC 822-compatible mail programs. (Although, of course, MUAs that don't understand MIME won't be able to interpret the MIME-specific parts.) The messages may be sent through all kinds of networks and gateways. So, MIME encodes messages that have non-ASCII parts. The Content-transfer-encoding: field tells the recipient the way a message was encoded -- and how to decode it. (Encoding usually isn't required for plain ASCII text.)

For instance, the previous Example message, from me to a friend in Chile, is in Spanish (more or less :-)). Spanish uses characters like and that aren't part of the ASCII character set. My MIME-capable MUA could encode the message's non-ASCII characters to pass safely through an ASCII-only mail transfer system. For instance, the character was encoded as the three-character sequence =A1. When the message gets to Chile, my friend's MIME-capable mail reader will translate the message's encoded characters to the correct Spanish characters.

One important feature of MIME's encodings is that they are designed to leave as much of the message in plain ASCII text as possible. In general, MIME only translates the characters that some email transfer systems would munge. So, if the recipient doesn't have a MIME-capable MUA, the encoded text in the message will probably still make some sense. (It's possible to encode text messages so that people can't read them without decoding. But, unless you want to hide words or have another reason, one of the less-severe encodings will probably do the job. In general, MH chooses human-readable encoding for text messages.)

Of course, when MIME encodes a binary file (like a digitized picture) that people can't read in the first place, the encoded data won't be any easier for a person to read. MIME encoding is designed to get the data safely through almost every known mail transfer system and gateway. One of the major wins in MIME is that it was designed to work everywhere, including "broken" and "brain-damaged" systems. Instead of trying to impose a new standard on mail transfer systems, MIME works with existing systems -- and adapts to their eccentricities.

Although you don't need to understand how encoding works to use MIME, you should have a general idea of the types of encoding. So, if you'd like to skip the technical details in the following section, please do skim it and learn the types of encoding. There are five encodings:

One of MIME's main goals is to make different email programs work with each other. To make interoperability more likely, the MIME designers tried to avoid having lots of different content-types. They tried even harder to avoid lots of different encodings. MIME content types and subtypes, as well as encodings, are registered with the IANA (Internet Assigned Numbers Authority). "Experimental" unofficial values start with X-, like X-pbm. A few experimental content-types and subtypes are in wide use. But in general, so that as many people as possible can read your message, try to avoid inventing new content types and subtypes. If you get the urge to create, the comp.mail.mime newsgroup and the info-mime mailing list are great places to work it out.

[Table of Contents] [Index] [Previous: Caution About MH Files and Newline Characters] [Next: Multipart Messages]


Last change $Date: 1996/06/06 15:12:06 $

This file is from the third edition of the book MH & xmh: Email for Users & Programmers, ISBN 1-56592-093-7, by Jerry Peek. Copyright 1991, 1992, 1995 by O'Reilly & Associates, Inc. This file is freely-available; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation. For more information, see the file copying.htm.

Suggestions are welcome: Jerry Peek <jerry@ora.com>

Questions or problems regarding this web site should be directed to Steve Gielda.
Copyright 1999 www.cotse.com.  All rights reserved.
Last modified: Friday April 02, 1999.