Internet Mail has emerged as a global standard for public and private messaging, linking together many tens of millions of users daily. Most of the core specifications for Internet Mail have been part of operational systems for ten or fifteen years. Recent enhancements include MIME (Multi-purpose Internet Mail Enhancements) and IMAP (Internet Message Access Protocol). MIME permits the encoding of multi-media, structured content; it is used for Internet Mail and the World Wide Web. IMAP permits complex interactions between a mail client and the user's remote message store. The purpose of IMC's MailConnect 1 event was to test the quality of implementation interoperability for these newer services.
MIME was specified several years ago and is being implemented, deployed, and used ever more broadly. This considerable base of experience provides a good basis for predicting the kinds of problems that would be encountered during interoperability testing. Hence the MailConnect event's purpose in doing MIME testing was to empirically assess the nature and extent of these difficulties, as well as to see whether unreported problems surfaced. IMAP is of more recent vintage. Although an earlier version had limited implementation and use, major enhancements make IMAP a strong candidate for supporting a broad range of remote access functions. Vendor and end-user interest in IMAP is intense. A large number of new implementations are under development or are getting initial deployment. Interoperability testing of these would be expected to demonstrate the "growing pains" of any new technology. Hence the purpose of IMAP interoperability testing was to surface these problems in a controlled environment so that they can be quickly remedied, before extensive production deployment takes place.
The event was held 13-14 August in San Jose, California. Fourteen organizations participated, most testing product rather than prototypes:
| CommTouch | Esys |
| Hummingbird | Innosoft International |
| Isocor | IBM/cc:Mail |
| MetaInfo | Microsoft |
| NetManage | Qualcomm |
| Software.com | SunSoft |
| Turnpike | Worldtalk |
Facilities consisted simply of a local area net, to which participants connected. A (very) slow-speed Internet connected was provided for simple remote testing and some file transfers. A formal testing scenario for MIME was developed by Patrik Faltstrom <paf@swip.net> and Lars-Johan Liman <liman@sunet.se>. A formal testing scenario for IMAP was developed by Steve Hole <steve@esys.ca>. Details about the scenarios, as well as other background materials and an archive of the online discussing surrounding the event, can be obtained online at the Internet Mail Consortium's Web site.
Approximately half of the participating organizations submitted test data to the IMC, discussing their results. This report summarizes that data. Given the informality of most submissions, this report should be considered as qualitative, rather than numerical. Further, it is intended to indicate the state of the "services" being tested, rather than of individual products.
Mime provides four sets of capabilities:
Each of these capabilities is extensible, with enhancements that can be private or standard. For example, the list of Content-types that is currently registered is well over one hundred, most of which have been added after publication of the original MIME specification. The richness of such an environment begs for interoperability problems, since the features that one correspondent's system supports might be quite different from the features supported by another. At issue for the MailConnect 1 testing was a core set of features that are considered to have universal appeal.
The good news is that most core features worked well among the testers. In some cases, the problems are with the user interface, determining how to present information to a user. Although underlying support for the MIME specification might be compliant, presentation to the user might be lacking or awkward. Some implementations acknowledged such awkwardness with the handling of altnerate character sets and with support for types of data that are not known "internally" to the software. However MailConnect interoperability is not a matter of human factors; it is limited exclusively to the question of exchanging bits over the wire, between two systems.
In this regard, systems were able to exchange most MIME data successfully, for a variety of character sets and a variety of data.
Problems that showed some general occurrence were:
Increased internationalization of the Internet originally prompted development of MIME, in order to permit email to carry text encoded in character sets other than ASCII. Although generally successfull, this ability has variable support across vendors. In some cases, the additional characters sets are supported but the user is not told which character set is in use. In other cases, other character sets are supported only through external viewers. MIME has different mechanisms for specifying alternate character sets in content portions than in email headers. Support for alternate character sets in headers is not universal.
MIME permits a complex, hierarchical structure for content components. Most mail systems have a simpler model with a series of "attachments", all at one level.
This has been part of an experiment written into the MIME standard, attempting to rudimentary formatting of textual data, such as bolding and italics. While there is some support for this among MIME-enabled email clients, it has not been very popular. The consensus among the Internet technical community is that HTML will fill this requirement, although there is very little support in current products.
Perhaps the most creative and ambitious part of the MIME specification, this Content-type specifies that each of its components is to be processed (displayed, played, etc.) at the same time. Thusly, one might have a voice commentary to some text that is displayed. This Content-type
This Content-type is intended to carry multiple forms of the same information. The recipient can then choose the form that is best for them, such as a document that is plain ASCII text, versus in Postscript printable form, versus in its original word processor internal format. Most MIME implementations do not treat /alternative differently from /mixed. That is, they make each of the versions equally available.
Not a part of the standard set of MIME definitions. It is intended for distinguishing messages that conform to Internet News conventions, which differ slightly from Internet email. This is not a widely used Content-type and the major type "Message" is not typically a source of sub-type creativity, the way Application and sometimes Multipart are. Some of the vendors that did not successfully process this Content-type during the testing indicated that they do expect to support it in the future.
When a message may be too large for transit through some portion of the Internet mail service, it can be segmented into a series of messages that travel independently, for reassembly into their original whole by the recipient. Each portion is wrapped in a MIME Message/partial label. A number of implementations do not do reassebly, so that the message appears to the recipient as a set of unrelated and incomplete messages.
Rather than send a document along with a message, Message/external-body permits a reference to be included. If the recipient wishes to obtain the actual document, they can follow the directions which are the /external-body content, such as for email for file transfer retrieval. A number of implementations do not support this feature, although it is starting to prove quite useful.
The primary protocol for client email acquisition of new mail is the Post Office Protocol (POP). It is simple and efficient for the basic task of downloading new mail to the client. This style of client/server interaction is called "offline" mail-reading in that the server is only a delivery transition node. All of the real user email work is done on the client machine, including long-term storage of email messages. The "master" copy of the user's mail is on the client machine. Two other styles of interaction are important for useful. One is called "online" and refers to having the server hold the email, with the client doing all work on messages residing on the server. If the client cannot connect to the server, then it can do no email work. The other mode is "disconnected" and means that the client and server have a more cooperative relationship, with new mail arriving at the server and the server holding copies of some or all of the user's mail, but the client too may hold some or all of the mail. When the client is not able to interact with the server, it can continue to process mail for which it has copies and to create new messages. When the client is later able to contact the server, changes are syncrhonized between them. This is called "disconnected" mode. POP cannot reasonably support online or disconnected modes. IMAP can.
Mailconnect 1 testing showed IMAP support falling into 3 categories:
Software implems a subset of the full IMAP repertoire of functions
All specified IMAP functions are implemented
Enhanced use of specified functions permit sadditional styles of interaction, in particular resynchronization.
MailConnect1 was sponsored by the Internet Mail Consortium. If you have any suggestions for additions or corrections to this Web page, please send them to phoffman@imc.org.