摘要

  • 普通邮件用反向路径指定日后接收投递报告的位置；通知邮件改用 MAIL FROM:<>，使通知本身失败时不能再要求另一封通知。
  • 空反向路径是 SMTP 信封中的有效控制值，不等于没有 From:、匿名可信或免于安全检查；提交服务器必须识别它，SPF 仍可用 HELO 身份评估发送主机。
  • DSN 后来增加逐收件人状态和关联字段，却没有取消这个终止符。远程报告停止后，责任收束到生成通知的本地系统，而不是凭空消失。

真正棘手的是接受之后

在 SMTP 会话尚未结束时拒绝收件人，问题很简单：连接中的客户端收到否定响应，邮件仍由它负责，不需要新建一封邮件说明失败。复杂性来自服务器在 DATA 之后给出成功答复。这个答复意味着它已经收下邮件并承担继续投递或报告结果的责任；但邮箱失效、下一跳断开、名单展开失败，都可能稍后才被发现。

此时原客户端早已离线，失败事实只能另行组成一封邮件，寄往原信封的反向路径。若这封通知也填写普通发件地址，它的投递失败便会触发第二封通知；第二封再失败，又会触发第三封。可靠性承诺反而制造了一个没有自然终点的递归过程。

1982 年的 RFC 821 已经看见这个陷阱。它要求接管中继任务后发现无法投递的服务器向原反向路径报告，同时告诫实现者不要为通知消息的问题再发通知。解决办法写成极短的一行：

MAIL FROM:<>

尖括号里不是一个空用户名，也不是漏填字段。它表示本次事务没有可供下一次退信使用的远程邮箱。邮件仍有生成它的系统、传输连接、目标收件人和追踪记录；被删除的只有“失败后再向哪里寄失败报告”这一条边。

空值从建议变成互操作义务

RFC 1123 在 1989 年把早期建议收紧为主机要求。SMTP 必须支持空反向路径。服务器不能仅因 MAIL FROM 里没有普通邮箱就把合法通知判为语法错误。

同一规范也把终止逻辑补完整：接受邮件以后生成的失败通知必须使用空反向路径；若原先要报告的反向路径已经为空，就不得再生成通知。因此，接收与停止是同一设计的两面。只实现前者，会让自动程序继续递归；只实现后者而拒绝所有空发件人，又会让合规的投递报告无法到达。

这套规则的重要之处，是它把“无”赋予了正面含义。网络协议不能靠猜测区分忘记填写与有意结束。<> 是线上可见、可测试、可保留的状态，明确告诉下一台机器：不要重新创造已经关闭的返回通道。

信封地址不是读者看到的作者栏

反向路径属于 SMTP 事务。邮件正文里的 From: 面向读者，Reply-To: 指引人的回复，而信封 MAIL FROM 分配机器在未来投递失败时的责任。三者都可能看起来像邮箱，却处在不同的控制平面。

一封自动退信可以在可见 From 中写出运营服务名称，让收件人知道是谁生成报告；同时在信封里使用 MAIL FROM:<>，要求传输软件不要为它再生成 DSN。这并不矛盾。

危险发生在通用自动化“补全”空值时。程序看见信封地址为空，便从 From 或 Reply-To 猜一个地址并回复。它其实把协议为防循环而删除的边重新接了回来。保持空值，需要比填满数据库字段更精确的语义意识。

接管责任的时刻决定补救方式

RFC 5321 延续了 DATA 后成功答复的责任边界。在答复之前，接收端若已有充分证据，应当在当前会话直接拒绝。连接中的真实客户端会得到结果，也避免把后来的退信寄给可能伪造的反向地址。

但并非所有失败都能提前知道。临时 DNS 故障、远端网关、邮件列表扩展和本地异步处理可能在接管后才暴露问题。此时通知不可避免，空反向路径负责把新产生的风险限制在一层。

这也解释了为何空路径不能独自解决 backscatter。攻击者可在第一封普通邮件中冒用无辜者的反向地址；服务器先接受后退信，第一封通知仍会打向受害者。空值只保证这封通知不会继续生出孙通知。交易期拒绝、速率策略与主机授权处理的是相邻但不同的风险。

终止远程邮件，不等于销毁故障

如果合法 DSN 自己无法投递，SMTP 的远程报告链必须停止，但操作责任仍在。RFC 5321 允许系统在本地记录或传递空地址失败信息，也提到可把问题交给能够修复邮件系统的 postmaster。关键条件是这条内部路径不能再次产生外部 DSN。

远程通知是跨域责任移交：向原反向路径报告发生了什么。本地升级则是对运营人员说：我们生成的最终报告也没有到达，请检查路由、队列和配置。协议没有掩盖失败，只是决定由谁在最后一站面对它。

因此，空路径绝不是删除证据的理由。原始信封、队列标识、逐收件人状态、最后一次尝试和诊断结果仍应按隐私与运维要求保存。<> 规定谁不该再收到邮件，并没有规定系统可以忘掉什么。

