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.
Like non-MIME messages, though, many MIME messages have just one part.
From: Jerry Peek <jpeek@jpeek.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 día 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.
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.
Finally, a message can be multipart, with several separate body parts. It's possible for the parts to be of different types (the Section on Multipart Messages explains the MIME syntax for multipart messages). For example, a message could start with a text part to describe what's in the message, then an audio part with a message from a photographer, followed by five of the photographer's pictures (in five image parts). It's also possible for each of the multipart body parts to be another complete multipart message -- with its own parts. That is, MIME messages can be recursive.
A Content-type: must have a subtype. The type and subtype names have a slash (/) between them. For instance, image/gif is a picture in the GIF format; the type is image and the subtype is gif. The MIME Reference Guide lists many of the common content types and subtypes.
Finally, a Content-type: can have optional parameters at the end, starting with a semicolon (;). For example, the charset= parameter in
Content-type: text/plain; charset=iso-8859-1says that the message body uses the ISO-8859-1 character set. (The default charset is us-ascii.)
The default Content-type: is text/plain.
The Content-ID: is a unique string, similar to the RFC 822 field
Message-ID:, that no other message in the world is likely to have.
A typical Content-ID: value is <1283.780402430.1@ora.com>.
Each part of a multipart message has its own Content-ID:.
Its main use is identifying
external parts
and cached body parts.
The Content-Description: field describes the content in words, like
Report on Zeta Meeting.
The RFC 822 Subject: field describes the whole message.
You can add a Content-Description: in the message header,
but it's more useful for describing a part of a multipart message.
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:
[Table of Contents] [Index] [Previous: Caution About MH Files and Newline Characters] [Next: Multipart Messages]
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 <jpeek@jpeek.com>