☰

背景

tag-icon • tag-icon email email-server mx-record spf email-bounces
背景

背景

我们有一个正在运行的 Web 应用程序webapp.example.com，它（除其他外）不时通过电子邮件发送消息。这些消息并不重要：虽然我们希望尽最大努力发送这些消息，但消息发送失败并不重要。

考虑到这一点，昨天我问如果不想收到电子邮件退回该怎么办？—遗憾的是，答案似乎是丢弃此类反弹后首先接收它们（而不是拒绝它们，例如在 SMTP 层或更低层；或者使用空返回路径传输原始消息）。

选择

假设 Web 应用程序生成的消息当前具有返回路径，[email protected]并且在 DNS 中，域example.com.由以下记录完全定义：

@        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"

我们的问题是，为了接收退回邮件（尽管纯粹是为了可以丢弃它们），我们认为：

  1. webapp.example.com必须运行接受退回消息的 SMTP 服务器；

  2. 其他机器必须运行接受退回邮件的 SMTP 服务器，并且必须添加 MX 记录webapp.example.com.以便将邮件投递到那里；或者

  3. 返回路径必须改变，例如改为[email protected]— 在这种情况下，该域的邮件交换器不仅必须接受退回消息，而且必须：

    （a）结果域的发件人策略（例如example.com.）必须更新为包含a:webapp.example.com；或

    （b）Web 应用程序必须通过该域的发件人策略批准的主机中继所有传出消息，例如192.0.2.0/24。

问题

选项＃1是不可取的，因为我们不特别希望在托管web应用程序的机器上运行额外的面向公众的服务（尤其是那些功能很少的服务）而带来额外的安全风险。

选项＃2 是不可取的，因为我们唯一面向公众的邮件服务是由第三方提供的，而创建新的收件人域超出了我们现有服务协议的范围。

选项 #3(a) 是不可取的，因为我们不希望授予webapp.example.com在 内的其他发送者发送消息的权限example.com。

webapp.example.com选项＃3（b）是不可取的，因为它需要维护从（面向公众的）到我们安全的、仅内部使用的网络的VPN 连接。

那么我们该怎么办呢？

在许多情况下，选项 2 可能是最佳解决方案。但是，鉴于上述原因，对我们来说，选项 1 看起来最不糟糕——但它仍然感觉过于夸张。有没有更好的方法？

答案1

通过阅读您之前的问题主题，我了解到您正在使用 exim。我的建议是将其配置为“仅发送”MTA。我个人使用过本指南在公共网络上快速配置仅发送邮件服务器。基本上它的作用是拒绝外部连接到 smtp 端口。

我知道这不是解决问题最“标准”的方法，但它非常实用。

缺点是，一些电子邮件提供商可能不喜欢无法联系到原始服务器，并拒绝接受来自该服务器的邮件。根据我的经验，我从未见过这样的事情发生，但我猜这取决于您发送的“非关键”邮件的数量，以及这些邮件被退回的频率。

相关内容