摘要

  • 1998 年 3 月的 RFC 2298让发件人在邮件头加入 Disposition-Notification-To 请求处理回执。收件端用户代理可以不理会，也可以按当时的格式回一个 denied。
  • 回执描述邮件程序的动作，例如显示、转送、处理或删除。原版规范建议先征得用户同意，并限制每位收件人的程序对同一封邮件最多发一份回执。2004 年的 RFC 3798后来删掉了少有人使用的 denied 和 failed 状态。

信封里夹着一张小纸条

一封九十年代的电子邮件看起来平平常常。正文谈工作，标题写事情，发件端却在邮件头暗放了一句：“处理完，请告诉这个地址。”那句请求叫 Disposition-Notification-To。它跟着邮件抵达别人的收件箱时，提问权已经用完。接下来，由收件端的程序和使用者决定是否回答。

1998 年 3 月的 RFC 2298为这种 Message Disposition Notification，简称 MDN，设计了机器可读的格式。第二节把邮件头写得很清楚：它提出请求。收件端用户代理可以安静地忽略；原始版本还允许回送 denied，明说不提供邮件去向。规范又强烈建议程序取得用户同意。有人可以逐封确认，有人可以设定长期偏好，也有人可以把回执全部关掉。收件箱没有因一个头字段而变成发件人的监控台。

“已读回执”这个俗称，比协议能看见的东西宽。原版定义了 displayed、dispatched、processed、deleted 等动作。displayed 表示程序把邮件显示给访问收件箱的人；dispatched 包含转发或打印；processed 可以只是服务器规则做了处理；deleted 是删除。回执所记录的是这些动作发生在哪个程序环节。眼睛是否扫过每一行、意思是否被理解，邮件格式没有替人作证。

同一个状态还可能通过不同方式出现。RFC 2298 的模式字段区分用户手动操作与程序自动操作，也区分用户为这一份回执单独授权，还是程序按照既有配置自动发送。发件人收到 displayed，能知道收件端报告了显示事件；若要追问是谁按的按钮，模式字段比“已读”两个字有用得多。

标准还担心程序过于热心。它规定同一收件人的用户代理对同一封邮件最多发一份 MDN。回执自身不能再带请求回执的字段，收到回执也不能再生出回执。想象两台程序互相敲门，越敲越响；这几条规则直接把门铃线剪短了。

更狡猾的玩法是把回执地址写成第三方。有人发出大量邮件，却要求所有收件端把通知寄到某个无辜地址。RFC 2298 因此要求程序注意 Disposition-Notification-To 与 Return-Path 的关系：两者不一致、回程地址缺失或请求里塞了多个不同地址时，应请用户确认，或者不自动发回执。原文直接指出邮件循环与“邮件轰炸”的风险。小小的查岗纸条，也能被改造成骚扰工具。

这套设计把权力拆得很细。发件人有提问权。收件端程序检查邮件头、地址和本地偏好。用户可以授权、拒绝或保持沉默。若回执真的发出，它陈述一个有限的处理事件。邮件的成功送达给了发件人一个机会，却没有把收件人的注意力交出去。

后来，协议里那枚正式的拒绝印章反倒先退场。2004 年取代 RFC 2298 的 RFC 3798说明，denied 和 failed 因缺少实际使用而从状态表删除。沉默仍然可以发生。协议没有派人上门追问为什么不回。热衷回执的发件人失去的是一个明确的“不”，留下的是一扇可能始终关着的门。

这段历史的幽默在于，最想得到确定答案的人只能写一个请求。收件箱倒像个有脾气的办公室：可以出具记录，可以盖拒绝章，也可以把纸条压在文件堆下。机器能报告的是自己的动作；一个人的阅读与理解，从来不在那个小字段里。