3

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

优点：发送电子邮件的程序可以将其发送到本地 MTA，而无需担心发送、重试或任何可能出现的错误。

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

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

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

非常感谢您的反馈。

伊夫

4

2 回答 2

1

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

于 2014-10-01T00:15:09.877 回答
0

如果远程 MTA（“ ……位于内部网络上的 MTA 服务器…… ”）与提议的本地 MTA 处于相同的管理之下，并且后者将仅交付给远程 MTA（充当一种中继“智能主机”），则不需要本地 MTA。

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

于 2012-07-07T10:12:05.437 回答