为什么我要说服开发人员将端口587用于所有SMTP通信？

对于所有客户端到MTA的通信，使用端口587的趋势越来越大。它位于标准轨道RFC中：

我的问题是“为什么？”。如果SMTP服务器的两个实例执行相同的操作，为什么它们在同一台服务器上运行？它提供了什么样的安全功能，除了给我2件作为管理员需要解决的问题之外

这似乎是不必要的复杂情况，除非ISP阻止端口25，否则不需要这样做。即使如此，如果ISP为了防止垃圾邮件而阻止端口25，这也意味着端口587也会被阻止，而我们将不得不使用一个不同的端口

---

似乎我们正在为自己创造更多的工作，而不是从解决问题和验证SMTP开始

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

作者认为，SMTP不应该被邮件客户端（MUA，Message User Agent）使用，而应该被邮件服务器使用，将邮件路由到目的地。他们认为，如果你以这种方式划分SMTP世界，那么你就可以编写一个只有MUA才能访问的SMTP服务器，然后它就可以做一些事情，并做出“正常”的假设，转发SMTP服务器应该/可能不会这样做。“普通”SMTP服务器始终称为MTA，即邮件传输代理。作者建议将新类型的SMTP服务器命名为MSA，即消息提交代理

似乎他们认为这将使实现这两种服务器类型更容易，甚至更安全。RFC解释了MSA与MTA的不同之处。例如，RFC强制使用授权，而原始SMTP协议没有授权（SMTP AUTH似乎是在RFC 2476之后添加的；但是SMTP AUTH本身是RFC 2554中指定的后者，后者已被RFC 4954取代）

需要将不同来源的邮件中继到不同目的地的MTA不能对每条邮件使用身份验证（其他服务器应如何对您的服务器进行身份验证？）。但是作为消息起点的MSA可以而且必须要求其对等方邮件客户端进行身份验证。MTA必须在未更改的情况下中继邮件，并保存以添加

接收的
邮件头，MSA可以通过填写缺少的邮件头等方式对电子邮件进行“清理”。
请参阅


我认为您缺少的是587端口仅经过身份验证。无论收件人是否为本地人，您都不应接受587端口上未经验证的电子邮件。我们（作为ISP），阻止出站端口25以防止直接发送到mx的垃圾邮件。例如，从僵尸电脑。阻止我们的住宅/动态用户群在端口25上向外发送（我们仍然允许从端口25上的IP空间进行未经验证的中继），从而使滥用报告减少了85%以上

ISP不会开始阻止587（他们不应该这样做，因为它不是MTA对MTA使用的，只是MUA对MTA，因为它是提交端口）。而且它允许更容易的管理。此外，在MTA方面，强制所有本地用户进行身份验证使垃圾邮件缓解变得更加容易。当他们的盒子被拥有，并窃取他们的smtp信用。您只需禁用他们的帐户/密码。当通过ip使用中继时，您需要阻止他们连接到邮件服务器（我们通过将ACL应用到他们的DSL/电缆连接来实现这一点）

如果您正在编写和MUA或MTA，则需要同时支持这两种格式。对于MUA或发送电子邮件的其他格式，它应默认为587尝试TLS和smtp身份验证，如果失败，则只能返回到465，25。
端口465的预期值是什么？SMTP身份验证？465是SSL下的SMTP。而25和587一开始是未加密的，并且可以使用starttls（如果支持启用ssl加密连接）。端口465从一开始就是SSL。身份验证是可选的，依赖于服务器。谢谢，它“单击”了您的解释。我没有想到所有入站SMTP服务器都应该有一个MX，而所有端口587服务器都没有这样的链接。端口25可以更好地分离关注点。我们将入站MX和中继服务器放在不同的盒子上，因为这使我们能够更严格地保护MX以防垃圾邮件发送者。很高兴它有帮助。rfc5321说，“邮件传输代理”（MTA）。我认为这与您上面的第1/p2行相冲突。@Ellipticalview:您的意思是“SMTP不应该由邮件客户端（MUA，邮件用户代理）使用，而只能由邮件服务器使用”？MUA=客户端，MTA=服务器。SMTP用于将邮件从一台服务器移动到另一台服务器，用户将邮件提交到服务器的方式应该是不同的。但客户端也开始使用它，今天我们有了用于MTA连接的端口25和465，以及用于MUA的端口587（称为提交），这两个端口的处理方式通常不同。我认为您的总体观点是公平的。但我也认为现在非常令人困惑的是，虽然“M”最初只指MTA、MUA和MDA的“邮件”，但现在它有时指的是“消息”，但仅指MUA。因此，我认为我们需要从一个新的首字母缩略词开始，比如输入传输代理的ITA，或者消息输入传输代理的MITA，或者消息提交传输代理的MSTA，或者MTA以外的其他名称。