摘要

  • RFC 2076 是信息性目录，不是对所有字段的标准认证；邮件、Usenet、X.400 网关和非标准惯例各自保留不同适用范围。
  • 它明确排除 SMTP、UUCP、NNTP 的传输信封属性，以及 PEM、MOSS 正文内部字段；消息头从来不是整笔传输事务。
  • 正确的证据链是出现 → 定义 → 协议语境 → 状态 → 本地处理 → 实际结果，前一张回执不能代替后一张。

RFC 2076 没有再发明一种消息头。它整理了运营者已经会遇到的名称，并在整齐的“名称：值”语法旁保留不整齐的制度现实：有的字段已标准化，有的只是实验，有的有争议或不鼓励使用，还有一些只属于 Usenet 或 X.400 网关。

同一个字典里有多种管辖范围

目录引用 RFC 822 的互联网邮件、RFC 1036 的 Usenet 和 RFC 1327 的 X.400 映射。Usenet 字段偶尔出现在电子邮件里，并不会因此成为邮件标准；X400-Received、Alternate-Recipient 记录网关语境，也不会因进入收件箱就获得通用权威。

RFC 3864 后来把这一原则变成永久与临时注册表，同名字段可以有不同协议条目，临时登记也不代表 IETF 或 IANA 背书。RFC 4021 和今天的 IANA 表仍把协议、状态、参考文件分列展示。

被排除的内容划出了证据边界

RFC 2076 不收录 SMTP、UUCP、NNTP 信封属性，也不收录 PEM 或 MOSS 正文内部字段和仅用于 HTTP 的头。可见消息头因此不能冒充真正的信封收件人、退信地址或正文内的安全声明。

调查一封邮件，需要分别保留原始消息、传输信封、转发轨迹、网关转换和客户端决策。把它们提前压成一个方便的“headers”对象，会先抹去事实由谁产生，再抹去谁应负责。

Apparently-To 把推断变成了隐私风险

部分 sendmail 实现会在缺少 To 时，根据信封收件人插入 Apparently-To。RFC 2076 将其标为非标准且不鼓励使用，并警告它可能暴露密送收件人。自动生成把仅供传输层掌握的信息改写成了读者可见内容。

解析器可以准确报告该行，却不能证明生成者、授权范围和披露政策。出现是一张观察回执，不是许可。

标准语法也不能解决社会意图

Reply-To 有标准依据，RFC 2076 仍称其用法存在争议。给个人回复、给群组回复与邮件列表政策表达的是不同意图。列表管理器重写字段、客户端选择回复按钮，都是新的本地决定。

Errors-To 与 Return-Receipt-To 则被列为非标准且不鼓励使用。请求通知不等于交付、阅读或业务效果。可靠结论必须沿着“出现、定义、语境、状态、执行、结果”逐步取证。

来源