Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples
obsoletes
Extracted elements (25)
Local newline formats (LF-only, bare CR, CRLF, counted records) are considered encodings of canonical RFC 822/MIME, not canonical form itself. Formats that encode CRLF as LF cannot represent binary MIME content containing LF octets that are not line separators.
The canonical encoding model defines MIME composition as four sequential steps: (1) create body in local form, (2) convert to canonical form, (3) apply transfer encoding, (4) insert into MIME entity with headers. This model is conceptual only — actual implementations may collapse or reorder these steps as long as the resulting messages are equivalent.
The concept of 'MIME-conformance' is defined to promote interoperability: a system meeting these criteria is considered 'safe' to send virtually any properly-marked data to, because it will treat unknown data as undifferentiated binary rather than displaying it as raw text to users.
The multipart/digest default body-part type is 'message/rfc822' rather than 'text/plain' because digest containers are intended to hold encapsulated mail messages; using text/plain as the default would misrepresent their structure.
There is no fixed relationship between a media type and its transfer encoding; the choice between base64 and quoted-printable may appropriately be based on character frequency counts specific to a given body instance, not on the content type alone.
Certain literal strings corrupt messages in some SMTP implementations: a period '.' alone on a line and lines beginning with 'From ' (with a space) are known to be altered. Encoders can prevent this by substituting '=2E' and '=46rom ' respectively in quoted-printable.
CRLF sequence persistence across gateways and user agents cannot be relied on, as conversion between base64 and quoted-printable may conflate CRLFs with line breaks. Implementations must not depend on CRLF sequences being preserved as something other than line breaks.
Lines longer than 76 characters may be wrapped or truncated by some mail transport environments. Applications requiring long lines must differentiate between soft and hard line breaks (e.g., using quoted-printable encoding).
NUL characters (US-ASCII value 0) are problematic in Internet mail and must not be relied upon to be preserved, because many C runtime library routines treat NUL as a terminator.
Only 73 characters are guaranteed to survive all known gateways intact: upper/lowercase A-Z and a-z, digits 0-9, and eleven punctuation characters. Base64 encoding confines itself to this invariant set and is thus maximally portable.
Trailing whitespace characters (SPACE, TAB) on a line may be discarded or padded by transport agents; their persistence cannot be relied on. TAB characters may also be converted to variable numbers of spaces in some environments.
A conformant agent MUST recognize and interpret the Content-Type header field, avoid showing users raw data with a non-text Content-Type, and be capable of sending at least text/plain messages with an explicit charset parameter when the character set is not US-ASCII.
A conformant agent must recognize the 'multipart/digest' subtype and use 'message/rfc822' (not 'text/plain') as the default media type for body parts inside multipart/digest entities. Unrecognized multipart subtypes must be treated as 'multipart/mixed'.
A MIME-conformant agent MUST recognize the Content-Transfer-Encoding header field and decode all data encoded with quoted-printable or base64. The identity encodings 7bit, 8bit, and binary must also be recognized. Non-7bit data sent without encoding must be labelled 8bit or binary, and if the underlying transport (e.g., SMTP) does not support these, the data must be encoded and labelled with quoted-printable or base64.
A MIME-conformant mail user agent MUST always generate a 'MIME-Version: 1.0' header field in any message it creates.
An implementation MUST treat any unrecognized Content-Transfer-Encoding as if the body had a Content-Type of 'application/octet-stream', regardless of whether the Content-Type itself is recognized.
Conformant agents MUST ignore any content-type parameters whose names they do not recognize, ensuring forward compatibility with future MIME parameter extensions.
Conformant agents must recognize and display 'message/rfc822' encapsulations in a way that preserves recursive structure, displaying or offering to display the encapsulated data according to its own media type. Unrecognized message subtypes must be treated as 'application/octet-stream'.
Conformant agents must recognize the 'multipart/alternative' subtype and avoid showing the user redundant parts. They must also recognize 'multipart/mixed' and display all body parts individually.
Conforming user agents must be able to distinguish encoded-words from 'text', 'ctext', or 'word' tokens wherever they appear in message headers, and MUST support both the 'B' (base64) and 'Q' (quoted-printable) encodings for any character set they support.
Conforming user agents must ensure that any string within a '*text' or '*ctext' that begins with '=?' and ends with '?=' is a valid encoded-word. Similarly, any 'word' within a 'phrase' matching that pattern must be a valid encoded-word.
Conforming user agents MUST include proper MIME labelling when sending anything other than plain US-ASCII text. Sending non-US-ASCII text without a MIME-Version field is strongly discouraged as it impedes interoperability.
Conforming user agents MUST NOT send non-MIME messages containing anything other than US-ASCII text. If non-standard support for non-US-ASCII in non-MIME messages is provided, it MUST apply only to received messages.
Upon encountering any unrecognized Content-Type field, an implementation MUST treat it as 'application/octet-stream' with no parameter sub-arguments, offering the user options such as saving the decoded data to a file or passing it to a named program.
Security issues applicable to MIME are discussed in RFC 2046 (MIME Part Two: Media Types); this document (RFC 2049) does not independently define security requirements beyond that reference.