摘要

  • RFC 2157 把映射定义为一个方向的转换，把等价定义为两条映射合在一起实现无损往返。
  • 封装能够为内容保留回到原系统的路径，却不承诺中间邮件系统能够解释、展示或使用它。
  • 因而，成功的一次转换、可信的文件名或相同的字节流都不是完整结论；反向规则、元数据恢复、目标端可用性与最终结果需要分别举证。

等号前面必须先有两支箭头

1998 年 1 月发布的 RFC 2157，负责补齐 MIXER 的正文部分。RFC 2156 处理 X.400 与 RFC 822/MIME 邮件系统之间的总体互通；RFC 2157 则进入正文内部，规定文本、附件、multipart、转发邮件、签名与加密内容如何越过边界。

它在术语表里做了一个至关重要的拆分。“映射”是把 X.400 正文部分变成 MIME 正文，或者反向变换的规则。“等价”不是同义词，而是两条映射的组合：从一边出发，再按对应规则返回，必须实现无损转换。

这意味着，一次演示即便产出了合法对象，也只证明第一支箭头可以走通。另一台网关可能没有反向规则，可能根据收件人能力选择另一条路径，也可能找不到位置放回已经丢掉的参数。解析成功证明语法可接受，不能替往返相等签字。

封装保留的是保管链，不是本地可读性

RFC 2157 定义的第三种关系是封装。它把一个邮件系统的对象包进另一个系统能够携带的正文类型中。规范明确说，中间系统不一定能对内容作出合理解释；保证在于，回到原系统的网关能够无损恢复原格式。

FTBP 与 BP15 封装可以保存 MIME 类型、参数、其他正文头部和规范化后的字节。相反方向上，application/x400-bp 可以让 X.400 扩展正文穿过 MIME。这是一份交给未来解封装器的保管回执，不是对当前用户代理的展示、编辑或执行承诺。

规范还描述了一个与封装处于同一概念层的 BP14“内容传递”方式，并明确称其有损。它删掉 MIME 头部、解除传输编码，只留下字节串；返回时没有规则还原原来的 MIME 类型，只能得到 application/octet-stream。字节还在，类型证据已经不在。

文件名能够触发选择，却不能成为事实本身

当两套邮件世界都在变化时，RFC 2157 没有假装存在一条永远最优的转换。网关可以依据收件人能力、发件人请求、下一跳限制、内容特征或文件名启发式来选路。遇到 BP14、泛化的 FTAM 文件或 application/octet-stream 时，查看扩展名是被允许的操作。

但启发式只属于本地决策。规范在映射 Content-Disposition 的 filename 时，把它作为 FTBP pathname 的一个字符串传递，并用 /etc/passwd 举例提醒接收端采取正常的文件系统安全措施。传入的名字既没有获得路径授权，也没有证明其声称的格式。

application/octet-stream 的两条强制路径更能说明问题。MIXER 合规产品必须同时实现 X.400 的 BilaterallyDefined 与 FTBP Unknown Attachment，并允许配置选择。BP14 会移除 MIME 参数；FTBP 路径保存更多文件元数据，并在两个方向复制正文的字节。

两条路径都可能产出合法结果，但它们维护的事实不同。删除 padding 可能改变最后一个字节的解释；输入的 disposition 被忽略，返回时总会生成 attachment；新的 MIME 字段若在目标正文类型里没有容器，只能丢弃。局部成功不等于全局等价。

等价登记是一对可复现的规则

RFC 2157 的等价登记并不是把两个类型名称写在同一行。登记必须说明 MIME 类型、X.400 正文类型、必要的对象标识符与 ASN.1 结构、转换算法，以及“禁止转换”和“禁止有损转换”如何生效。细节要充分到让另一位实现者独立复现。

登记的目的在于提高网关之间的一致性，但规范同时拒绝更大的推论：网关不必支持全部已登记转换，本地支持的转换也不必全部登记。因此，一条登记记录只能证明公共规则已经被描述；它不能证明某个产品实现了规则、某个实例选择了规则，或收件人的软件真的使用了输出。

核心表也诚实地表现了边界。IA5Text、GeneralText、若干图像、转发邮件和两种通用附件存在明确的对应规则；音频、视频和若干 X.400 正文则指向封装。签名与加密 multipart 要特殊保存，因为为“可读”而改写内部结构，可能直接破坏对象携带的密码学属性。

无损往返也只是证据链的一段

可靠测试先冻结输入正文、头部、参数与嵌套位置，再记录激活的映射表以及收件人能力、发件人指令或启发式输入。第一次转换后，应列出保留、移动和丢弃了什么。随后必须执行被点名的反向映射，并将返回对象同原始对象比较。

即使这一层完全无损，也不能越级声称目标端已经可用。用户代理可能没有处理器；文件名可能触犯本地命名政策；加密对象可能本来就应该保持不透明。送达、安全打开、正确展示和人的理解仍是后续观察。

Lu Heng 的运行代码优先提供了恰当的编辑视角：表格与算法说明可用路径，执行过的两次转换和比对结果才构成运行事实。最小初始规范提醒我们，只把必要的可逆规则放进共同层，不把接收端策略误写成统一命令。现实层级则要求登记、实现、选择、保留字节、可用对象与实际结果各自持有自己的回执。

RFC 2157 最有价值的地方，不是承诺任何内容都能在任何地方得到相同体验，而是让声明变得可检验：一条箭头是映射；两条箭头合起来无损返回才是等价；封装则公开承认，保存与理解可以被刻意分开。

来源