摘要

  • RFC 2017 为 MIME message/external-body 增加 URL 访问类型：邮件携带的是取回说明，所指对象仍在邮件之外。
  • 引号、折行与百分号编码解决的是地址如何穿过邮件头，并不能证明地址可达、对象不变、来源可信或取回已获授权。
  • 类型一致、明确同意与 Content-MD5 完整性校验是三道独立控制；官方记录没有给出广泛部署或实际成效的证据。

RFC 2017 只有几页，却抓住了网络系统里一种经常被误读的权力转移：发送者没有把对象交给收件人，而是交给收件人的软件一项待执行的动作。邮件里出现了地址，真正的数据仍留在另一台系统、另一种协议乃至另一个信任边界之后。

这项标准给既有的 message/external-body 增加了 URL 访问类型。此前 RFC 1521 已列出 FTP、匿名 FTP、TFTP、本地文件和邮件服务器等取回办法。RFC 2017 的新增项允许外层参数携带 URL，内层实体头则声明预期取回对象的媒体类型。那个对象本身不随邮件到达。

规范首先限制“什么算地址”。只有能直接取回对象的 URL 才能使用。它特意排除了 mailto：后者指向邮箱和发送动作，不是可直接取得的 external-body 数据。两者都可能符合 URL 的外观，但操作语义不同。格式正确，不等于满足本次取回承诺。

接下来是传输。邮件头并不适合任意长字符串。RFC 2017 把 URL 参数定义为一串置于引号中的 URL-word，每段最长 40 个字符，中间可由线性空白分隔。接收端去掉引号与这些空白，重组出原地址。切分之前，未编码的空格、控制字符、引号、反斜杠和高位字节，要按当时 RFC 1738 的规则编码。

这是一套表示法，不是一张收据。地址即使重组无误，也可能无法解析、需要凭据、经过重定向，或在不同时间返回不同字节。规范没有把“能传地址”偷换成“已收对象”。

取回之前作出的声明

内层实体头预先声明媒体类型。RFC 2017 要求应用最终使用的取回版本与该声明一致，因为应用可能已经做出不可逆的选择：挑选解码器、分配处理程序、打开查看器。若等到处理开始后才发现实际对象与声明不符，边界已经越过。

URL 形式的“幻影正文”不被使用，应当留空。这个空白不是缺失字段，而是语义本身：消息没有附带一份微型对象。它也说明 URL 形式与 mail-server 形式不同；后者会在幻影正文里放置发给服务器的命令。

一个月后发布并取代 RFC 1521 的 RFC 2046 延续了 external-body 模型。它要求 external-body 带有 Content-ID，便于缓存与后续回执关联同一材料；同时直接指出风险：解析外部正文，会让收件人执行发送者指定的操作。用户代理应解释动作，并取得明确许可。

因此，同意不能由地址语法代替，真实性也不能由校验和代替。RFC 2017 允许使用 Content-MD5，检查取回字节是否完整、是否符合发送者所指对象；紧接着便强调它不是数字签名。RFC 1864 同样把它限定为完整性检查，而不是作者认证。

外层消息与后来取回的对象，可能属于两条不同的证据链。验证了邮件，不会自动验证通过另一协议取得的字节；取回机制也可能被改向或破坏。地址描述的是一条取回路径，不是永久内容身份。

RFC 2017 以 Proposed Standard 发布，当前 RFC Editor 与 IETF 记录仍保留这一状态，本次核查未见匹配勘误。它依赖的 RFC 1738 如今已被标为废止，RFC 3986 提供了后来的一般 URI 语法。这些状态信息只能说明规范谱系，不能证明部署规模、实现普及或运行结果。

它留下的历史问题反而很朴素：系统究竟拿到了地址，还是拿到了对象？若只是地址，就还要分别回答谁授权取回、实际返回什么字节、类型是否相符、对象是否稳定，以及完整性证据能证明到哪一步。把这些答案合并成一个绿色状态，是后来系统自己作出的选择，不是 RFC 2017 给出的保证。

来源