MIME Conformance ? ================== README.ME+ states: > But anyway, Elm will never be MIME Conformant But lets look what RFC 2049 (Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples) says. Text from RFC 2049 is quoted with ###. ELM ME+ refers to Elm 2.4ME+ PL109 (25). ### A mail user agent that is MIME-conformant MUST: ### (1) Always generate a "MIME-Version: 1.0" header field in ### any message it creates. ELM ME+ do not add MIME-Version: 1.0 on following situation: 1) If Elm ME+ is mailing of form Content-Type: mailform That is not MIME message, but some obsolete format (it is uncluear can be that format invoked) ### (2) 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. ELM ME+ do not recognize these content-transfer-encodings if message have not MIME-Version header and elmrc option "require-mime-version-for-body-encoding" have value ON (default ON). ### 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. ELM ME+ do not encode non-7bit text data, on following situation: 1) If elmrc option "noencoding" have value "pass-8bit" or "pass-binary". Default value is "pass-7bit". Also ELM ME+ do not encode, if to it is told that underlying transport supports 8bit or binary. ### (3) 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. ELM ME+ provides way to save part on message encoded form if content-transfer-encoding is unrecognized. ELM ME+ provides way to save application/octet-stream on decoded form if content-transfer-encoding is recognized and supported. However if metamail is available and elmrc option "metamail" is not value "none", mail with unknown content-transfer-encoding is passed to metamail. So behauviour depends of metamail. ### (4) Recognize and interpret the Content-Type header field, ### and avoid showing users raw data with a Content-Type ### field other than text. ELM ME+ do not recognize these content-type header if message have not MIME-Version header and elmrc option "require-mime-version-for-body-encoding" have value ON (default ON). If metamail is available and elmrc option "metamail" is not value "none", mail with unknown content-type is passed to metamail. So behauviour depends of metamail. 1) Metamail may display raw data If metamail is not used, Elm ME+ provides way to save part with unknown content-type on (content-transfer-encoding) decoded form. Raw data is not shown if external programs are not used for iterpretation of data. Elm ME+ provides limited internal mailcap parser. If mailcap specifies program for content-type and Elm ME+ is able to support line on mailcap, Elm ME+ provides possibility to pass data on (content-transfer-encoding) decoded form to that external program. So on that case it depends on external program. ### 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. Elm ME+ provides is able to send text/plain messages and provides charset -paramater if it is not US-ASCII. ### (5) Ignore any content type parameters whose names they do ### not recognize. Elm ME+ ignores unknown content type paramaters. If metamail is called, behauviour depends of metamail. ### (6) 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." Elm ME+ displays text/plain mail with the character set "US-ASCII." (at least if underlining system supports US-ASCII -- on other hand ELM ME+ do not support environments where that is not true -- systems with some ISO 646 set other than US-ASCII are perhaps exception.) It is possible define or redefine charset names of configuration file. With sufficient broken redefination of charset US-ASCII, it is possible that Elm ME+ is do not have able to display text/plain mail with the character set "US-ASCII." If system supports some other ISO 646 set than US-ASCII, Elm ME+ is not able to print all US-ASCII characters. User have possibility with 'O' (Override charset) command change charset of charset. That may change behauviour. In that case also charset paramater of mail is ignored. ### -- Recognize other character sets at least to the ### extent of being able to inform the user about what ### character set the message uses. Elm ME+ prints character set's name or value of charset parameter if it is unknown or unsupported. ### -- 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. ELME ME+ should be able to work environment, where display and system supports only some ISO 646 sets. On these systems all US-ASCII characters are not printable. If ELM ME+ do no able to display US-ASCII, it probably also do not have able to display ascii parts of these charsets. If elmrc page-known-charsets is OFF (default ON) and metamail is available and elmrc option "metamail" is not value "none", mail with other than system or display charset is passed to metamail. So behauviour depends of metamail on that case. 1) Metamail usually pages text directly to terminal without taking account of charset. If metamail is not used: Assuming that underlining system supports US-ASCII, ELM ME+ usually regognize "ISO-8859-*" character sets and display ascii part of them. There is defination for existing "ISO-8859-*" character sets so that these treated as superset of US-ASCII. It is possible define or redefine charset names of configuration file. With sufficient broken defination or redefination of some ISO-8859-* set that this is not true. If "ISO-8859-*" character sets is not defined and elmrc option "auto-iso-8859" is ON (default ON), given charset is automatically defined to be superset of OS-ASCII. If charset is not defined or is defined to unknown, metamail is available and elmrc option "metamail" is not value "none", mail is passed to metamail. So behauviour depends of metamail on that case. User have possibility with 'O' (Override charset) command change charset of mail. That may change behauviour. In that case also charset paramater of mail is ignored. ### -- 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. Elm ME+ provides limited internal mailcap parser. If mailcap specifies program for content-type and Elm ME+ is able to support line on mailcap, Elm ME+ provides possibility to pass data to external program. But that case perhaps is not unrecognized subtype (if wildcars is not used on mailcap.) If metamail is available and elmrc option "metamail" is not value "none", mail with unrecognized subtypes of text is passed to metamail. So behauviour depends of metamail on that case. Otherwise Elm ME+ handles unrecognized subtypes of text as "text/plain". ### -- Treat material in an unknown character set as if ### it were "application/octet-stream". If metamail is available and elmrc option "metamail" is not value "none", mail with unknown charset is passed to metamail. So behauviour depends of metamail on that case. 1) Metamail usually pages text directly to terminal without taking account of charset. If metamail is not used: ELM ME+ provides way to save text on decoded form. Text is not displayed. User have possibility with 'O' (Override charset) command change charset of mail. That may change behauviour. In that case also charset paramater of mail is ignored. ### Image, audio, and video: ### -- At a minumum provide facilities to treat any ### unrecognized subtypes as if they were ### "application/octet-stream". ELM ME+ provides way to save both unrecognized subtypes of Image, audio, and video and application/octet-stream on decoded form if content-transfer-encoding is recognized and supported. ### 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. Elm ME+ provides way to save subtypes on decoded form if content-transfer-encoding is recognized and supported. ### 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. Elm ME+ recognizes multipart/mixed. Handling of message depends are all subparts supported or not. If subparts are unrecognized and elmrc option "pagemultipart" is OFF (default OFF), metamail is available and elmrc option "metamail" is not value "none", mail on that case is passed to metamail. So behauviour depends of metamail on that case. On some conditions subparts is passed to external program using ELM ME+'s internal mailcap parser. ### -- Recognize the "alternative" subtype, and avoid ### showing the user redundant parts of ### multipart/alternative mail. Elm ME+ recognizes multipart/alternative. Handling of message depends are all or some subparts supported or not. Elm ME+ may either itself show multipart/alternative message or pass it to metamail (and perhaps on some conditions to external program via using it's internal mailcap parser.) When Elm ME+ handles itself multipart/alternative, it shows only one subpart from it. Also if metamail is called, it shows only one subpart from multipart/alternative. ### -- 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. Elm ME+ recognizes multipart/mixed. Handling of message depends are all subparts supported or not. Elm ME+ treats "message/rfc822" as default media type for subtypes instead of "text/plain". Othervise "multipart/digest" is basically handled same way than "multipart/mixed". ### -- Treat any unrecognized subtypes as if they were ### "mixed". If elmrc option "pagemultipart" is OFF (default OFF), metamail is available and elmrc option "metamail" is not value "none", mail on that case is passed to metamail. On some conditions mail is passed to external program via using it's internal mailcap parser. Otherwise mail is treated as "multipart/mixed." ### 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. Elm ME+ recognizes message/rfc822. Handling of message depends are all subparts of recurssive structure supported or not. ### -- Treat any unrecognized subtypes as if they were ### "application/octet-stream". Elm ME+ recognizes multipart/mixed. Handling of message depends are all subparts supported or not. If subparts are unrecognized and elmrc option "pagemultipart" is OFF (default OFF), metamail is available and elmrc option "metamail" is not value "none", mail on that case is passed to metamail. So behauviour depends of metamail on that case. On some conditions subparts is passed to external program using ELM ME+'s internal mailcap parser. ### (7) 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. ELM ME+ provides way to save unrecognized subtypes on decoded form if content-transfer-encoding is recognized and supported. If content-type is unrecognized and elmrc option "pagemultipart" is OFF (default OFF), metamail is available and elmrc option "metamail" is not value "none", mail on that case is passed to metamail. So behauviour depends of metamail on that case. On some conditions part is passed to external program using ELM ME+'s internal mailcap parser. Elm ME+ do not offer the user to name a program to which the decoded data should be passed as input. Except via mailcap mechanism. ### (8) 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. 1) If Elm ME+ is mailing of form Content-Type: mailform it may include other than US-ASCII text and it is non-MIME message (it is uncluear can be that format invoked.) ### 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. (Seems irrelevant.) ### (9) 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. 1) This is not done if Elm ME+ is mailing of form Content-Type: mailform (it is uncluear can be that format invoked.) 2) This is not done, if elmrc option "nohdrencoding" have value ON (default OFF.) Otherwise it is believed, that this is ensured. ### (10) 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. 1) This is not done if X-ELM-OSV: -header includes paramater no-hdr-encoding=1. That paramater and header is added by Elm ME+ on mailing, if elmrc option "nohdrencoding" have value ON (default OFF.) ( Actually header reads as X-ELM-OSV: (Our standard violations) ) 2) That is not done if message have not MIME-Version header and elmrc option "require-mime-version-for-hdr-encoding" have value ON (default OFF.) Otherwise it is believed that this is done. However that requires quite complete parser for mail headers so that "*text" and "*ctext" are regognized correctly and that decoding is not tried on other places. ### The program must be ### able to display the unencoded text if the character set ### is "US-ASCII". It is possible define or redefine charset names of configuration file. With sufficient broken redefination of charset US-ASCII, this is not done. Otherwise this is done. ### 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. There is defination for existing "ISO-8859-*" character sets so that these treated as superset of US-ASCII. It is possible define or redefine charset names of configuration file. With sufficient broken defination or redefination of some ISO-8859-* set that this is not true. If "ISO-8859-*" character sets is not defined and elmrc option "auto-iso-8859" is ON (default ON), given charset is automatically defined to be superset of OS-ASCII.