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.
With MIME, you can:
Like non-MIME messages, though, many MIME messages have just one part.
Example: Encoded MIME message
From: Jerry Peek <email@example.com> To: firstname.lastname@example.org Subject: Un =?iso-8859-1?Q?d=EDa_dif=EDcil?= 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 are some things 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. A different specification, RFC 1522, is a standard for non-ASCII text in the header. RFC 1521 has been replaced by RFC 2045, and RFC 1522 has been replaced by RFC 2047. There are links from the Reference List.
MH doesn't support RFC 1522 character encoding in message headers you read or send. nmh does support it (actually, RFC 2047) in messages you read, but it doesn't yet have automated support for composing messages using those characters; you have to type them in by hand as you compose the message.
To make my message Subject: more readable, I could have written an ASCII approximation of the non-ASCII characters. That is, instead of Un día difícil, I'd write Un d'ia dif'icil. Most modern MUAs support RFC 2047, though, so let's hope that nmh can have complete support soon.
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.
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.
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
Message-ID:, that no other message in the world is
likely to have. A typical Content-ID: value
is <email@example.com>. Each part of a
multipart message has its own Content-ID:. Its main use
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.
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:
This file is from the third edition of the book MH & xmh: Email for Users & Programmers, ISBN 1-56592-093-7, by Jerry Peek. It 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 COPYING.
Copyright © 1991, 1992, 1995 O'Reilly Media, Inc.
Copyright © 1996, 1997, 1999, 2000, 2002, 2004 Jerry Peek
Last modified: 2006-05-31 15:13:43 -0700