本地MTA，即使有可靠的远程MTA也是如此

Question

我曾与我们的开发团队讨论过在应用程序服务器上安装本地MTA，或者他们是否应该使用位于内部网络上的MTA服务器来发送电子邮件。这两种解决方案各有利弊。

优点:发送电子邮件的程序可以将其传递到本地MTA，并忘记传递、重试或可能出现的任何错误。

缺点:发送电子邮件的用户可能会在很晚的时候才被告知发送邮件有问题。如果远程服务器不可用，程序可以立即检测到。缺点:安全。必须对本地MTA进行充分配置，以确保服务器的安全性缺点:过程中的额外一层复杂性。

在我看来，我们应该保持简单。我们不是在谈论一个与MTA服务器对话的程序，MTA服务器不是由我们控制的，并且我们不知道它的状态。在我看来，有一个本地的MTA是必要的，如果你不确定你的柜台，但在这里，程序将提供它到一个“已知”的MTA系统。所以我认为额外的一层是没有必要的。此外，在每个试图发送电子邮件的系统上都有一个本地MTA也可能导致额外的问题/错误和更多的管理任务(维护/修补)。有些人可能会说，在Unix系统上，您总是运行本地MTA (sendmail)，但在我们的组织中，我们将系统缩减到最低限度，以确保没有运行额外的服务，这可能会导致潜在的风险。

但是，我非常有兴趣知道您将如何设计基础设施，同时记住您与已知/受控制/受监控的MTA系统进行对话。或者这只是一个观点问题？

非常感谢您的反馈。

伊夫

Answer 1

如果远程MTA ("...位于内部网络上的MTA服务器...")与建议的本地MTA处于相同的管理之下，则和将仅传送到远程MTA (充当某种中继“smart host”)，则不需要本地MTA。

因此，唯一的问题是，发送邮件的本地应用程序/用户在尝试访问远程MTA时，是否可以承受网络故障的潜在额外风险。

Answer 2

本地MTA，即使远程服务器处于相同的管理之下。在某些情况下，远程MTA必须打补丁并重新启动。通过直接转到远程MTA，它创建了硬依赖关系，使得应用程序在远程MTA重启时将遇到错误，等等。应用程序现在需要实现重试逻辑，与多个远程MTA通信；基本上成为一个精简的MTA。本地MTA仍然应该中继到远程MTA，而不是直接传递电子邮件--这使得管理和保护电子邮件传递变得更容易。