摘要

  • RFC 9787 要求每封收到的邮件只有一个清晰摘要；参与计算的只是连续包围 Crypto Payload 的签名和加密层。
  • 嵌套签名可以有效，游离密文可以成功解密，转发件可以有自己的信封，但这些局部结果都不能替外层邮件升级状态。
  • 回复、附件和历史解密各自带来新的授权与保管问题。客户端必须保存边界，不能让旧标识替新动作背书。

先问标识在陈述哪个对象

一封邮件里可以同时出现外层正文、转发件、签名文档和后来添加的附件。如果界面只亮起一个“已加密”标识，读者很容易把它理解为整页内容都受同一保护。RFC 9787 不允许这种含糊：密码学信封是连续包围 Crypto Payload 的签名与加密层；邮件摘要只汇总这些层。

RFC 3156 与 RFC 8551 分别提供 OpenPGP/MIME 和 S/MIME 结构，RFC 2045 提供 MIME 基础。它们都不会因为两个对象在界面上靠得很近，就让二者共享密码学覆盖。

关键难题并非密码运算失败，反而常常是局部运算成功。内层签名可以验证通过，某个密文片段可以解开；这只能证明那个对象的局部事实，不能证明外层说明文字、列表页脚或相邻附件也被签名或加密。

邮件列表包装改变了收到的对象

RFC 9787 用邮件列表说明边界：作者先签名，列表服务再把已签名实体包起来并追加页脚。原签名可能依然有效，但它相对于订阅者收到的新邮件已经成为游离层。新邮件没有密码学信封，顶层摘要应当是“未保护”。

客户端可以单独展示“内含部分的签名有效”，但不能把它合并成“收到的邮件已签名”。因此，发件人的 Sent 副本与订阅者收到的副本出现不同摘要完全合理；两者已经不是同一个字节对象。嵌套结构也一样：位于 Crypto Payload 内部、却不属于外侧连续信封的签名或加密层，不能进入顶层汇总。

能解密，不等于能拼接

对于游离加密部分，客户端可以帮助用户查看明文，却必须把明文渲染成独立 MIME 子树，不能把它塞回攻击者控制的邻近 HTML，也不能宣称整封邮件已加密。EFAIL 研究与后续的多部件预言机研究解释了这种谨慎：解密能力与安全组合内容是两种不同权限。

非 MIME 的内联 OpenPGP 片段也不能给整封邮件提供验证签名。RFC 9580定义现代 OpenPGP 格式，但格式存在不等于它属于邮件信封。客户端可以把解密结果放进独立区域，却不能在回复时悄悄把明文带入引用。

转发与回复会生成新的证据范围

依据 RFC 5322 与 RFC 6532，转发的 message/rfc822 或 message/global 对象可以拥有自己的密码学信封。它的状态相对于外层邮件是独立的；界面可以显示两个摘要，但必须让用户看得出各自属于哪个对象。

回复不是浏览原文，而是创建新邮件。当原邮件的整体摘要为已加密时，RFC 9787 要求回复也加密，或者不引用原文。如果并非每个收件人都有未过期且可用于加密的证书，客户端应移除引用，除非用户明确选择其他做法。加密邮件回复攻击研究提供了这一风险的研究背景。

游离密文更不对称：用户可为阅读而解密，但外层邮件仍是未加密状态。回复可能需要加密，却不能自动引用那段解出的明文。“我能看见”不是“我可以在新邮件中重新分发”的授权凭证。

附件必须证明自己在载荷里面

RFC 9787 把附件放在同一个 Crypto Payload 内，让正文和附件共享一条完整性边界。若每个附件各用独立信封，它们就可能被移除、替换或重排，而整个组合没有全局完整性；一个标识也无法诚实表达混合状态。

这并不证明客户端里看到的每个附件都受保护。运营人员需要保存原始邮件与解析后的 MIME 树，核对附件是否真正属于载荷。纸夹图标、文件名和下载按钮都不是密码学证据。

证书过期与历史可读性不是一回事

RFC 9787 认为，只要用户仍拥有所需私钥，即使关联证书已过期，客户端也应允许解密。证书过期是轮换与销毁策略的一部分，不会追溯改变旧密文。若证书在加密发生时已经过期，警告才对应那个历史事件。

长期保管还有多种选择：把精确线传副本也加密给发送者；保留发件人版与收件人版；保存明文；或保存会话密钥。每一种都改变字节一致性、暴露面、备份责任和跨客户端可用性，单一标识无法替组织作出这些决定。

RFC 9788处理相邻的邮件头保护问题，不在本文展开。RFC Editor 信息页、Datatracker 与勘误检索证明文档发布状态，并记录本次检查时未列出匹配勘误；它们不证明任何产品已经实现规范。