摘要

  • RFC 1344 区分了同质邮件环境中的传输服务与跨越异质环境的网关。中继若改动正文，就不能继续把自己描述为透明搬运者。
  • MIME 让退信可以完整封装原邮件，也能拆分大对象、搬移外部正文或用编码保护字符。保护传输形式与替换内容表示并不是同一种行为。
  • 转换痕迹和发件人禁令只解决部分授权问题。后来的 MIXER 与投递状态通知进一步保留损失、原始与最终地址、通用与原生错误码，使不同现实层不再被一个“已转发”吞并。

改一个像素，承担的就不再是运输责任

MIME 的一项关键价值，是让图片、音频和复合正文继续搭乘既有邮件传输系统。中间服务器不必理解一幅图表达什么，也不必重写每个正文部分；它可以接收字节，再把字节交给下一跳。

RFC 1344 正是在这项兼容性上画出界线。传输服务负责在大致同质的邮件环境中移动消息，通常不应改变内容。网关连接差异显著的环境，转换有时不可避免。两者的区别不取决于机器挂着什么名字，而取决于它有没有替别人改写对象。

原文设想一条昂贵的洲际链路。SMTP relay 也许想把 GIF 转成更小的 JPEG，以减少带宽成本。这个动机并非虚假，但动作同时选择了新的表示，假定收件端支持它，并可能舍弃细节。RFC 没有让 relay 以“服务优化”为由保持中立身份；它要求这类中继重新界定为 gateway。

角色名称在这里是一条责任边界。中继可以证明自己取得和转交了托管。网关必须解释为何改变、改变了什么，以及这种变化在哪一步发生。

退信系统不懂图片，也可以完整归还图片

纯文本时代的退信往往在说明之后附上原邮件片段。面对图片或音频，把原始字节当文本展示既不可读，也破坏了失败对象的边界。

RFC 1344 用 MIME 把两件事拆开：multipart 的一部分写给人看，说明拒绝原因；另一部分以 message/rfc822 封装整封被拒邮件。传输程序不必解析其中的图像，只需正确保存并包装它。退信原因与失败对象因此可以同时存在，而不是互相覆盖。

但原文也明确限制了自己的权威。这只是许多可行格式之一，拒绝和确认仍需要另行开展 IETF 标准化工作。示例证明“可以这样保留证据”，并不证明所有邮件系统已经能互操作。

RFC 3464 后来把 delivery status notification 做成机器可处理的结构。它分别记录整封消息与每个收件人的结果，在发生转发或地址改写时保留 original recipient 与 final recipient，还允许通用状态码和外部邮件系统的原生错误码并存。通用码便于跨系统判断，原生码保留复现故障所需的现场语义。

编码是在保护对象，格式转换是在选择对象

RFC 1344 罗列的网关动作，不能都放进“转换成功”这个桶里。

ASCII 到 EBCDIC 的边界可能损坏某些字符。对正文使用 base64 或 quoted-printable，是先改变运输外形，使接收方解码后通常能恢复原始字节。这种操作的目标是抵抗有损信道，而不是替用户挑选新内容。

GIF 与 JPEG 之间的转换不同。更小的 JPEG 能减轻远距离线路压力，GIF 也可能更适合当时某些终端。可转换程序存在，不代表收件端必然支持新格式，更不代表像素、细节和用途等价。网关日志最多证明算法输出了一个新文件。

message/partial 面对的是尺寸限制。发送侧或接收侧网关可以拆开或重组大消息，但上游未必知道下游真正的容量。一次“聪明猜测”可能产生若干格式正确的分片，却不能证明它们都抵达并被重组。

message/external-body 则把大数据放在邮件外，只发送取得它的方法。跨越慢速边界时，网关可以先取回数据、把它复制到离收件人更近的位置，或改写地址。RFC 提出的谨慎版本，是同时给出原始引用和展开后的副本。这样，本地便利没有删除出处，收件人日后仍可回到原位置寻找更新版本。

转换痕迹承认了机器的主动性

RFC 1344 强烈建议格式转换后加入 trace information，可能写入 Received。这条记录不是装饰。原内容与现内容不同时，路径必须留下一个行动者：是哪一台网关、在哪个边界作出了选择。

文中还建议使用 Content-Conversion: prohibited 或 permitted 表达发件人意愿。这是 Informational RFC 的建议，不是已经普遍部署、必然被遵守的标准字段。更重要的是，缺省时许多网关可能假定允许，而且拥有表达权的是 sender，不是每一位 recipient。

这项不对称让控制面浮现出来。网关看到链路价格、附近存储和自己的转换器；发件人知道原作；收件人知道自己能否打开、愿意接受多少损失。三者的知识和利益不在同一处。留痕只能让网关的决定可见，不能凭空产生另外两方的同意。

RFC 2156 的 MIXER 后来处理 X.400 与 RFC 822/MIME 映射时，记录了更细的状态：conversion prohibited、conversion with loss prohibited、不支持媒体、执行了有损转换、转换失败。网关还要添加表明转换的 trace。其“支持”概念把语义对应和无重大信息损失纳入判断。它没有证明 RFC 1344 的建议全被采用，却证明真实网关需要的状态远多于“已转发”。

真实的转换记录仍可能通向错误结局

一封邮件的实际链条至少包括：原始内容、接受托管、发现边界限制、选择动作、生成新表示、下游接受、逐收件人投递、软件呈现，以及人的阅读或使用。每一步都可留下真实记录，但任何一步都不能自动代表下一步。

转换器可能正确生成一个收件端打不开的文件；SMTP 会话可能成功，随后某个邮箱投递失败；本地副本可能容易取得，却已经过期；DSN 可能准确描述投递，却不知道人是否看见。

RFC 1344 明确说没有讨论安全问题，因此不能被改写成一次攻击、泄露或恶意网关事件。它留下的是更基本的制度判断：改变他人对象的表示，就是在行使权力。诚实的系统既记录这项权力，也限制这份记录只能证明它实际看到的那一层。

来源

这些来源证明文档状态、所述机制与后来的证据结构；不证明特定部署、攻击、采用率、普遍转换政策、等价呈现、最终送达、收件人同意或人的结果。