DSN 把请求与证据拆开

早期退信常由各产品生成自然语言文本，机器难以判断一封报告对应哪个事务、哪个收件人。RFC 3461 增加了 Delivery Status Notification 扩展。ENVID 提供信封关联标识，RET 决定返回头部还是更多原文，ORCPT 保留被重写前的原收件人；NOTIFY 可以请求 SUCCESS、FAILURE、DELAY，或者独占值 NEVER。

这些参数是报告偏好和证据关联，不应改变原本有效的 MAIL 或 RCPT 是否被接受。更重要的是，它们没有削弱终止规则：对于 MAIL FROM:<> 的邮件，MTA 不得因为正文头部出现一个貌似可用的发件人就生成 DSN。

发送 DSN 时，信封发件地址必须为空。它自己的事务不能使用 RET；若带 NOTIFY，只能是 NEVER。于是报告内部可以很丰富，对未来报告的要求却是明确的零。

RFC 3464 又规定了结构化格式：multipart/report 中可同时包含供人阅读的说明、机器读取的 message/delivery-status，以及在返回和隐私政策允许下附带的原邮件材料。一封 DSN 对应一封原邮件，却可为多个收件人分别记录 Action、Status、远端 MTA 和诊断结果。

逐收件人结构很关键。同一封邮件可能对甲投递成功、对乙延迟、对丙最终失败。名单系统可只暂停持续失败的成员，而不把整次群发当作失败。delayed 也不同于 failed：前者仍会重试，后者表示报告 MTA 已经放弃。

不过结构不等于认证。DSN 可能泄露转发地址、收件人和原文，也可能被伪造。规范允许在保密边界省略敏感字段。字段提升了证据粒度，却不是不可抵赖证明；更详细的报告仍须使用空反向路径，因为细节不会自动消除循环。

自动回复继承了同一个终止问题

假期回复、帮助系统、群组机器人和内容处理器同样可能互相触发。RFC 3834 把纪律推广到这些场景：自动程序不得向空地址生成响应，通常应依据信封 Return-Path，而不是从面向人的 From 或 Reply-To 猜目的地。

若自动响应本身不值得再次自动回复，它可以使用 MAIL FROM:<>；支持 DSN 扩展时，还应请求 NOTIFY=NEVER。但这只切断循环，不会证明请求获得授权。返回地址容易伪造，服务机器人若对未经确认的请求发送巨大内容或产生副作用，仍会成为放大器。

RFC 6409 因而要求消息提交代理不能仅凭空反向路径拒绝提交。合法客户端会产生这种邮件，包括某些处置通知。提交账户认证、内容策略、配额和速率限制仍可执行；不能执行的是“空即恶意”的粗糙推断。

没有邮箱，仍然可以评估主机

SPF 通常检查 MAIL FROM 域；空路径似乎没有可检查对象。RFC 7208 给出确定做法：在反向路径为空时，MAIL FROM 身份按 HELO 身份所在域的 postmaster 构造。这样，系统仍能判断发送主机与域的授权关系。

这种结果必须窄读。SPF 不验证 DSN 正文，不证明故障真的发生，也不认证某个人。获授权的主机可以生成错误通知，合法通知也可能因配置失误失败。它只说明空邮箱不等于所有身份面都消失。

空反向路径还经常被误解为 null MX。二者只是都使用显式的“无”。null MX 是 DNS 对一个域不接收邮件的声明；空反向路径则存在于正在传输的单次邮件信封中，告诉接收者不要为本次事务失败另发通知。一个阻止向域尝试投递，一个终止错误报告分支。

来源与证据边界

最初的无法投递通知与 MAIL FROM:<> 循环终止机制见 RFC 821：https://www.rfc-editor.org/rfc/rfc821.html

必须支持空路径以及不得向空返回地址再发通知的要求见 RFC 1123：https://www.rfc-editor.org/rfc/rfc1123.html

DSN 信封参数、空发件人处理和 NOTIFY=NEVER 见 RFC 3461：https://www.rfc-editor.org/rfc/rfc3461.html

结构化 multipart DSN、逐邮件和逐收件人字段及其隐私限制见 RFC 3464：https://www.rfc-editor.org/rfc/rfc3464.html

假期、群组和服务自动回复规则见 RFC 3834：https://www.rfc-editor.org/rfc/rfc3834.html

当前 SMTP 责任移交、空发件人消息类型、转发纪律与本地 postmaster 路径见 RFC 5321：https://www.rfc-editor.org/rfc/rfc5321.html

消息提交时合法使用空发件人的要求见 RFC 6409：https://www.rfc-editor.org/rfc/rfc6409.html

空反向路径使用 HELO 构造 SPF 身份的规则见 RFC 7208：https://www.rfc-editor.org/rfc/rfc7208.html

这些规范证明的是协议义务，不是某一封 DSN 的真实性，也不是当前服务商的部署状况。本文不推断现时退信数量、垃圾邮件比例、拒收率或产品策略。