即使可靠的远程MTA可用，也可以使用本地MTA

Question

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

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

缺点：发送电子邮件的用户可能会被告知发送邮件时出现问题。程序可以立即检测远程服务器是否不可用。 缺点：安全。必须充分配置本地MTA以确保服务器的安全性 缺点：过程中的一层复杂性。

在我看来，我们应该保持简单。我们不是在讨论与MTA服务器通信的程序，这些服务器不受我们控制，我们不知道它的状态。在我看来，如果你不确定你的计数器部件，那么有一个本地MTA是必要的，但是在这里，程序将把它交付给一个“已知”的MTA系统。所以我认为附加层不是必需的。此外，在每个尝试发送电子邮件的系统上都有本地MTA也可能导致其他问题/错误和更多管理任务（维护/修补）。有人可能会说，在Unix系统上，你总是运行本地MTA（sendmail），但在我们的组织中，我们将系统降至最低，以确保没有运行额外的服务，这可能会带来潜在的风险。

但是，我很想知道您将如何设计基础设施，同时牢记您与已知/受控/受监控的MTA系统进行通信。或者只是观点问题？

非常感谢您的反馈。

伊夫

Answer 1

本地MTA，即使远程服务器在同一管理下。在某些时候，必须修补远程MTA并重新启动。通过直接转到远程MTA，它会创建一个硬依赖关系，以便应用程序在重新启动远程MTA时会遇到错误等。应用程序现在需要实现重试逻辑，与多个远程MTA通信;基本上成为一个精简的MTA。本地MTA仍然应该转发到远程MTA而不是直接发送电子邮件 - 这样可以更轻松地管理和保护电子邮件传送。

Answer 2

如果远程MTA（“ ...位于内部网络上的MTA服务器...... ”）与建议的本地MTA处于同一管理下，则和后者只会传送到远程MTA（作为一种中继“smart host”），然后就不需要本地MTA。

唯一的问题是，如果发送邮件的本地应用程序/用户在尝试访问远程MTA时可能会遇到潜在的额外网络故障风险。