Interoperability Tests of MIME

Internet Mail Consortium

August 13-14, 1996

1 Overview

1.1 History

The Internet suite of standards contains a number of standars regarding Internet electronic mail (e-mail) messages. A few of the more important ones are

RFC-821, Simple Mail Transfer Protocol, which regulates the most common way of transferring mail messages between hosts.

RFC-822, Standard for the Format of ARPA Internet Text Messages, which regulates the format of the contents of an Internet e-mail message.

RFC-1123, Requirements for Internet Hosts -- Application and Support, which contains amendments to a number of RFCs, among them 821 and 822.

RFC-1521, MIME (Multipurpose Internet Mail Extensions) Part One, which regulates ways of tagging and coding the information in messages bodies. This facilitates transfer of data other than English text.

RFC-1522, MIME (Multipurpose Internet Mail Extensions) Part Two, which regulates ways of tagging and coding the information in the message headers. This allows a variety of character sets to be used in header fields.

The Internet Mail Consortium (IMC) wants to encourage the use of these modern standards, and by performing the following tests during the IMC MIME tests 1996 in San Jose we hope to inspire software developers and vendors to strive towards interoperability in a standardized way.

1.2 Goals and Objectives

The goal of these tests is to prove the ability to send more complicated electronic mail than pure English text between applications conforming to the standards above.

Part from testing applications for their conformance to the minimal suite of requirements stated in RFC-1521, we also want to make a brief summary of the availability of optional MIME functionality in each product, to aid customers wanting to compare MIME software.

The tests should be viewed as technical, and the emphasis is on the software's behaviour towards the rest of the Internet, and on the correctness of the final contents of the mail messages. Many aspects of mail software must be regarded as matters of taste, and we have tried to avoid those, and to concentrate on qualities that can be measured in an objective manner.

2. Test Specification

The tests are divided into 4 classes.

M - Minimal MIME conformance, as described in relevant RFCs above.

SM - MIME and features which are necessary to communicate using 8-bit characters, i.e., extensions to the minimal conformance test to include handling of ISO-8859-1 in a uniform way.

EM - Extra MIME functionality such as handling of character sets not mentioned in class M or SM, and handling of other types of data, e.g., picures and sound.

N - Non-MIME functionality, such as requirements on transfer systems and gateways.

EN - Extra non-MIME functionality, such as use of optional parameters in transfer systems. The results of these tests are not relevant for the certification process.

Test cases are specified in section 3.5.

3 Test Procedures

The tests should primarily be carried out before the IMC MIME tests, by the participating parties. There is one mailback server which will generate test messages with MIME content according to the specification, to test software capabilies for incoming mail. To test capabiliteies for outgoing mail, there will be a mailbox that is manually examined by the test leaders.

The participants are expected to complete a test form (Appendix A) with correct information regarding their software. The test forms should be brought to the IMC MIME test event. During the actual meeting, the test leaders will verify various sections of various test forms. The final results will be compiled and made part of the final IMC test report.

Software participating in the test is supposed to be "as is", which means that it should be installed out of the box, with no special amendments from the participating organisation. All extra configuration, beyond normal setup expected by the user and according to the installation manual, is to be indicated in the test form as verbose comments. If the software requires external software to perform one or more tests, that should be clearly indicated, and a note should make clear whether that external software is included in the distribution of the tested software or not.

3.1 Reception Tests

To test if a client can parse a MIME message of a specific type, a mailback service is available, from which messages can be ordered. For more information, send a message to mimeback@bunyip.com with the command HELP as the only word in the subject line, e.g.,

To: mimeback@bunyip.com Subject: HELP
You will receive a plain text messgage containing further instructions on how to use the mimeback server.

3.2 Transmission Tests

In many cases the participants are also expected to produce messages. To have an outgoing message verified, please send it to

mime-test@cafax.se
and not to any personal mailbox. A test leader will reply to the message with comments on its contents. Please make sure that the sender addresses of your test messages are valid return addresses.

The test leaders are not interested in seeing test messages on MIME functionality which the participants know they handle correct (i.e. like the question if you produce a correct MIME Version header line). This mail address is supposed to only be used for questionable formatting and encapsulation problems.

3.3 Interoperability Tests

A mailing list

