摘要

  • RFC 3459 把 Handling=REQUIRED|OPTIONAL 放在单个 MIME 正文部分上：必需部分不能通过时整封消息失败，可选部分不能通过时则可被静默删除，而不使投递失败。
  • 未标记部分与未来未知值都按 REQUIRED 处理；标记究竟位于签名或加密封装、控制对象还是内部正文，会决定网关可以转换内容还是必须拒绝消息。

部分投递需要发送者预先分配后果

通用互联网邮件通常要求支持 MIME 的接收端保留或暴露每个正文部分，即使本机没有合适的查看器。语音邮件系统面对的物理限制更窄：它可能保存语音和传真，却无法保存文字处理文档或视频。了解终端能力的内容网关因此可能删去终端无法接纳的部分。

2003 年 1 月发布的 RFC 3459 把这种转换变成显式协议。纯文本、RFC Editor 记录、Datatracker 档案、历史、引用资料、后续引用与勘误检索构成可核验记录。它更新了 RFC 3204，把 Handling 参数从 ISUP/QSIG 隧道传输机制中分离出来。

这个参数依附于 Content-Disposition。REQUIRED 表示：若接收系统无法交付该部分，发送者就不认为整封消息已交付，因此一个必需部分失败会让整封消息失败。OPTIONAL 表示：网关可静默删除无法交付的部分；除非另有 REQUIRED 部分失败，否则不得因此返回投递失败。

这两个词不是紧急程度或商业重要性的排名，而是转换权限与失败后果的分配。发送软件可能在用户不知情时附加辅助正文。若发送者并不在乎该附件，把它标为可选，就能避免能力较弱的语音系统因为无关附件而拒绝有用的录音。

删除、失败与通知是三个不同决定

默认规则刻意保守。未标记的部分是 REQUIRED；未来出现而旧实现不认识的 Handling 值也必须按 REQUIRED 处理。旧软件可以按照既有 MIME 规则忽略陌生参数，新网关则在不了解新语义时禁止静默丢失。这是面向演化的失效关闭。RFC 2045提供 MIME 基础，RFC 2421则显示能力受限的语音消息环境。

“关键”本身不等于索要回执。SMTP 投递状态通知仍按 RFC 3461；消息处置通知按 RFC 3798；无法保存或呈现媒体时可使用 RFC 3463 的 5.6.1 状态码。最终投递之前以网关身份工作，可生成 DSN；在投递之后作为用户代理工作，只能生成 MDN；SIP 则通过响应状态报告，包括 RFC 3204 场景中的 415。决定凭据种类的是拓扑与角色，不是 REQUIRED 单独一个词。

密码封装使标记位置成为政策的一部分

最有分量的规则来自 RFC 1847 的多部分安全结构。把整个 multipart/signed 封装标为 REQUIRED，意味着发送者要求原样通过并进行真正的端到端签名验证；终端不能验证时必须拒绝。把签名控制对象标为 REQUIRED，则可由网关先验证再转发，但验证失败仍须拒绝。若签名信息是 OPTIONAL、被签正文是 REQUIRED，网关可为不能验证的终端剥离签名信息，不过在可能时仍强烈建议验证并提示篡改。RFC 2480提供相关处置指导。

加密把管辖边界暴露得更清楚。加密控制对象为 REQUIRED，意味着必须保持端到端加密，不能解密的终端使消息失败。控制对象为 OPTIONAL，则有能力的网关可在终端不能解密时先解密，再转发明文；这个权限来自发送者把标记放在控制对象上的明确选择。若标记藏在加密数据内部，网关必须先解密才能发现它，形成逻辑循环。因此无法看到标记的加密内容继续按 REQUIRED 处理。

这些规则并不证明网关值得信任，只规定已知正文结构与终端能力之后，符合规范的网关可以采取什么行动。RFC 3238关于 OPES 的讨论提供更宽的问责背景：转换需要同意、通知语义与非阻塞约束，而不是不可见的内容改写。

用 Heng Lu 后来的现实层次语言，可以把四张凭据分开：发送者标记、网关能力声明、实际转换、返回结果。运行代码优先则要求比较网关前后的真实 MIME 树，而不是相信一个令人安心的标签。这些是后来的编辑视角，不是对 RFC 作者私人意图的推断。

RFC 3459 将部分投递从隐形事故变成明确的后果分配。可选部分可以消失，投递仍然成功；必需部分即使很小，它的丢失也会使整封消息失败。

来源