RFC 5321§4.5.5规定：
所有其他types的消息（即，标准跟踪RFC不要求具有空的反向path的任何消息）应该被发送有效的，非空的反向path。
为了避免疑问， RFC 2119§3将“ 应该 ”定义为“ 在特定情况下可能存在忽略特定项目的有效理由，但在select不同的课程之前，必须理解并仔细权衡全部含义 ”。
正在考虑的“特定情况”是爱丽丝不希望收到送达状态通知（与她所发的电子邮件有关）的情况。
她有几个select：
忽略/丢弃任何这样的通知，当她收到它 – 明显这种行为是完全正确的，但这是一个滋扰（和她的资源浪费）;
拒绝在较低的级别接受这样的通知 –可以想象，反向path将不再是“有效的”（可悲的是，在RFC中没有定义），如果是的话，这样的行为是违背RFC的build议的; 要么
用一个空的反向path发起电子邮件，这样就不会首先产生通知 – 明显违背RFC的build议。
我非常肯定，这些情况构成了忽视RFC引用的上述build议的“合理原因” – 但我想确定我已经理解了选项2和3的“全部含义”。
我特别注意到：
在选项2下，一些代理可能检测到反向path无效
在选项3下，一些代理可能会把特殊情况下的空path作为对待
无论哪种方式，代理可能因此拒绝接受/转发/发送电子邮件，或可能使用这些信息，以增加被标记为垃圾邮件的可能性。 这种措施在实践中有多普遍？
我应该考虑其他问题吗？
使用选项＃1总是更好的解决scheme。 把它想象成纸邮件; 一个有效的返回地址是强制性的 电子邮件只是受到更多的限制（DMARC等），由于spamer利用开放的政策。 自动处理你不关心的回复真的不难。 但可能不到10％的电子邮件服务器是限制性的，所以你可以放弃它。 另外一定要避免让你的服务器在dnsbl中列出。
规则是大多数地方松懈（我可以发送一个电子邮件，看起来像是从你这将调用一种DDOS，如果我把它发送给每个人，并制作它反弹）看看所有在Postfix的限制，如果你想知道什么规则可能有效。
你不能双方都有， （＃1）或辞职标记垃圾邮件制造者（至less一些）。 Google使用[email protected]，因为我的邮件服务器需要经过validation的发件人，所以无法与我联系。 如果Google无法兼顾反垃圾邮件，Google是最好的select，我相信我们不能。
一般来说，最好的方法是使反弹进行某种反弹处理过程，以便永久popup收件人地址最终可以从数据库中删除。 这可能是“alice”的前奏，或者将信封发送者调整为处理程序进程。
无论“爱丽丝”是否关心电子邮件是否反弹，收件人服务器pipe理员或filter经常这样做。 在许多情况下，收件人服务器会将每次反弹计为负面声望点。 这样做够了，你最终在黑名单上，你将无法获得任何东西。
不要咀嚼别人的资源，因为你自己懒得去处理。
一般来说，我同意＃1可能是最好的解决scheme，你可以放弃在服务器上的任何回报。 安装将消息发送到/ dev / null的.forward。 你的带宽账单不太可能受到伤害。
在广泛的讨论中，你是否应该关心没有被传递的消息，我并不知道任何人在任何规模处理自己的回报，但像SendGrid，MailGun等服务是伟大的，他们让你通过HTTP POST发送，他们pipe理知识的IP空间，并告诉你关于返回的邮件和投诉。
对于你的情况，可能不是关键，但总的来说，我试图避免pipe理我自己的邮件在生产这些天。 这么多事情可能会出错，而且从维护一个大型Web栈的其他方面来看，这可能是一个巨大的分心。