摘要

  • RFC 1421 把 PEM 处理放在用户代理或其上层的两个端点，使既有 SMTP 中继无需理解密码学也能搬运邮件。受保护的是封装正文，不是中继沿途添加或改写的全部邮件字段。
  • MIC-CLEAR 与 MIC-ONLY 选择相同的认证和完整性服务，却省去了抵御邮件系统改写的可打印编码。没有 PEM 软件的收件人可以直接阅读正文，但无法因此验证签名。
  • MIC 针对以 ASCII 和 CRLF 表示的规范形式计算。普通换行转换或转发转义也可能造成验证失败。因此，失败结果、变化原因与安全事件定性必须分开保存。

早期安全邮件最棘手的选择，并不是用哪一种密码算法，而是让互联网的哪一部分不必同时升级。

1993 年的电子邮件已经穿过许多彼此并不相同的系统。用户代理使用本机字符集和换行方式写信；消息传输代理接收、转发和投递；网关把内容带进其他消息环境；转发程序可以在原文外再套一层说明。若端到端保护要求每台 SMTP 服务器先理解新的安全格式，它很可能永远等不到普遍部署。

RFC 1421 选择把 Privacy Enhanced Mail 放到边缘。发件人的端点先处理正文，再交给普通邮件系统；收件人的端点在投递之后逆转处理并验证。中间中继不需要成为 PEM 处理器。一个站点可以独立采用，而不必先取得整条路径上所有运营者的同步配合。

这个自由附带清楚的边界。规范明确说，两个 PEM 组件之间由中继添加或转换的字段不受保护。密码学对象位于外层邮件正文之内，并不自动覆盖传输信封、全部追踪字段、地址列表或路由决定。

同一封邮件因此有几条历史：SMTP 交接历史、外层字段改写历史、PEM 对象的表示变化、密钥处理与 MIC 验证，以及人最终看到和采取的动作。把它们压缩成一个“安全”图标，只会让故障失去解释。

公共传输层只负责搬运

RFC 1421 的部署原则很克制。安全措施局限在端点，不要求改造既有 SMTP 协议或服务器。它还明确倾向于增强用户能力，而不是以技术手段阻止用户发送未受 PEM 保护的邮件。规范承认，不能普遍假设用户代理具有足以抵抗本机破坏的可信实现。

这种安排降低了进入门槛。中继运营者继续运行已有设施，端点开发者可以局部实验。但责任没有消失，只是移动了。发件人必须知道收件人是否有能力逆转所选编码或加密；双方还要共享可用的密钥管理方式。

SMTP 接受某个地址并不能证明这种能力。RCPT TO 得到肯定答复，只说明一个传输节点接受了下一步责任；它不说明最终用户代理能解码、解密或验证 PEM。投递关系没有自然升级为安全关系。

规范列出的“不解决事项”同样重要：访问控制、流量流向保密、地址列表准确性、路由控制、收件证明与不可否认、回执关联、重复检测和重放防护。正文签名从未被允许代替这些后续证据。

人读的是文字，MIC 比较的是重建结果

处理从本机形式开始。不同主机可以用不同字符集和行表示。PEM 先把文本转成类似 inter-SMTP 的公共规范形式：ASCII 字符和 CRLF 行结束符。SMTP 自己为句点行使用的透明传输转义不属于这个规范对象。

MIC 以这些规范字节为输入。若选择保密，加密也从同一表示开始。RFC 1421 用 Encode(Encrypt(Canonicalize(Local_Form))) 概括一般出站流程，并按消息类型省略不适用的步骤。接收端反向执行相应步骤，最后才转成本机形式。

这使不同计算机能够互操作，也把证明责任落在一个具体对象上。签名并不认证“意思差不多的那段话”，更不认证屏幕的视觉印象。它认证由规定重建过程生成的字节。两段肉眼相同的文本可能无法产生相同 MIC；传输途中看似不同的文本，也可能在正确去除外层变化后回到相同规范对象。

