摘要

  • RFC 2156 明确规定，MIXER 符合性属于一台已经实例化的 X.400/RFC 822-MIME 网关，而不只是能够按规范配置的软件实现。
  • 原本服务封闭用户群的局部网关，会因分发列表扩展和非本域 X.400 用户的邮件交换进入全局场景；机器没有换，运行责任却扩大了。
  • 完整证据必须连接产品能力、实例配置、MCGAM 数据、每次跨网关转换、服务保留情况和最终投递结果，不能用一次成功转换代替整条链。

边界不是在源代码里，而是在安装之后

产品测试可以证明某个转换函数存在；采购清单可以写“支持 MIXER”；实验室也能让一封邮件成功往返一次。真正困难的问题是：生产中接到这封邮件的实例，是否启用了全局场景所需的全部功能，并在实际路径上使用了正确的映射资料？

1998 年 1 月发布的 RFC 2156 把 X.400 与 RFC 822/MIME 之间的转换写成一套跨服务层的规则。它预期不止一台网关，并把一致行为视为多网关互通的条件。规范区分两个场景：全局场景连接两张邮件网络，消息可能多次跨越边界；局部场景只把封闭用户群接到全球邮件网络，可由连通性或授权策略维持边界。

局部实现成本较低，但局部不一定稳定。RFC 点名 ADMD 提供的网关：它最初只面向本地客户，后来因为分发列表以及同非客户 X.400 用户的往来，实际上开始承担全局路径。拓扑和收件人集合改变了实例的角色，根本不需要更换软件。

因此 RFC 的结论非常精确：MIXER 的符合性适用于网关的一个实例，而不只是一个实现。实现能够以符合方式运行当然重要，但“能够”没有证明生产实例“正在这样运行”。

分发列表把一次转换变成一连串决定

分发列表会突破简单的边界想象。一个 X.400 用户把信寄给 RFC 822 系统上的列表，列表展开后可能引入第三方地址、新收件人和返回路径，再把邮件送回 X.400。入口处的一次转换于是变成多个运营者、多个映射表和多种配置共同参与的过程。

RFC 2156 说，多次映射在分发列表场景尤其必要。它追求对称和可逆，以免地址无谓地重复编码，并让回复能够沿路径返回。但规范也警告，多次跨越通常把服务降到最低共同分母，大致相当于 RFC 822 所提供的服务。没有标准 RFC 822 对应项的 X.400 服务，不应被假定能在 X.400→RFC 822→X.400 的往返中保留。

可逆只证明可以构造回程地址，不证明重要性、通知语义、trace、转换禁止标记、正文含义和收件人动作全部未变。规范又把单台网关内部的递归映射与多台网关之间的 source route 分开：前者共享一个决定环境，后者会碰到独立维护的 MCGAM、X.400 版本、SMTP 选项和正文转换策略。

Appendix G 要求的是实例记录

Appendix G 规定，只要缺少必选功能，就不能声称符合 MIXER。网关必须遵循字段格式、支持 MCGAM、实现 trace 映射、能够访问三类全局映射、按 RFC 2157 处理正文；生成 MIME 时还要遵循 RFC 2045。它还必须说明支持哪些互联网邮件传输协议、哪些 X.400 版本，以及用表、X.500 或 DNS 中的哪些机制访问全局映射。支持 SMTP 时，附录 A 就成为必选要求。

这些都是运行实例的事实。产品可能带有 DNS 和 X.500 查询模块，生产进程却指向过期表；代码可能实现 trace，局部配置却没有在被审计的路径上保存它。

配套的 RFC 2157 把区分写得更清楚：产品只要可以配置使用某功能，该功能就算“已实现”；规范并不限制产品必须以那种方式配置。这正说明产品功能收据只是第一张收据。RFC 2156 仍要求观察当前网关实例是否按全局 MIXER 方式工作。

RFC 2157 允许网关根据收件人能力、发件人请求、内容启发式判断和下一跳限制作出选择。未知正文可以拒绝、标记丢弃或封装，而符合规范的产品必须能配置为封装。两台同样有能力的产品，因配置不同仍会给出看似矛盾的服务。

一次成功转换只能证明一次转换

RFC 2156 在讨论单次跨越时，把“支持服务”定义得很严格：语义要对应，不能有显著信息损失，还要执行该服务要求的动作。输出语法正确却丢了报告动作，就不能借用“支持”这个更强的词。

可靠审计应逐层保存：产品版本与必选能力；运行实例和启用选项；MCGAM 来源、版本、哈希与实际查询结果；每次列表展开和边界跨越；每次转换的输入输出指纹、所选规则、封装或丢失内容与 trace；最后再评估服务语义。目标系统接收、邮箱投递、渲染成功和人类阅读仍是后续独立结果。

Lu Heng 的 Running-Code Primacy 在这里是公开说明的编辑视角，不是 RFC 条款：标准文本和具备能力的二进制描述的是可能性，运行配置与实际路径才描述事实。Minimum Initial Specification 要求把每个可本地验证的断言保持最小；Reality Layers 则提醒我们，不要让符合性标签这种符号保证替代可执行证据。

RFC 2156 没有证明哪家厂商部署失败，也没有统计 MIXER 的普及率。它留下的是更有用的历史界线：举证责任不止是软件“能做什么”，而是实际承载邮件的实例，在这条路径上“配置并执行了什么”。

来源