|
ACADEMIC COMPUTING and COMMUNICATIONS CENTER | ||||||||
|
|
|
|
|
|
|
|
|
|
Making Email Talk with MIME | ||||
|
||||
| Fancying Up Your Email | ||||
|
Would you like your email to look as nice as Web pages do? Would you like send a picture in a note? Or send a WordPerfect file to a colleague in Europe, perhaps, or submit a paper for publication electronically? World Wide Web servers do things like this all the time. Why not email? You can do all these things in email. In fact, the protocols used by Web servers and browsers to exchange "rich text" files over the Internet were developed to perform the same tasks for electronic mail: Multipurpose Internet Mail Extensions, or MIME (pronounced as the word mime). Want to use MIME? Pine on UNIX understands it. Eudora does too, so if you've installed the ADN Network Services Kit on your personal computer, then you're set. Also newer versions of most WWW browsers, including Netscape, allow you to send email notes with MIME attachments. Alas, neither mail nor note on CMS are MIME-aware. (Nor is that likely to change. Another hint, perhaps?) |
||||
| What MIME Does | ||||
|
When Internet email was originally defined, its purpose was to enable the exchange
of short messages that would be read by people. So its original definition was
simple: a short "header" consisting of a few human-readable header lines that
say where the message is coming from and where it's going to; a blank line to
separate the header from the body; and a single (non-structured) message body
containing only human-readable text.
Over the years, it became clear that people wanted to do more with email than its designers originally envisioned. MIME was designed to deal with these needs. The specific goals taken on by the MIME development team were:
And that's exactly what MIME does.
|
||||
| How MIME Does It | ||||
The MIME designers took advantage of a small but crucial feature in the original
definition of Internet email: email software and transport systems are instructed
to ignore any lines in email message headers that they don't recognize. So MIME
email messages have the same set of email header lines as standard email messages,
with a few lines added that describe the MIME content of the message:
|
||||
| How You Do MIME | ||||
|
It's simple. To send a file, you "attach" it to a note; to receive a file is even
easier -- your MIME user agent will recognize the attachment and offer to receive
it. (It could display it instead, but that will take a bit more work on your part.
See Configuring MIME.)
What does this do for you? Well, you could use Eudora to send an HTML file from your PC or Mac to your ADN UNIX account, and then use pine receive it into your pubic_html directory. Does that sound useful? |
||||
| Sending a File with Eudora | ||||
|
A few of the Eudora "switches" and "configuration" options apply to MIME attachments;
you can set them manually each time you send or receive a file, but it might be
easier if you have Eudora automatically set them to your preferences.
Two switches (Special --> Switches) apply when you send files: "Always as Attachment" can either be selected or not; "Encode with" should be MIME (for Eudora for Windows) or Apple Double (for Eudora for Macs; in spite of the name difference, this is MIME). The configuration (Special --> Configuration) option "Automatically Receive Attachments" applies when you receive files. If you select this option, Eudora will automatically receive any attachments into the specified directory or folder (click the directory name to change the attachment directory or folder from Eudora's suggested default), using the attachment's original name. But you might prefer not to select this; then Eudora will ask you what you want to do with the file before it receives it. To attach and send a file with Eudora: Open your note as usual (Message --> New Message), address it, and type the subject and body of the note (it doesn't have to have a body). The fully qualified name of the attached file(s) will be displayed on the "Attachments" line. You don't type the file's name; instead select Message --> Attach Document to open the "Attach Document" dialog box. Use it to select the file you want to send -- it's just like any other dialog box you use to select a file. (Repeat if you wish to attach more files -- a GIF image to go along with the HTML file, perhaps?) Then send the note as usual. |
||||
| Receiving a File with Pine | ||||
|
Pine is an easy-to-use email system in general, and MIME attachments only add
a small wrinkle. To read incoming mail with MIME attachments: Login to your UNIX
account, enter: pine then type: i (Folder Index) to display your
INBOX. Use the up or down arrow keys to highlight the note you want
to read, then press Enter or type v (ViewMsg) to view it. Figure
1 shows a note with two MIME attachments displayed in Pine. The attachments
are listed at the top. (Note that the message body is considered an attachment,
but it's "Shown".)
While you're viewing the note, type v (ViewAttch). Pine will list the attachments. Highlight the file you want to receive and type s (Save). Pine will offer to save the file, with its original name, in your home directory. Pine always saves the file in your home directory by default, even if you've entered pine while you're in a different directory. If that's OK, press Enter and you're done. If you'd rather put the file in your public_html directory, use the left arrow key -- not Backspace (unless you want to also change the file's name, which you might want to do to make the name lowercase) -- to move before the name and type: public_html/ (so if the file's name was CAMP.HTM, you'll have: public_html/CAMP.HTM). If you want to put it into an entirely different directory, say your department's WWW directory, be sure to include the leading slash: /usr/local/etc/ ... and so on. The file will have read/write permissions only for you, it's owner, so you will have to do a chmod to make it publicly available on the WWW. |
||||
| A Sample MIME Message | ||||
|
I sent the note shown in figure 1 to my account on tigger; its MIME header fields are shown in bold.
The top-level content-type of a MIME message with multiple body parts is "multipart", and the content-type header line includes the "boundary-string" parameter, which defines the string that separates the different parts of the message body. The subtype in the sample message is "mixed" because its body parts are different types of data. In multipart/mixed messages, each part of the message has its own MIME content fields describing it. The first body part of the sample MIME message is a standard email message; like all standard email messages, its content-type is: Content-Type: TEXT/plain; charset=US-ASCIIThis is the default MIME content-type. The content-type of video file in the sample message is video/x-msvideo. The "x" in the subtype means that it is not yet registered. The .wav audio file is also an unregistered type: audio/x-wav. Both video/x-msvideo and audio/x-wav are common enough that there's a chance that other MIME user agents will know about them. (Netscape Navigator does, for example.) The text/plain part of the sample message's body is already in 7-bit US ASCII, so it didn't need to be encoded for transport and it didn't need a content-transfer-encoding field. (If it had one, its content-transfer-encoding would be 7bit.) The video and audio files are binary, so they were automatically encoded for transport. Thus the video has: Content-Transfer-Encoding: BASE64Base64 is the binary to 7-bit ASCII encoding scheme developed for MIME; MIME user agents automatically encode (and decode) binary files using base64 encoding. The encoded version is somewhat larger than the original file. (Compare the two sizes displayed by Pine in figure 1.) |
||||
| More on Content-Types | ||||
The MIME content-types are probably the most important innovation in MIME. There
are only seven top-level content-types: application, audio, image, message, multipart,
text, and video. The MIME designers consider these seven types to be "substantially
complete"; it is expected that current and future expansion will be accommodated
by the addition of new registered subtypes.
See the MIME FAQ for more information on MIME content-types; it's in the Ohio State FAQ archives: http://www.cis.ohio-state.edu/text/faq/usenet/mail/mimefaq/top.html
|
||||
| More on Transfer Encoding | ||||
|
In addition to base64 for encoding binary files, MIME provides another
type of transfer encoding that you've probably already seen: quoted-printable.
It's for data that's already for the most part printable ASCII characters.
Quoted-printable encoding leaves printable ASCII text alone, but any character that is not US ASCII is represented by an equal sign (=) followed by the character's numerical representation in the form of two hexadecimal digits. Quoted-printable encoding also splits lines that are longer than 76 characters after the 75th character, ending the first part of the line with an equal sign. (And have you ever received mail that had "=20" at the end of some lines? That's also quoted-printable encoding, to indicate that there was a blank at the end of that line; some email systems strip off -- or add -- trailing blanks.) Eudora uses quoted-printable encoding by default. These stray equal signs can make your notes look a bit messy when viewed by a non-MIME-aware email system; that's why we recommend that you turn quoted-printable off when you're using Eudora to compose ordinary notes. With it off, Eudora composes email in regular 7-bit US ASCII, with no extra equal signs. |
||||
| Configuring MIME | ||||
|
OK, so now we know what the MIME header fields are and what they mean. But how
do MIME-aware email software and World Wide Web servers decide what the content-type
of a particular file is? How do email software and Web browsers know what to do
with the text/html and video/x-msvideo files they receive?
Well, assuming for the moment that you're not using a Mac, how would you tell? (If you are using a Mac, you're probably wondering what the problem is -- the file's resource fork has all the information you'd ever need.) You'd look at the second part of the file's name -- its file extension. The extension tells you that mail.gif is a GIF image, index.html is an HTML FILE, and so on. That's exactly how MIME user agents tell. When a MIME user agent sends out a file, it looks up the file's content-type in a table that associates MIME content-types with specific file extensions, and when a MIME user agent receives a file, it looks the file's content-type in a table that associates content-types with the commands and options to display them. In UNIX, these tables are in the files .mime.type and .mailcap, respectively. In personal computer MIME user agents, this information tends to be set and stored as "options" or "preferences". In Netscape, for example, the MIME content-types, extensions, and associated commands are set in General Preferences (see figure 2).
Configuring Eudora to recognize and display MIME content-types is a bit more complicated. For Eudora Pro for Windows, it's explained in "Appendix D -- MIME and Mapping" in the Eudora manual (which, incidentally, includes brief introduction to MIME and a nice example of quoted-printable encoding). If you're on the adventurous side, it involves editing your eudora.ini file, in the section labeled [Mappings]. The mappings labeled in=, out=, and both= are for incoming, outgoing, and both. There are five parameters separated by commas: the PC file extension, the Mac creator code, the Mac type, the MIME type, and the MIME subtype. (Not all mappings have all five parameters, but you must have all four commas.) |
||||
| File Transfer with MIME | ||||
|
File transfer with FTP (File Transfer Protocol) is important, useful, and quite
common, but it has significant limitations: it only works on networks running
TCP/IP, and you must own or have received permission to use the accounts on both
end of the transfer.
Email has neither of these problems. So file transfer by email certainly has its place, and MIME makes it possible. If email software used on both ends is MIME-aware (MIME user agents), email is by far the best, easiest, and most fun way to exchange any type of file between two computer accounts. Sending or receiving email with attached files with a MIME user agent is not much harder than sending email without attached files. But just being able to send or receive the file is not enough. There are two additional considerations that you must take when the file you want to transfer is one that will be used by a program. (Or, for that matter, when it is an executable program itself.) |
||||
| The First: a Question | ||||
|
Will the person receiving your file be able to use it?
This is a problem more often than you might think. Not everyone uses the same version of the same software on the same platform (type of machine and operating system). So, a person using a PC running Windows will probably not be able to use a Mac BinHex file. And the .doc file you create with Word 6 isn't going to be of much use to your colleague who only has Word 2. So, first ask the person who's receiving the file what type of file they can handle. But even if you have WordPerfect for Windows 6.1 and they have Word 2, don't worry, you'll be able to accommodate them. WordPerfect 6.1 has 39 choices for "Save as file type" on its "Save as" dialog box (in its File menu), including four for MS Word 2. Or you might want to save the file in a special file format such as Microsoft's RTF (Rich Text Format) that can be easily handled on both ends. (There's even a content-type for RTF files -- application/rtf. Configure your MIME user agent to open the RTF file in the word processor of your choice.) If the file you're transferring is data that will be used with a database, spreadsheet, or statistical program, you might have to do something special to prepare a file that's suitable to be sent. The documentation for the program should tell you what you need to do to prepare the data; often you have to "export" it in a special form for transport. Here too you'll also have to take into consideration whether the person who will receive the file has the right program (and the right version of the program) to handle the file. |
||||
| The Second (and it's a big one): Viruses | ||||
|
Now that I've gotten you all excited about the prospect of sending files with
MIME (at least, I hope I have), here's a downside: You cannot spread or become
infected by viruses (of the computer type, that is) by sending or receiving plain
email. You can, however, do either when you send or receive files as MIME attachments.
Text files are OK, but executable files (like .com and .exe files)
and, yes MS Word .doc files, aren't. So if you're sent an MIME attachment that
you didn't expect, don't save or use it. And check your machine for viruses before
you send one.
(In case you think this couldn't happen to you, think again. It could. The latest virus scare on the 'Net, the Hare virus, is known to have been spread via posts to Usenet/Netnews newsgroups.)
|
||||
| The ADN Connection, Sept/Oct 1996 | Previous: Public Labs Require Passwords | Next: A Brief Email History |
| 1999-9-10 connect@uic.edu |
|
