背景—标准
所有其他类型的消息（即，Standards-Track RFC 不要求具有空反向路径的任何消息）都应使用有效的非空反向路径发送。
为避免疑义，RFC 2119§3定义“应该“ 作为 ”在特定情况下可能存在忽略特定项目的正当理由，但在选择不同的方案之前，必须了解并仔细权衡其全部含义。“
情况
所考虑的“特殊情况”是指爱丽丝不希望接收递送状态通知（与她发送的电子邮件相关）。
她有几种选择：
当她收到此类通知时，忽略/丢弃它—显然这种行为完全正确，但它很麻烦（而且浪费她的资源）；
拒绝在较低级别接受此类通知—可以说反向路径不再“有效”（遗憾的是 RFC 中没有定义），如果是这样，这种行为违背了 RFC 的建议；或者
使用空的反向路径发送电子邮件，这样就不会生成通知—明显违背了 RFC 的建议。
问题
我非常确定这些情况构成了忽略上述 RFC 引用的建议的“正当理由”——但我想确保我已经理解了选项 2 和 3 的“全部含义”。
我特别指出：
在选项 2 下，一些代理可能会检测到反向路径无效
在选项 3 下，一些代理可能会将具有空反向路径的邮件视为特殊情况
不管怎样，代理可能会拒绝接受/转发/投递电子邮件，或者可能使用此类信息来增加其被标记为垃圾邮件的可能性。此类措施在实践中有多普遍？
我还应该考虑其他什么问题/影响吗？
答案1
使用选项 #1 始终是更好的解决方案。将其视为纸质邮件；必须提供有效的回信地址。由于垃圾邮件发送者利用开放政策，电子邮件只会受到更多限制（DMARC 等）。自动处理您不关心的回复并不难。但可能只有不到 10% 的电子邮件服务器有如此严格的限制，因此您可能可以侥幸逃脱。另外，请务必避免将您的服务器列入 dnsbl 中。
大多数地方的规则都很宽松（我可以发送一封看起来像是你发来的电子邮件，如果我把它发送给每个人，然后精心设计让它反弹，就会引发某种 DDOS）。看看后缀如果你想知道哪些规则可能生效。
你不能同时拥有两者；要么正确地做（#1），要么屈服于被标记为垃圾邮件发送者（至少被某些人标记为垃圾邮件发送者）。Google 使用[电子邮件保护]而这封邮件永远发不到我手上，因为我的邮件服务器需要已验证发件人。Google 是反垃圾邮件方面的佼佼者，如果他们不能两全其美，我相信我们也做不到。
答案2
4——处理反弹。
通常，最好的方法是让退回邮件进入某种退回处理过程，这样持续退回的收件人地址最终就可以从数据库中删除。这可以是“alice”的 .forward，或将信封发件人调整为处理程序。
无论“alice”是否关心电子邮件是否被退回，收件人服务器管理员或过滤器通常都会关心。在许多情况下，收件人服务器会将每次退回都算作负面声誉点数。如果退回次数太多，您就会被列入他们的黑名单，无法发送任何邮件。
不要因为自己懒得处理而浪费别人的资源。
答案3
总的来说，我同意 #1 可能是最佳解决方案，您只需丢弃服务器上的任何返回即可。安装一个将消息发送到 /dev/null 的 .forward。您的带宽费用不太可能受到影响。
对于您是否应该关心未送达的消息的更广泛的讨论，我真的不知道任何人以任何规模处理自己的退货，但像 SendGrid、MailGun 等服务在这方面非常出色，它们允许您通过 HTTP POST 发送，他们管理 IP 空间的声誉，并告诉您有关退回的邮件和投诉的信息。
对于你的情况，这可能不是关键，但总的来说，我现在尽量避免在生产中管理自己的邮件传递。这样可能会出很多问题，而且会极大地分散你对维护大型 Web 堆栈的其他方面的注意力。