Summary

  • RFC 1421 placed Privacy Enhanced Mail at the endpoints so existing SMTP relays could carry it without understanding the cryptography. Its protection covered the encapsulated body, not every header or transformation visible in the wider mail transaction.
  • MIC-CLEAR retained authentication and integrity while omitting the printable encoding used to protect MIC-ONLY text from relay changes. A recipient without PEM software could read the body but could not validate its signature.
  • Because the MIC was calculated over canonical ASCII lines ending in CRLF, benign changes to the transit or local representation could make validation fail. The failure was evidence; the cause and security significance remained separate judgments.

The most interesting part of early secure mail was not the cipher. It was the decision about where ordinary mail should be allowed to remain ordinary.

By February 1993, Internet mail was not one clean end-to-end machine. User agents prepared text. Message Transfer Agents accepted, relayed and delivered it. Gateways crossed into other environments. Hosts disagreed about character sets and line endings. Forwarders could wrap one message inside another. An integrity mechanism had to survive this ecology without first replacing it.

RFC 1421 answered by placing Privacy Enhanced Mail processing at the User Agent level or above. The originator transformed the body before submitting it. The recipient reversed and checked the transformation after delivery. Intermediate SMTP relays did not have to know that the text was protected. A site could adopt PEM without waiting for every server on the route to be upgraded.

That decision was deliberately narrow. The RFC said the privacy enhancements did not apply to message fields added or transformed by relays between the PEM components. If a relay added a trace field, rewrote an outer header or changed routing information, that activity remained outside the protected object. The mail system carried an encapsulated security object; the security object did not absorb the entire mail system.

This distinction matters because a delivered message has several histories. SMTP has a transaction history. The outer message has a header history. The enclosed PEM object has a transformation history. The recipient has a validation history. A single “secure mail” badge would erase all four.

The common route stayed thin

RFC 1421's deployment principle was unusually pragmatic. Security measures were confined to endpoints instead of being integrated into every SMTP server. The standard tried to enhance user capabilities rather than prevent users from sending unprotected messages. It acknowledged that trusted user-agent implementations could not be assumed everywhere and that enforcement was less realistic than an optional service.

The incentive structure followed from that placement. Relay operators kept their existing transport machinery. Endpoint implementers gained the freedom to experiment and deploy locally. Senders and recipients, however, inherited the work of agreeing on key management, supported transformations and recipient capability.

The sender could not infer capability from the fact that an address existed or that SMTP accepted a recipient. Before encoding or encrypting a body, the originator needed to know whether the intended recipient could perform the inverse operation. Transport acceptance was evidence of one handoff, not evidence of a PEM-capable endpoint.

The standard also listed what it did not solve: access control, traffic-flow confidentiality, address-list accuracy, routing control, assurance or non-deniability of receipt, acknowledgement correlation, duplicate detection and replay prevention. These exclusions were not footnotes to be filled with optimism. They were the boundary of the record.

The signature covered a canonical object, not whatever appeared on screen

The processing pipeline began with local form. One host might store lines one way, another differently. RFC 1421 converted that local text into a canonical form modeled on the inter-SMTP representation: ASCII characters and CRLF line endings. It did not include SMTP dot stuffing in this canonical object.

The canonical bytes were the input to the Message Integrity Check. Encryption, when selected, also worked from that representation. For the general case, the RFC summarized the outbound composition as Encode(Encrypt(Canonicalize(Local_Form))), with inapplicable stages omitted for particular message types. The receiver performed the corresponding inverse stages and only then converted the canonical text into its local representation.

This sequence made heterogeneous computers interoperable, but it also assigned responsibility. A MIC did not authenticate an abstract paragraph or a reader's visual impression. It authenticated the bytes produced by a specified reconstruction. If sender and receiver did not reach the same canonical object, the arithmetic could not rescue their semantic agreement.

