我们有一个运行在webapp.example.com上的web应用程序（除其他外）通过电子邮件不时地发送消息。 这些信息是不重要的，尽pipe我们希望尽最大的努力来传递信息，但是信息传递失败的知识是没有意义的。
考虑到这一点，昨天我问，如果不想接收电子邮件反弹，该怎么办？ 可以肯定的是，答案似乎是在第一次接收它们（而不是拒绝它们，例如在SMTP层或更低层;或者用空的返回path传输原始消息） 之后 ，放弃这种反弹。
假设webapp生成的消息目前具有[email protected]的返回path，并且在DNS中具有域example.com. 完全由以下logging定义：
@ SOA ns.example.net. hostmaster 1 86400 7200 604800 300 NS ns.example.net. NS ns.example.org. MX 1 mx.example.net. TXT "v=spf1 a:192.0.2.0/24 -all" webapp A 198.51.100.1 TXT "v=spf1 a -all"
我们的问题是，为了接收反弹信息（尽pipe纯粹是为了可以丢弃 ），我们认为：
webapp.example.com必须运行接受退回消息的SMTP服务器;
某些其他机器必须运行接受退回消息的SMTP服务器，并且必须将MXlogging添加到webapp.example.com. 所以他们在那里交付; 要么
返回path必须改变，例如[email protected] – 在这种情况下，不仅该域的邮件交换器必须接受退回邮件，还必须：
（a）结果域的发件人策略，例如example.com. ，必须更新以包含a:webapp.example.com ; 要么
（b）webapp必须通过由该域的发送者策略批准的主机（例如192.0.2.0/24 ）来中继所有发出的消息。
选项1是不受欢迎的，因为我们并不特别希望在托pipewebapp的机器上运行额外的面向公共服务的额外安全性（至less是那么less的）。
选项2是不可取的，因为我们唯一面向公众的邮件服务由第三方提供，创build新的收件人域超出了我们现有服务协议的范围。
选项＃3（a）是不合需要的，因为我们不希望授予webapp.example.com权限来发送来自example.com其他发送者的消息。
选项＃3（b）是不可取的，因为它需要维护从（面向公众的） webapp.example.com到我们安全的webapp.example.com内部networking的VPN连接。
那我们该怎么办？
在许多情况下，select＃2可能是最好的解决scheme。 但是，鉴于上述原因，对于我们的选项＃1看起来是最不好的 – 但它仍然是巨大的矫枉过正。 有没有更好的办法？
通过阅读你以前的问题线程，我收集到你正在使用exim。 我的build议是将其configuration为“只发送”MTA。 我亲自使用这个指南来快速configuration公共networking上的发送邮件服务器。 基本上它是拒绝到smtp端口的外部连接。
我知道这不是解决问题最“标准”的方法，但是非常实际。
不足之处在于有些电子邮件服务提供商可能不喜欢原来的服务器无法返回，并拒绝完全接受邮件。 根据我的经验，我从来没有见过这样的事情发生，但我想这取决于你发送的“非关键”邮件的数量，以及这些邮件多久被反弹。