The "MIC-CLEAR" specifier represents a PEM message with the same security service selection as for a MIC-ONLY message. The set of encapsulated header fields required in a MIC-CLEAR message is the same as that required for a MIC-ONLY message.
MIC-CLEAR message processing omits the encoding step defined in Section 4.3.2.4 of this RFC to protect a message's encapsulated text against modifications within the MTS. As a result, a MIC-CLEAR message's text can be read by recipients lacking access to PEM software, even though such recipients cannot validate the message's signature. The canonical encoding discussed in Section 4.3.2.2 is performed, so interoperation among sites with different native character sets and line representations is not precluded so long as those native formats are unambiguously translatable to and from the canonical form. (Such interoperability is feasible only for those characters which are included in the canonical representation set.)
Omission of the printable encoding step implies that MIC-CLEAR message MICs will be validatable only in environments where the MTS does not modify messages in transit, or where the modifications performed can be determined and inverted before MIC validation processing. Failed MIC validation on a MIC-CLEAR message does not, therefore, necessarily signify a security-relevant event; as a result, it is recommended that PEM implementations reflect to their users (in a suitable local fashion) the type of PEM message being processed when reporting a MIC validation failure.
A case of particular relevance arises for inbound SMTP processing on systems which delimit text lines with local native representations other than the SMTP-conventional <CR><LF>. When mail is delivered to a UA on such a system and presented for PEM processing, the <CR><LF> has already been translated to local form. In order to validate a MIC-CLEAR message's MIC in this situation, the PEM module must recanonicalize the incoming message in order to determine the inter- SMTP representation of the canonically encoded message (as defined in Section 4.3.2.2 of this RFC), and must compute the reference MIC based on that representation.