摘要

  • IESG 于 2026 年 5 月 8 日批准 draft-ietf-mailmaint-expires-06 作为拟议标准。字段表达的是消息在某个日期之后“失去有效性”，规范有意没有把这句话扩大成统一的删除、拒收或隐藏指令。
  • 邮件软件不得仅因 Expires 而拒收或丢弃消息；除非邮箱所有者主动配置，否则也不应删除已经过期的消息。显示、策略、删除标记和永久清除仍是不同动作。

日期来自利益相关的一方

想象一封活动通知。活动结束后，让它退出默认收件箱视野很合理；但如果参与者日后要核对地址、承诺或变更记录，原信仍有价值。界面上的“过期”与证据上的“消失”不是同一件事。

Expires 使用 RFC 5322 的 date-time 语法。消息创建者不得放入多个同名字段。适用场景包括限时优惠、活动通知、社交通知和周期性公告：它们都有一个自然的时间边界，过了边界之后，展示优先级可以下降。

问题在于，日期由消息创建者选择。希望优惠尽快淡出的人，可能正是发出优惠的人；希望旧指令不再显眼的机构，也可能是指令来源。字段所记录的是来源方的判断，而不是收件人已同意的处置决定。

因此，工作组只把共同语义推进到“消息失去有效性”。它没有规定有效性究竟意味着不展示、降权、归档、删除还是别的结果。表面看，这像是不够精确；实际上，它拒绝伪造并不存在的共识，也拒绝把历史实现中的差异悄悄改写成一项全球授权。

标准化的是边界，不是产品按钮

IESG 的批准通知发于 2026 年 5 月 8 日 22:11 UTC。这份文件出自 Mail Maintenance 工作组，目标状态为 Standards Track 上的 Proposed Standard。本文冻结证据时，Datatracker 显示第 06 版已经进入 RFC Editor 队列，状态为等待首位编辑，IANA 动作为 RFC-Ed-Ack。

IANA 的 Message Headers 登记表已经把邮件用 Expires 列为 standard，并指向这份草案。登记表中另有一项 Netnews 的 Expires。同一个字段名称出现在两个系统里，不代表可以把一个系统的处置语义直接搬到另一个系统。

这个字段并非凭空出现。早期的 X.400 映射和邮件头登记文件都留下了历史脉络，不同软件也曾采用不同做法。新文件没有用一句漂亮的定义抹平这些事实，而是确立一个最小共同规格：能够交换一个时间信号，同时禁止最危险的默认解释。

这符合薄协调的原则。共同层只承担互操作所必需的含义，未来的产品选择由本地作出。标准可以让软件识别字段，却不需要替所有邮箱所有者决定什么应该永久消失。

阅读器可以行动，但行动要分层

邮件体系结构把两端称为 Message Creator 和 Message Reader。后者可以是存储代理，也可以是用户代理。阅读器可以淡化过期邮件，可以让默认视图不显示它，也可以向用户提供清理规则。

规范同时设置两条硬边界。第一，软件不得仅因 Expires 已过而拒收或丢弃消息。第二，除非邮箱所有者有意配置了这种行为，否则软件不应删除带有过去日期的消息。

“减少注意力”通常可逆，“删除证据”则可能不可逆。把邮件从首屏移到归档视图，是展示决定；给它加删除状态，是数据状态变化；永久清除，则是另一个结果。一个来自发件人的时间戳可以参与第一个决定，但不会自动获得最后一个决定所需的权力。

IMAP4rev2 把这条动作链写得很清楚。消息先带上 \Deleted 标记，EXPUNGE 才会永久移除带有该标记的消息，UID EXPUNGE 还可以把范围限制在特定 UID。邮箱未必都采用 IMAP，但任何可靠系统都应能给出等价证据：解析了什么，应用了哪条本地规则，状态何时改变，字节何时被清除。

如果所有步骤都被压成一个“自动过期”，运营者就无法回答最重要的问题：这究竟是发件人的声明、界面的选择、邮箱所有者的政策，还是一次不可逆操作？

签名能证明来源，不能扩张权限

DKIM 可以证明某个签名域对一组被签名内容承担了一定责任。如果 Expires 被纳入签名，之后的篡改可能在 DKIM 的适用条件下被发现。这改善的是来源链。

它不能证明日期合理、真实或符合收件人的目的，更不能把签名域变成收件人数据的管理者。证明“谁说了这句话”，并不等于证明“谁有权执行这句话”。

这种区别在互联网基础设施中并不陌生。可机读的登记项、路由属性或签名对象，各自在明确范围内提供事实；它们不会因为格式标准化或带有密码学归属，就自然取得更广泛的操作权。证据层与授权层必须保持分离。

Expires 特别容易诱使系统越界，因为时间戳看起来天然适合自动化。正确的工程做法不是拒绝自动化，而是让自动化始终显示其权力来源：是展示偏好、用户清理规则、组织保留政策，还是独立的删除操作。

恶意发件人也会使用这个字段

威胁分析不假定创建者善意。发件人可以选择很久以前、几分钟以后或遥远未来的日期。缺少其他信息时，阅读器不能把这个值当作准确或有益的事实。

过去日期可能让垃圾邮件在用户举报前淡出。一个很近的未来日期，可能让投诉或有争议的指令在采取行动后更难找到。遥远未来则可能被用于争夺长期可见性。所以，这个字段不适合单独判断邮件是否受欢迎，也不适合判断它是否欺诈。

这并不意味着日期毫无用处。阅读器可以结合认证结果、发送者历史、消息类型和邮箱所有者偏好来展示它。界面可以诚实地说“已超过消息所声明的有效期”，而不是暗示系统已经发现一项客观真理。

语言就是控制的一部分。“按消息声明已过期”是证据描述；“可以安全删除”是本地决策。两者之间必须有一条由承担损失的一方拥有、能够审计的规则。

来源