mime-participants@cafax.se
will be created to facilitate communication and cross-platform tests between the participants. This way it will be easy for participants to test the interopability of their software with other participants. Of course this course of action depends a lot on the good will and positive attitude of the participants. (Read: Don't abuse!)

3.4 Test results

The result of each test can be either a clear "Yes", a "No", or a combination of "Not applicable" and a comment. A "Yes" or a "No" may be accompanied by a comment giving extra information.

Tests regarding software's ability to handle MIME message types are to be interpreted as whether the software is able to handle it or not in its basic configuration. If the user has to take extra measures to obtain the functionality it is to be indicated as "No" with an explaining comment starting with the expression "User configurable".

3.5 Test Criteria

The following are the test criteria that the software has to meet, to get certified in the indicated test class.

3.5.1. Class M - Minimal MIME conformance tests

M1 Always generate a "MIME-Version: 1.0" header field.

M2 Recognize the Content-Transfer-Encoding header field, and decode all received data encoded with either the quoted-printable or base64 implementations. Encode any data sent that is not in seven-bit mail-ready representation using one of these transformations and include the appropriate Content-Transfer-Encoding header field, unless the underlying transport mechanism supports non-seven-bit data, as SMTP does not.

(Interoperability comment: For clarification it is stated that software should implement both encodings, and be able to handle mail encoded in any one of them.)

M3 Recognize and interpret the Content-Type header field, and avoid showing users raw data with a Content-Type field other than text. Be able to send at least text/plain messages, with the character set specified as a parameter if it is not US-ASCII.

M4 Explicitly handle the following Content-Type values, to at least the following extents:

M4.1 Text

M4.1.1 Recognize and display "text" mail with the character set"US-ASCII."

M4.1.2 Recognize other character sets at least to the extent of being able to inform the user about what character set the message uses.

M4.1.3 Recognize the "ISO-8859-*" character sets to the extent of being able to display those characters that are common to ISO-8859-* and US-ASCII, namely all characters represented by octet values 0-127.

(Interoperability comment: Which glyphs to display for octets with values in the range 128-255 is up to the implementation.)

M4.1.4 For unrecognized subtypes, show or offer to show the user the "raw" version of the data after conversion of the content from canonical form to local form.

M4.2 Message

M4.2.1 Recognize and display at least the primary (822) encapsulation.

(Interoperability comment: Note that 822 is just a name of the subtype. See RFC-1521 for description of the type.)

M4.3 Multipart

M4.3.1 Recognize the primary (mixed) subtype. Display all relevant information on the message level and the body part header level and then display or offer to display each of the body parts individually.

M4.3.2 Recognize the "alternative" subtype, and avoid showing the user redundant parts of multipart/alternative mail.

M4.3.3 Treat all unrecognized subtypes as if they were "mixed".

M4.4 Application

M4.4.1 Offer to remove the Content-Transfer-Encoding. The software should be able to handle types of Content-Transfer-Encoding defined in RFC-1521. The resulting information should be written to a user file.

M5 Upon encountering any unrecognized Content-Type, treat the message as if it had a Content-Type of "application/octet-stream" with no parameter subarguments. How such data are handled is up to an implementation, but suggested options for handling such unrecognized data include offering the user to write it to a file (decoded from its mail transport format) and offering the user to name a program to which the decoded data should be passed as input. Unrecognized predefined types, which might include audio, image, or video, should also be treated in this way.

3.5.2. Class S - Minimal functionality required in Sweden

S1 Ability to send and receive text/plain message types according to rule M4.1.1 with the extension that in character set ISO-8859-1 the octets values 128-255 (decimal) must be displayed using the correct glyphs.

(Interoperability comment: It is acceptable that some graphic symbols are not displayed correctly if the reason for that is that no complete translation table between ISO-8859-1 and the native character set can be generated.)

S2 Ability to send and receive messages with header lines encoded according to RFC-1522 with character set ISO-8859-1. Recognize other "ISO-8859-*" character sets to the extent of being able to display those characters that are common to ISO-8859-* and US-ASCII, namely all characters represented by octet values 0-127.

3.5.3 Class EM - Extra tests about MIME functionality

Tests of specific MIME types. For each type, it should be noted if the content type can be received and/or sent with the software unsing the basic configuration installed out of the box. If the content type can be recieved/sent, but only after additional configuration, that must be clearly stated in the test form. If the content type is displayed/composed by using external software, that must also be clearly stated.

EM1 Content-Type Text

Is the software able to handle messages with the following specifications.

EM1.1 Charset Parameters to Type Text/Plain

EM1.1.1 text/plain; charset=SEN_850200_B

EM1.1.2 text/plain; charset=ISO-2022-JP-2

EM1.2 text/enriched

EM2 Content-Type Image

EM2.1 image/gif

EM2.2 image/jpeg

EM2.3 image/tiff

EM3 Content-Type Audio

EM3.1 audio/basic

EM4 Content-Type Application

EM4.1 application/msword

EM4.2 application/postscript

EM5 Content-Type Multipart

EM5.1 multipart/appledouble

EM5.2 multipart/report

This format is specified in Internet-Drafts created by the IETF Notary Working Group. For gateways from/to X.400, the definitions can be found in Internet drafts created by the IETF Mixer Working Group.

EM6 Content-Type Message

EM6.1 message/partial

EM6.2 message/external-body (This test uses multipart/alternative also). It must be noted which access types are supported.

EM7 Content-Type Video

EM7.1 video/mpeg

EM7.2 video/quicktime

3.5.4 Class N - Extra tests about non-MIME functionality

The following requirement is not related to MIME message content specifications.

N3 SMTP Clients

N3.2 An SMTP client must never send high octets (i.e., with values in the range 128-255) without first having verified that the server is able to handle them. One method of such verification is the 8BITMIME STMP extension. Note that headerlines never may contain high octets. Header lines must be encoded according to RFC-1522.

The client must never use high octets in envelope addresses.

3.5.5 Class EN

The following tests reflect extra functionality without connection to MIME message content specifications..

EN2 SMTP servers - ESMTP

EN2.1 The server recognizes the EHLO command and reacts accordingly by listing its extensions.

EN2.2 The server handles the SIZE extension. (RFC-1653)

EN2.3 The server handles the 8BITMIME extension correctly. This implies that the server is able to convert the content-transport-encoding if required in the next hop. (RFC-1652)

EN2.4 The server handles the DSN extension correctly. (RFC-1891 and RFC-1894).

EN3 SMTP clients - ESMTP

EN3.1 The client uses EHLO to determin if the server in question is able to handle SMTP extensions.

EN3.2 The client recognizes and uses the SIZE extension correctly. (RFC-1653)

EN3.3 The client recognizes and uses the 8BITMIME extension correctly. (RFC-1652)

EN3.4 The client is able to recognize and use the DSN extension correctly. (RFC-1891 and RFC-1894).

3.6 Contact Information

The following persons will represent IMC in the mail tests.

Patrik Fältström
Senior Researcher
Tele2, Sweden

Lars-Johan Liman
Research Engineer
Royal Institute of Technology, Network Operations Centre

When sending test messages, please use the email address:

mime-test@cafax.se
If you don't, your tests will be mixed with our ordinary mail which will make it very difficult for us to handle it in a proper way.

For questions about the tests, discussions about MIME etc, please contact the test leaders using e-mail, addressed

mime-group@cafax.se
To reach all participants in the MIME test, please use the address

mime-participants@cafax.se
Our individual mail addresses are:

Patrik Fältström: paf@swip.net
Lars-Johan Liman: liman@sunet.se

Appendix A - Test form

This test form should be completed and submitted by electronic mail no later than April 25 1996 to the address mime-group@cafax.se.

Name of product:
Version:
Manufactured by:
Tested on platform(s):
Available on platform(s):
Availablility:
Comments:

Form completed by:
Affiliation:
Email:
Phone:
Fax:
Address:

Sales contact:
Affiliation:
Email:
Phone:
Fax:
Address:

Result [Y/N/NA]:

Comment:

M2

Result [Y/N/NA]:

Comment:

Result [Y/N/NA]:

Comment:

M4.1.1

Result [Y/N/NA]:

Comment:

M4.1.2

Result [Y/N/NA]:

Comment:

M4.1.3

Result [Y/N/NA]:

Comment:

What glyphs are displayed for octets in the range 128-255?

M4.1.4

Result [Y/N/NA]:

Comment:

M4.2.1

Result [Y/N/NA]:

Comment:

M4.3.1

Result [Y/N/NA]:

Comment:

M4.3.2

Result [Y/N/NA]:

Comment:

M4.3.3

Result [Y/N/NA]:

Comment:

M4.4.1

Result [Y/N/NA]:

Comment:

Result [Y/N/NA]:

If Yes, how are unrecognized subtypes handled?

Comment:

Result [Y/N/NA]:

If Yes, is the translation table complete for all characters in the range 160-254?

Comment:

Result for ISO-8859-1 [Y/N/NA]:

Comment:

Result for ISO-8859-* [Y/N/NA]:

Comment:

EM1.1.1

Result [Y/N/NA]:

If Yes, with external viewer?

Comment:

EM1.1.2

Result [Y/N/NA]:

If Yes, with external viewer?