摘要

  • RFC 1865 建议用互联网邮件替换既有 EDI 系统之间的传输组件，并把专用 SMTP 直达合作方系统称为有保证的交付；它并未取消双边贸易伙伴协议，也没有把到达写成商业接受。
  • RFC 1767 只为 EDI 对象增加 MIME 封装，不改变 EDI 的语法与语义，也不自带安全机制。RFC 3335 与 RFC 4130 后来加入签名 MDN、原始报文关联和 MIC，仍把处理成败与交易有效性分开。
  • 可审计的顺序应当是：SMTP 接受、邮件系统交付、密码学回执、EDI 处理、业务应用确认、商业决定。前一张回执不能替后一位主体行使权力。

“已送达”究竟是谁说的

假设供应商在 1996 年发出一份标准化采购报文。发送端留下成功的 SMTP 对话，接收方邮件系统也收到了完整数据。此时可以确认的是一次邮件传输，不是买方同意价格、数量与交付条件。

RFC 1865 是一份 Informational FAQ，面向尚不熟悉互联网的 EDI 社群。它提出的迁移并不激进：业务程序与 EDI 翻译系统继续存在，只把通信部分换成互联网模块。文中说，专用 SMTP 连接会把信息直接送到贸易伙伴系统，交付因而得到保证；普通存储转发路径的完整性则取决于中间系统。

关键在“系统”二字。收到邮件的系统可能只是传输代理。之后还要识别合作方、验证签名、去重、解析 X12 或 EDIFACT、执行本地规则，才可能把对象交给采购应用。任何一步失败，都不否定先前的邮件到达，却会阻止商业流程继续。

互联网替换了线路，没有替换协议双方

RFC 1865 把 EDI 定义为标准化商业信息的应用到应用通信，并特意将其与更宽泛的电子商务区分开。后者还包括人与人沟通、资金转移和共享信息资源。这个分类意味着：一个 EDI 对象可以承载商业意图，却不自动完成支付、履约或同意。

文件同时保留双边贸易伙伴协议。原有协议可以把专有邮箱名换成互联网地址，但地址并不创造授权。RFC 1767 对 application/edi-consent 的限制更直接：只有双方明确同意时才使用。

因此，开放网络降低了传输供应商的中心性，却没有消除谁能约束企业、什么算重复订单、哪种确认产生效力、证据保留多久等制度问题。互联网提供共同组件，协议双方仍需定义这些组件的后果。

MIME 说明对象种类，不裁定对象含义

RFC 1767 为 EDI-X12、EDIFACT 和经双方同意的对象规定 MIME 类型。它描述的处理路径从业务程序到 EDI 翻译器，再经 MIME、邮件提交与 SMTP；接收端按相反方向拆封，之后才到 EDI 翻译和业务处理。

该 RFC 明言不改变底层 EDI 的语法或语义，也没有自行提供安全功能。MIME 因而解决“这些字节如何被邮件系统携带、声称属于哪类对象”，不解决“内容是否合规、由谁发出、是否被改动、是否获准进入业务账本”。

这条界线很容易在成功演示后消失。互操作封装让两个系统第一次连通，人们便把连通当作流程完成。RFC 1767 的结构提醒我们，传输组件只是整条商业处理路径中的中段。

一张更强的回执仍然可以报告失败

RFC 3335 为基于 MIME 的安全 EDI 增加了隐私、完整性、真实性以及收发不可否认所需的机制。签名 MDN 可以带回原始 Message-ID、对接收内容计算的 MIC，以及接收方签名。发送方据此关联原报文、比较内容指纹并验证回执来源。

这些字段把“对方说收到了什么”变得更可审计，却仍不是订单接受。RFC 3335 把接收不可否认描述为发送方验证签名回执之后形成的法律事件；这个表述仍依赖适用政策、签名者权限和法律判断，而不是把协议本身变成法院。

RFC 4130 的处理方式更能揭示边界：当协议要求签名回执时，即使内容处理失败，接收方仍应返回签名回执，并在 disposition 中记录失败。回执的价值正在于它能证明一个失败状态，而不是只在成功时亮灯。

反过来，若约定必须返回的签名回执没有出现，RFC 4130 把交易有效性留给贸易伙伴解决，并指出交易很可能不会被视为有效。技术传输为证据提供工具；有效性仍由商业和法律关系决定。

“显示过”也不等于“理解了”

RFC 3798 对通用 MDN 给出了两个克制的限定：接收方可以忽略回执请求；displayed 状态也不能保证内容真的被阅读或理解。自动化 EDI 同样需要这种克制。

最强的可见记录总容易被误当作最终记录：SMTP 成功被说成送达，MDN 被说成处理完成，签名被说成有权承诺，显示被说成理解。事实上，每一次升级都需要新的主体与证据。

至少应区分六层：发送端提交确切对象；邮件系统接受或交付；接收端返回可关联的 disposition 与 MIC；EDI 组件解析并处理；业务应用发出功能确认；具有商业权限的流程接受、拒绝或修改交易。具体系统未必产生六份独立文件，但不能用前一层状态暗中代替后一层权限。

分布式传输与双边治理同时存在

RFC 1865 设想用分布式目录、协作路由和地址解析支撑 EDI，还建议用冗余 ISP 与邮件服务器提高可靠性。它认为 EDI 活动本身不需要一个互联网中央协调者，互联网接入则需要相应管理。

这改变了依赖的形状。专有增值网络不再必然处于每笔交换的中心，合作方可以直接连接，也更容易更换传输路径。但身份映射、加密选择、回执时限、重试规则与争议处理仍写在双边安排里。去中心化的是承载，不是责任。

官方文本能证明到哪里

现有 RFC 足以证明一条有限的历史脉络：RFC 1865 主张把互联网邮件用于 EDI 传输；RFC 1767 规范封装却不碰商业语义；RFC 3335 和 RFC 4130 构造签名、关联与 MIC 证据，同时保留处理结果和交易有效性的独立性；RFC 3798 连“显示即理解”也不肯承诺。RFC 5321 所定义的 SMTP 责任转移同样止于邮件体系。

这些资料没有证明某家公司成功部署、某份订单被接受、某笔款项支付，或某法院如何看待签名 MDN。它们也不能保证所有实现正确。

真正持久的成果不是找到一张万能回执，而是让回执序列可以被拆开检查：谁发出、覆盖什么、何时生效、还缺哪一位主体。只有掌握商业授权的一方依照适用安排作出决定，交易才越过最后门槛。

资料来源