我们的一些 Linux 服务器将移至云中。但服务器需要能够向内部用户发送电子邮件,并且必须使用我们的域名作为发件人。服务器无法启动向我们的网络传输数据,也就是说,发送电子邮件的唯一方法是通过我们的邮件服务器。
不幸的是(但可以理解),我们的安全人员不允许外部服务器使用我们的域名作为发件人发送电子邮件,因此...
我正在考虑建立一个系统,让内部服务器通过 SSH 发起连接,收集电子邮件并将它们本地发送给我们的用户因为我们不允许从外部到内部网络建立开放连接,这可能会被黑客滥用,而且添加中继服务器也不是一种选择。
在过去的美好时光(30 年前),我们使用(称为)UUCP(Unix-to-Unix-Copy)的技术来传输文件、邮件、新闻发布(NNTP)...使用调制解调器 :-) 并且我认为这种设置将以更安全的方式再次发挥作用 - 但有更现代的替代方案/设置吗?
答案1
据我了解,您目前有一个或多个传入 MX:es。当您系统之外的服务器连接到这些 MX:es 时,如果其尝试发送的电子邮件包含您所在域内的 From:-header 或信封发件人,则您的 MX 服务器不会接受它。
是的,UUCP 是一种方法,而且我实际上看到过它在 TCP/IP 上使用,但那已经是十多年前的事了,甚至更久以前...但这里有一些解决这个问题的替代方法,而无需在您的网络中建立开放连接(我同意应该避免这种情况)。
- 您的 MX:es 可以拥有允许使用您的域名的主机白名单,您可以将您的云服务器添加到该白名单中。这假设您的云服务器具有固定 IP 地址。
- 如果你的云服务器没有固定 IP,你可以设置一个单独的服务器,做,然后将其列入白名单。
- 您的 MX:es 可以拥有您域内允许从外部使用的电子邮件地址白名单,并且您可以配置云服务器以使用这些特定地址
- 如果 MX:es 仅检查信封发件人,则您的云服务器可以使用他们喜欢的任何信封发件人,但电子邮件中的发件人:标题仍然可以是您公司域内的发件人
- 您设置了一个单独的 SMTP 服务器,该服务器不在 MX 列表中,并且只允许来自云服务器的传入电子邮件流量(通过 IP 白名单或身份验证或两者),并且可以传送到您的内部电子邮件系统。然后,此服务器需要与您现有的 MX 位于相同或相似的 DMZ/网段/任何位置。您需要配置您的云服务器以将其用作中继。
- 编辑您的 MX:s 可以允许使用其自己的域接收电子邮件认证后,并且可以配置您的云服务器在发送之前进行自我身份验证。
所有这些方法的优点是您可以继续使用常规 SMTP,而无需任何非标准解决方法。如果您的安全部门不接受其中任何一种,您可以使用以下方法解决提取邮件来自内部服务器,它将重新注入来自您组织内部的电子邮件。