Appendix: MIME Conformance

This appendix describes how well MHonArc implements MIME-conformance as defined in RFC 2049: (MIME) Part Five: Conformance Criteria and Examples. Also, additional MIME-related features are summarized.

MIME-Conformance
Other Stuff Supported

MIME-Conformance

MIME-conformance is defined in section 2 of RFC 2049: (MIME) Part Five: Conformance Criteria and Examples. Following is the text extracted from section 2 of RFC 2049 with annotations added on how MHonArc conforms to each criteria listed. It should be noted that the criteria listed in RFC 2049 is geared towards interactive MUAs; therefore, some criteria may not be applicable to MHonArc.

NOTE

All notes about conformance is based upon the default MIME-related resource settings: MIMEFILTERS, CHARSETCONVERTERS, MIMEARGS

Always generate a "MIME-Version: 1.0" header field in any message it creates.

Not applicable.
Recognize the Content-Transfer-Encoding header field and decode all received data encoded by either quoted-printable or base64 implementations. The identity transformations 7bit, 8bit, and binary must also be recognized.

Base64, quoted-printable, 7bit, 8bit, and binary are supported. Also, uuencode is supported: uuencode, x-uuencode, and x-uue.

Any non-7bit data that is sent without encoding must be properly labelled with a content-transfer-encoding of 8bit or binary, as appropriate. If the underlying transport does not support 8bit or binary (as SMTP [RFC-821] does not), the sender is required to both encode and label data using an appropriate Content-Transfer-Encoding such as quoted-printable or base64.

Not applicable.

Must treat any unrecognized Content-Transfer-Encoding as if it had a Content-Type of "application/octet-stream", regardless of whether or not the actual Content-Type is recognized.

Currently, MHonArc will still call the registered content-type filter for the specified Content-Type, but the $isdecoded will be set to a false value. With the default set of filters, the $isdecoded flag is ignored. Therefore, behavior could be considered undefined when MHonArc process a message with an unrecognized Content-Transfer-Encoding.

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

MHonArc conforms to the first sentence of the paragraph The second sentence is not applicable.
Ignore any content type parameters whose names they do not recognize.

Yes.

Explicitly handle the following media type values, to at least the following extents:

Text:

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

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

Not really applicable. Warnings are generated during processing if a character set is encountered that is not recognized.
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 1-127.

Yes.
For unrecognized subtypes in a known character set, show or offer to show the user the "raw" version of the data after conversion of the content from canonical form to local form.

MHonArc will treat the data as text/plain and convert.

Treat material in an unknown character set as if it were "application/octet-stream".

No. A warning is generated for unknown character sets. The data will be shown in raw form, with HTML special characters converted to entity references. This behavior is the default because some MUAs are known to give incorrect charset parameters.

Image, audio, and video:

At a minumum provide facilities to treat any unrecognized subtypes as if they were "application/octet-stream".

All image, audio, and video types are saved to an external file with a link to the file created in the HTML. For applicable image types, they are inlined unless the image has an attachment content-disposition.

Application:

Offer the ability to remove either of the quoted-printable or base64 encodings defined in this document if they were used and put the resulting information in a user file.

Most application types are decoded and saved to an external file with a link to the file created in the HTML. Some application types can be converted directly to HTML.

Multipart:

Recognize the 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.

Yes. Each part is automatically processed according to its media-type.
Recognize the "alternative" subtype, and avoid showing the user redundant parts of multipart/alternative mail.

Yes.
Recognize the "multipart/digest" subtype, specifically using "message/rfc822" rather than "text/plain" as the default media type for body parts inside "multipart/digest" entities.

Yes.
Treat any unrecognized subtypes as if they were "mixed".

Yes.

Message:

Recognize and display at least the RFC822 message encapsulation (message/rfc822) in such a way as to preserve any recursive structure, that is, displaying or offering to display the encapsulated data in accordance with its media type.

Yes.
Treat any unrecognized subtypes as if they were "application/octet-stream".

Yes.

Upon encountering any unrecognized Content-Type field, an implementation must treat it as if it had a media type of "application/octet-stream" with no parameter sub-arguments. How such data are handled is up to an implementation, but likely options for handling such unrecognized data include offering the user to write it into a file (decoded from its mail transport format) or offering the user to name a program to which the decoded data should be passed as input.

Yes. The data is passed to the m2h_external::filter to be saved to an external file.
Conformant user agents are required, if they provide non-standard support for non-MIME messages employing character sets other than US-ASCII, to do so on received messages only. Conforming user agents must not send non-MIME messages containing anything other than US-ASCII text.

In particular, the use of non-US-ASCII text in mail messages without a MIME-Version field is strongly discouraged as it impedes interoperability when sending messages between regions with different localization conventions. Conforming user agents MUST include proper MIME labelling when sending anything other than plain text in the US-ASCII character set.

The m2h_text_plain::filter supports an option to specify what character set to use if no character set is specified. By default, ISO-8859-1 is assumed.

In addition, non-MIME user agents should be upgraded if at all possible to include appropriate MIME header information in the messages they send even if nothing else in MIME is supported. This upgrade will have little, if any, effect on non-MIME recipients and will aid MIME in correctly displaying such messages. It also provides a smooth transition path to eventual adoption of other MIME capabilities.

Not applicable.
Conforming user agents must ensure that any string of non-white-space printable US-ASCII characters within a "*text" or "*ctext" that begins with "=?" and ends with "?=" be a valid encoded-word. ("begins" means: At the start of the field-body or immediately following linear-white-space; "ends" means: At the end of the field-body or immediately preceding linear-white-space.) In addition, any "word" within a "phrase" that begins with "=?" and ends with "?=" must be a valid encoded-word.

Yes.

Conforming user agents must be able to distinguish encoded-words from "text", "ctext", or "word"s, according to the rules in section 4, anytime they appear in appropriate places in message headers. It must support both the "B" and "Q" encodings for any character set which it supports. The program must be able to display the unencoded text if the character set is "US-ASCII". For the ISO-8859-* character sets, the mail reading program must at least be able to display the characters which are also in the US-ASCII set.

MHonArc supports non-ASCII encoding of text in message headers, including the "B" and "Q" encodings. By default, US-ASCII, ISO-8859-[1-10], and ISO-2022-JP are supported. For encoded words with an unrecognized character set, the word is left in encoded form. Additional character set support can be added via the CHARSETCONVERTERS resource.

Other Stuff Supported

The following lists other MIME-related features supported by MHonArc:

Support for uuencoding as a Content-Transfer-Encoding.
Support for many media-types (including the ability to extend that support). For a complete list, along with more information, see the MIMEFILTERS resource. Note, many media-types cannot be directly converted into HTML. For these types, they are saved to a separate file with a link to the file inserted in the converted HTML message data.
Support for multipart/related by allowing filters to access other message parts via content-ids.
Support for cid: URLs in text/html data. The provides support for things like MHTML: MIME E-mail Encapsulation of Aggregate Documents, RFC 2110.
Support for RFC 2369, The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields. The URLs in list header fields will be converted into hypertext links.

$Date: 2001/12/24 14:38:07 $