使用端口 587 进行所有客户端到 MTA 的通信的趋势越来越大。它在标准轨道 RFC 中：http ://www.ietf.org/rfc/rfc2476.txt
我的问题是“为什么？”。如果它们都做同样的事情，为什么在同一台服务器上运行 2 个 SMTP 服务器实例？它提供了什么安全功能，除了给我作为管理员排除故障的 2 件事。
这似乎是不必要的复杂性，除非 ISP 阻止端口 25。即便如此，如果 ISP 阻止端口 25 以防止垃圾邮件，这只是意味着端口 587 也被阻止需要更多时间，我们将不得不完全使用不同的端口。
似乎我们正在为自己创造更多的工作，而不是解决问题并从一开始就验证 SMTP
我快速阅读了 RFC，他们的想法是将 SMTP 世界分为两个领域：传输邮件（这就是 SMTP 的开发目的）和提交邮件。
作者争辩说，SMTP 并非旨在由邮件客户端（MUA，消息用户代理）使用，而仅由邮件服务器使用，将邮件路由到其目的地。他们认为，如果您以这种方式划分 SMTP 世界，那么您可以编写一个只能由 MUA 访问的 SMTP 服务器，然后该 MUA 能够做事并做出“正常”的假设，转发 SMTP 服务器应该/可能不做。“正常”的 SMTP 服务器一直被称为 MTA，即消息传输代理。作者建议将这种新型 SMTP 服务器命名为 MSA，即消息提交代理。
似乎他们认为这将使实现这两种服务器类型更容易，甚至可能更安全。RFC 解释了 MSA 与 MTA 相比有哪些不同之处。例如，RFC 强制使用授权，而原始 SMTP 协议没有授权（SMTP AUTH 是后来添加的，似乎是 RFC 2476；但是 SMTP AUTH 本身是后来在 RFC 2554 中指定的，它已被替换由 RFC 4954）。
需要将来自各种来源的消息中继到各种目的地的 MTA 不能对每条消息都使用身份验证（另一台服务器应如何向您的服务器进行身份验证？）。但是作为消息起点的 MSA 可以并且必须要求来自其对等方（邮件客户端）的身份验证。虽然 MTA 必须不加更改地转发消息，但要添加Received标头，而 MSA 可能会“清理”电子邮件，例如通过填写缺失的标头之类的东西。
请参见。
http://www.uceprotect.net/downloads/MAAWGPort25English.pdf
我认为您缺少的是端口 587 仅经过身份验证。无论收件人是否是本地人，您都不应该在端口 587 上接受未经身份验证的电子邮件。我们（作为 ISP）阻止出站端口 25 以防止直接到 mx 的垃圾邮件。例如来自 botted 计算机。在阻止我们的住宅/动态用户群在端口 25 上发送出站消息（我们仍然允许在端口 25 上从我们的 IP 空间进行未经身份验证的中继）时，滥用报告减少了 85% 以上。
ISPS 不会开始阻塞 587（他们不应该，因为它不是供 MTA 到 MTA 使用的，只有 MUA 到 MTA，因为它是提交端口）。它使管理更加容易。同样在 MTA 方面，强制所有本地用户进行身份验证可以更轻松地缓解垃圾邮件。当他们的盒子被拥有并偷走他们的 smtp 信用证时。您需要做的就是禁用他们的帐户/密码。当通过 ip 使用中继时，您需要阻止他们连接到邮件服务器（我们通过将 ACL 动态应用到他们的 DSL/Cable 连接来做到这一点）。
如果您正在编写 MUA 或 MTA，则需要同时支持两者，并且在 MUA 或发送电子邮件的情况下，它应该默认为 587 尝试 TLS 和 smtp auth，并且仅在以下情况下故障回复到 465、25那失败了。