MIME. Topical memo for PPNCG 1995/01/11

Update 1996/09/10: added pointers to MPACK/MUNPACK at its home site.

Updated 1996/04/09: No significant changes in content. Adjusted date format to avoid confusing USA readers, and added navigation links.

Update of 1995/04/03: Mentioned alternative approaches, e.g using a POP server on VAX/VMS and MIME-capable POP client.

Introduction

It seems to me that our users are increasingly being confronted by MIME, whether they like it or not. There are two main situations, in my experience with users, where surprises happen:

A user without a MIME-aware mail reader receives an incoming MIME-encoded mail and wonders what to do about it.
A user who has a MIME-capable mail software but had not intended to create MIME-encoded mail, accidentally sends MIME-encoded mail to a recipient who cannot deal with it.

Of course, some communities of users will already be taking advantage of MIME, having established that they can all exploit it: we don't really need to discuss that aspect.

Background reading

The usenet group for discussion of MIME is comp.mail.mime, and a good starting point for background reading is its Frequently Asked Questions (FAQ) document (URL has been updated!).

When read in the latter format, it includes Web links to the many other references that it makes, including the specifications (RFCs) for MIME and other related standards.

Where can we help?

From my experience, I think there are two areas where we could help, broadly corresponding to the two situations mentioned above.

We need to assess the situations where no MIME capability is presently being offered to our users, and identify whether this shortcoming can be remedied, so that they will have less trouble with incoming MIME-encoded mail that they may get.
We need to offer advice to our users, particularly those who have or will have MIME capability, on how best to avoid causing unwelcome surprises when sending mail to other users (who might not be able to deal with MIME format yet).

