为什么我应该说服开发人员在所有SMTP通信中使用端口587？

Question

为什么我应该说服开发人员在所有SMTP通信中使用端口587？

smtpexchange-serverspampop3rfc

10

越来越多的客户端与MTA(邮件传输代理)间通信采用端口587。这已成为标准轨迹下的RFC：http://www.ietf.org/rfc/rfc2476.txt

我的问题是“为什么？”。如果它们都完成相同的任务，为什么在同一台服务器上运行两个SMTP服务器实例？除了给管理员增加了两个故障排查点，它还提供了哪些安全功能？

这似乎只是不必要的复杂化，除非ISP封锁了端口25。即使如此，如果ISP封锁端口25以防止垃圾邮件，那么只是意味着需要稍微花费一些时间，直到端口587也被封锁，然后我们将不得不使用完全不同的端口。

这似乎只是为自己创造更多的工作而不是解决问题并首先对SMTP进行身份验证。

- makerofthings7

2个回答

10

请查看。请参阅：http://www.uceprotect.net/downloads/MAAWGPort25English.pdf。

我认为您遗漏的是端口587仅支持已验证邮件。无论收件人是否本地，都不应在端口587上接受未经身份验证的电子邮件。我们（作为ISP）阻止出站端口25以防止直接发送到MX的垃圾邮件。例如来自被控制的计算机。通过禁止我们的住宅/动态用户从端口25发送出站（我们仍然允许IP空间上的未经身份验证中继），导致滥用报告减少了85％以上。

ISP不会开始阻止587（他们不应该这样做，因为它不是MTA到MTA使用，只有MUA到MTA，因为它是提交端口）。它允许更轻松的管理。此外，在MTA端，强制所有本地用户进行身份验证可更轻松地进行垃圾邮件缓解。当他们的计算机被入侵并窃取了SMTP凭据时，您只需要禁用他们的帐户/密码即可。使用IP中继时，您需要阻止它们连接到邮件服务器（我们通过动态应用ACL到其DSL / Cable连接来实现）。

如果您要编写MUA或MTA，则需要同时支持两者。在发送电子邮件的情况下，它应默认尝试TLS和SMTP身份验证，并仅在失败时退回到465、25端口。

- Doon

端口465的期望是什么？SMTP Auth也包括在内吗？ - makerofthings7

465 是 SSL 下的 SMTP。而 25 和 587 开始时未加密，可以使用 starttls（如果支持）来启用 SSL 加密连接。端口 465 从一开始就是 SSL。身份验证是可选的，取决于服务器。 - Doon

谢谢，你的解释让我恍然大悟。我没有想到所有传入的SMTP服务器都应该有MX记录，而所有端口587服务器则没有这样的链接。这使得与25号端口的责任分离更加清晰。 - makerofthings7

我们的入站MXS和中继服务器位于不同的盒子上，这使我们能够更加重视MXS对抗垃圾邮件的保护。很高兴它有所帮助。 - Doon

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- DarkDust · Accepted Answer

我快速阅读了RFC文件，他们的想法是将SMTP世界分为两个领域：传输邮件（这就是SMTP开发的目的）和提交邮件。

作者认为SMTP不应该由邮件客户端（MUA，消息用户代理）使用，而只应由邮件服务器使用，将邮件路由到其目的地。他们认为，如果按照这种方式划分SMTP世界，则可以编写一个SMTP服务器，专门供MUA访问，然后能够执行一些常规的、转发SMTP服务器不应该/可能做出的假设。通常被称为MTA（消息传输代理）的“正常”SMTP服务器。作者建议将新类型的SMTP服务器命名为MSA（消息提交代理）。

他们似乎认为这样做可以使实现两种服务器类型更容易，甚至可能更安全。RFC解释了MSA与MTA相比需要有什么不同。例如，RFC强制要求使用授权，而最初的SMTP协议没有这个功能（SMTP AUTH稍后添加，似乎是由RFC 2476添加的；但SMTP AUTH本身在RFC 2554中进行了更详细的规定，并已被RFC 4954取代）。

需要从各种来源转发消息到各种目的地的MTA无法为每个消息都使用身份验证（另一个服务如何对您的服务器进行身份验证？）。但是MSA，作为您的消息起点，可以并且必须要求其对等方——邮件客户端进行身份验证。而且，虽然MTA必须转发未经更改的消息，除了添加一个“Received”头，但MSA可以“清理”电子邮件，例如填充缺少的标题等。