RFC 822 had defined a message as header fields plus an optional ASCII, line-oriented body. RFC 821 supplied SMTP's DATA transaction and transparency rules. PEM borrowed that familiar line discipline because it was widely implemented, not because an intermediate canonical result itself travelled as an SMTP transaction. The boundary between model and carrier remained explicit.

Three message types made three different bargains

ENCRYPTED provided confidentiality as well as the authentication and integrity services. Its canonical body was encrypted and then represented in a restricted printable alphabet suitable for varied mail paths.

MIC-ONLY omitted confidentiality. Readers did not receive ordinary visible prose; the canonical form was still converted into printable encoding so relay transformations would not disturb the signed text. A PEM implementation decoded it and validated the MIC before presenting the recovered body.

MIC-CLEAR selected the same integrity and authentication services as MIC-ONLY, but omitted that printable encoding step. This was the compatibility opening. A recipient without PEM software could read the text directly. The same recipient could not validate the signature.

The design refused to pretend those two abilities were one. Readability was a property of the visible representation. Verification required the cryptographic controls, the appropriate key path, the correct canonical reconstruction and a matching MIC.

It also exposed a social asymmetry. Humans respond to meaning before systems finish provenance checks. A clear message can persuade, alarm or instruct the moment it appears. The very feature that widened access made it possible for visible content to acquire authority before its signature had any authority at all.

A mail-system rewrite became an evidence question

Printable encoding protected MIC-ONLY text from a class of transformations within the Message Transfer System. MIC-CLEAR chose readability instead. Its MIC could be validated only if the MTS had not modified the text, or if the modifications could be identified and inverted before validation.

Line endings were the immediate case. SMTP used CRLF. A receiving system might convert those delimiters into its native form before handing the body to the PEM module. The verifier then had to recanonicalize the delivered text to reconstruct the inter-SMTP representation and compute a reference MIC.

Forwarding introduced another layer. RFC 1421 adopted RFC 934 encapsulation boundaries. If a MIC-CLEAR line began with a dash and could be mistaken for a boundary, a forwarder might prepend . The MIC was calculated before that outer escape was added. Correct validation therefore required the wrapper's reversible change to be removed by the layer that owned it.

This is where a failed MIC stopped being a complete verdict. The RFC said that a MIC-CLEAR failure did not necessarily signify a security-relevant event. It might reflect malicious alteration. It might also reflect a benign transformation that the receiving side could not determine or reverse. The failed comparison was real; its cause remained open.

The recommended interface followed the evidence. A PEM implementation should tell the user what kind of message was being processed when reporting the failure. Elsewhere, the RFC warned that syntactically valid messages with failed MICs should not simply be displayed as trustworthy: the recipient should see an authenticity and integrity warning and affirmatively choose whether to proceed. The user needed the failure, the message type and the uncertainty—not a green or red fiction.

The wrapper did not expand the signature by proximity

PEM control fields lived in an encapsulated header inside the outer message body. The format allowed unprotected annotations outside the PEM boundaries. It also allowed multiple protected objects and nested forwarding. A paragraph sitting beside a signed object did not become signed because it looked attached.

Likewise, a valid MIC did not validate the outer address list, trace fields or delivery route. RFC 1421's own exclusions made that plain. The originator claim, body integrity, SMTP recipient, eventual mailbox, human reader and acknowledgement remained different relationships.

RFC 1423 placed algorithms, modes and identifiers in a separate specification. That modular split allowed the processing grammar to cite a replaceable algorithm surface. Both documents are now Historic. The separation is still informative; the specific 1993 algorithm suite is not a modern security recommendation.

The deeper historical contribution of MIC-CLEAR was therefore not a promise that old mail could become secure without friction. It was a precise account of the friction. Legacy relays could remain unchanged. Clear text could remain accessible. But every transformation between the signed canonical object and the reader's local view had to remain visible enough to reverse or explain.

The system preserved adoption by declining to demand universal change. In exchange, the verifier inherited the burden of history.