我运行一个通过 smtp.mailgun.org 发送电子邮件的服务器。我锁定了服务器，只允许端口 587 上的传出 SMTP 到 smtp.mailgun.org。
该域的 IP 地址最近更改了，因此我的系统停止发送电子邮件。作为试图找出停止工作的一部分，我意识到在 iptables 规则中使用域名的缺点以及 iptables 在您运行规则时进行查找并在规则时保存 IP 地址的事实已创建，因此域中的 IP 地址更改不会反映在 iptables 中。
从mailgun的状态页面，他们说
我们的基础架构升级将导致未来更频繁地更改这些 IP 地址，客户应确保他们在连接到 Mailgun 服务时仅使用我们支持的主机名。
我没有收到有关 IP 地址更改的通知，也不知道是否会收到有关将来更改的通知。
处理这种情况的最佳方法是什么？我是否应该编写一个脚本来定期检查 smtp.mailgun.org 的 IP 地址并在 iptables 更改时更新它？（我知道这样做的安全风险，但也许值得一试）。
快速查看 smtp.mailgun.org 的当前 IP 地址会发现它们都在 Amazon AWS 上。您应该期望这些会经常更改，因此在防火墙中对它们进行硬编码充其量是很棘手的。即使使用动态脚本，您也可能会丢失外发邮件，因为 IP 地址可能会更改，并且您尝试在下次运行脚本之前发送邮件。这称为竞争条件。除了重新设计之外，您无能为力，这就是我会推荐的...
至于出口防火墙，我真的不太担心到端口 587 的传出流量。无论如何，所有这些流量都必须通过远程邮件服务器的身份验证，所以这对我来说不是一个重要的问题。对于邮件，我担心到端口 25 的传出流量；如果您使用的是 mailgun 之类的服务，则应该没有这样的流量，如果有，那几乎可以肯定是因为您已被入侵。
您可以考虑的一些事情是：
允许任何传出 TCP 流量到目标端口 587。如上所述，这是相当低的风险，但您可以通过以下方式进一步降低风险...
在唯一的用户 ID 下运行您的 Web 应用程序，然后只允许该用户 ID 的任何传出 TCP 流量到目标端口 587。（使用
-m owner匹配项。）通过规定只有 Web 应用程序的用户可以发起此类流量，这进一步降低了风险。请注意，如果您这样做，其他用户将无法进行此传出连接，甚至 root 也无法（但 root 可以更改防火墙规则以使其成为可能）。您可以通过运行配置为使用 mailgun 作为智能主机的仅本地邮件服务器来使您的设置更加健壮，中继它收到的所有邮件（因为它只在本地侦听，这应该只来自您的 Web 应用程序）。然后，您只允许邮件服务器的用户 ID 与上述端口 587 建立传出连接。这为您提供了不丢失邮件的额外好处，因为在您的 Web 应用程序尝试发送邮件时无法访问 mailgun。如果由于网络问题或防火墙配置错误或任何其他原因导致 mailgun 无法访问，您的 Web 应用程序将记录错误并丢失邮件，但本地邮件服务器会将邮件排队并在服务恢复时将其发送。然后，您将 Web 应用程序配置为在本地交付。