RFC 822 把邮件描述为字段加可选的 ASCII 行式正文。RFC 821 定义 SMTP 的 DATA 阶段和透明传输规则。PEM 借用了已经广泛实现的行式纪律，但没有声称规范中间形式本身就是一次被观察到的 SMTP 传输。

三种消息为兼容性支付不同成本

ENCRYPTED 同时提供保密、认证和完整性。规范正文被加密，再变成由受限字符集组成的可打印形式，以穿过不同邮件环境。

MIC-ONLY 不隐藏内容的密码学意义，但仍把规范正文编码成可打印表示。这层表示让中继常见的字符变化较难碰到签名对象。收件人必须用 PEM 处理器还原正文并验证 MIC。

MIC-CLEAR 保留与 MIC-ONLY 相同的完整性和认证选择，却去掉可打印编码。收益直接落到人：没有 PEM 软件也能看懂正文。代价也同样直接：看懂的人不能验证随文签名。

规范没有把两种能力混成一个等级。可读性来自清晰表示；可验证性需要密码控制字段、正确密钥路径、相同规范重建和吻合的 MIC。前者为真时，后者仍可处于未知状态。

这还制造了一种社会层面的不对称。人会在证据整理完毕前回应意义。一段清晰的文字可以先形成紧迫感、权威感和行动冲动。兼容性扩大了读者范围，也扩大了“看到”与“证实”之间必须被标出的距离。

验证失败是真实记录，却不是完整判决

MIC-ONLY 的可打印编码用来承受邮件传输系统的一类改写。MIC-CLEAR 为了直接阅读而放弃这层保护。因此，只有在 MTS 未改变正文，或者变化可被识别并在验证前逆转时，MIC 才能可靠验证。

换行是最直接的例子。SMTP 使用 CRLF；接收系统可能在把正文交给 PEM 模块前，已经将其转换成本机行结束形式。验证器必须重新规范化，恢复 inter-SMTP 表示，再计算参考 MIC。

转发又多一层变化。RFC 1421 采用 RFC 934 的封装边界。若 MIC-CLEAR 正文某一行以连字符开头，转发层可能加上可逆的 ，避免它与边界混淆。MIC 在加入这个外层转义之前计算。因此，拥有这个转义的封装层也必须在验证前去除它。

MIC 不吻合证明出现了差异，却没有自动证明差异的原因。攻击者可能改过正文；无恶意的网关也可能做了一次接收端无法辨识或逆转的转换。RFC 1421 因而明确说，MIC-CLEAR 的验证失败不一定代表安全相关事件。

用户界面应保留这种证据结构。报告失败时要说明正在处理哪一种 PEM 消息。对于语法正确但 MIC 失败的消息，不能先把内容当作可信信息直接展示；界面应先说明真实性和完整性无法保证，并取得用户明确确认。它既不能把失败粉饰掉，也不能把未知原因硬写成攻击。

相邻文字不会因为靠近边界而获得签名

PEM 控制字段位于外层正文里的封装头。格式允许边界之外存在不受保护的注释，也允许多个 PEM 对象和嵌套转发。屏幕布局上的相邻，不会扩张 MIC 的覆盖范围。

同样，MIC 有效也不能证明外层地址、实际路线、邮箱投递或真人阅读。它建立的是规范对象、MIC 和某条密钥路径之间的关系。真人作者身份、授权、收件、同意、回复与行动仍需要各自证据。

RFC 1423 把算法、模式和标识符放进另一份文档，让处理语法与可替换的算法表面分离。RFC 1421 和 RFC 1423 如今都被列为 Historic；这种模块边界仍值得研究，1993 年的具体算法却不是今天的安全建议。

MIC-CLEAR 的历史意义，不是宣称旧邮件系统可以无成本获得安全。它准确标出了成本落在哪里：公共中继不必升级，正文可以继续让人阅读；但从签名规范对象到本地显示之间，每一次改写都必须可以归因、可以逆转，或者被明确记录为未知。邮件保持可读，验证者继承了路径历史。