To mention just one example, it seems that Eudora is commonly set up in such a way that mail that contains only the normal "7-bit" repertoire of ASCII characters will be sent without use of MIME format, but it only takes the user to insert, say, a Pound-sterling character in the mail and it would quietly swap into MIME mode. The recipient would get a mail in which the pound-sterling character was represented by the character string "=A3", which (in the absence of MIME-awareness in the recipient's software) would be displayed to the user as such, causing confusion.

Un*x platforms seem to be well-served with solutions: PINE, for example. PC (MS Windows) and Mac platforms can use, for example, Eudora (available as a stripped down free version, or a fuller-function supported commercial product) if they are content with a POP-based mailer. An official PC version of PINE is available (not tried by me). When we had an IBM mainframe, I was aware of work by Rick Troth to support MIME on VM/CMS: it looked pretty nice, although I must admit I did not follow it up. I leave it to others to decide whether they want to pursue that.

So the area that seems to need attention in our context is VAX/VMS, since this is still in widespread use in our community. We were already aware, at least by name, of two different commercially available MIME-capable mail packages: ECSmail and PMDF.

Update as of 1995/03/20

At Glasgow we decided to follow up some rumours of a free PINE for VMS: on investigation it transpires that versions of PINE have been ported to VMS at the Hebrew University of Jerusalem (HUJI) by Yehavi Bourvine. I installed this at Glasgow in a VAX/VMS/MULTINET environment, and Dave Sankey also reports useful results on an OpenVMS/DEC ALPHA/MULTINET environment. See my ongoing status report.

Update of 1995/04/03

Advice to senders whose recipients may not be MIME-aware

When using a MIME-capable mail composer, composing mail for a recipient who might not be able to interpret MIME encoding, you should take some steps to avoid inadvertently creating MIME-format mail. Taking Eudora as an example, here are some of the steps that you might consider.

Turn off the configuration switch "May use QP". This will prevent PC Eudora from using MIME QP encoding, but of course has the consequence that if you do something that calls for QP encoding, the mail might not get through correctly: see later points for further suggestions.
Avoid use of characters that are not in the US-ASCII (7-bit) code. (If you do so, your recipient may not be able to see them, or may see a different character from what you typed). In a UK environment the most common "offence" is to use a pound sterling character.
Use a restricted line length when composing your mail. Line lengths of less than 80, preferably less than about 73, are recommended. Make sure that you understand your composition software - it might display text in a line-wrapped form without really including the line-end characters in the mail, but instead sending each paragraph as a single very long "line"! In PC Eudora, turn on the "word wrap" switch.
Don't use the "Attach document" procedure for sending an attached document in mail (this normally results in a MIME enclosure being created). Instead, include the text of the document in the body of the mail (with PC Eudora use Paste, with PINE use the "Ctrl/R" [Read file] command in the composition window), or send the document as a separate mail if appropriate. In doing this, make sure that the document also complies with the other restrictions (as to character repertoire and line length) mentioned above.

Handling MIME mail that arrived on a MIME-incapable platform

If a mail in MIME format is received on a platform that does not explicitly support MIME decoding, there are several approaches that might be useful.

The most widely recommended utilities for handling MIME-format mail that has arrived on a platform that cannot handle it, or that cannot be automatically decoded because its headers have been lost or garbled, are MPACK/MUNPACK available from CMU. Take care to retrieve the package version appropriate to your platform.

There are a various simple utilities available, that can encode and decode quoted-printable and base-64 MIME encodings. One, "encdec", written in C, can be obtained, for example, in the directory:

   ftp://ftp.efd.lth.se/pub/mail/

It is the user's responsibility to pull out the relevant part of the mail (for example using an editor) and make it available to the appropriate option of encdec. Although admittedly tedious, this has the advantage that it can deal just as well with mail whose MIME headers have got mangled or lost. These utilities have been run successfully on the VAX/VMS system.

Other utilities are mentioned in part 2 of the MIME FAQ.

Another approach that might prove profitable would be to transfer the mail from the MIME-incapable platform to a MIME-capable one. However, this is non-trivial, since the process of transferring mail might well upset the mail headers and preclude the correct decoding by automatic interpretation of the MIME headers. In this context it may be mentioned that the mail distribution server used by the PPNCG at Manchester supplied its own set of mail headers, and (as far as the destination system is concerned) the original headers, including any MIME headers, became part of the body of the mail, and could not be actioned. {Remark added Sept.'95 - the Rutherford Lab mail list server now being used does not have this problem.}

Some successful experiments were conducted on the Glasgow system that may serve as a starting point for your investigations.

VAX/VMS MULTINET includes a POP server, which we were already running on our system at Glasgow for other reasons. Using a MIME-capable POP client, such as PC Eudora, to process MIME-encoded mail (that had arrived on our VAX/VMS system by SMTP procedures) proved entirely successful. To avoid any possible misunderstanding, let me stress that the VMS-ported PINE played no role in this: on the VAX system only MULTINET and VMS MAIL were involved, i.e the VMS software was not MIME-capable.

Note that because a POP server only gives access to the newmail folder, if the mail has already been inspected on the VAX system itself (e.g using VMS MAIL) and has consequently been moved to the MAIL folder, it is necessary to put it back into the NEWMAIL folder. The obvious strategem of a MOVE NEWMAIL command from within VMS MAIL proved completely effective (surprising as this might seem).

Such a transfer would work equally well using the ported IMAPD server on the VAX/VMS system, and connecting from an IMAP client such as PC PINE.

It is assumed in the above that the mail has arrived by SMTP procedures and that the mail headers are presented in a sufficiently similar way to what we use at Glasgow. I also conducted some experiments with delivering MIME mail to our VAX/VMS system using DECNET and CBS procedures, and attempting to process them via the POP server with PC Eudora, and I can report for delivery by DECNET (specifically, for mail that had been forwarded via DXMINT, e.g mail to GLPHV2.CERN.CH) that it did not work and there seems little prospect of it working, since there are no usable mail headers delivered; and for CBS that the MIME decoding worked perfectly well in PC-Eudora (although much else would not, for example the addresses are unfit for Reply etc. functions).