为什么我要说服开发人员使用端口587进行所有SMTP通信?

goo*_*ate 8 pop3 exchange-server smtp rfc spam

将端口587用于所有客户端到MTA通信的趋势越来越明显.它位于标准跟踪RFC:http://www.ietf.org/rfc/rfc2476.txt

我的问题是"为什么?".为什么有两个SMTP服务器实例在同一台服务器上运行,如果它们都做同样的事情?它提供了什么安全功能,除了给我两个作为管理员进行故障排除的事情.

这似乎是不必要的复杂性,除非ISP阻止端口25,否则不需要.即使这样,如果ISP阻止端口25以防止垃圾邮件,它只是意味着它只需要更多的时间,直到端口587也被阻止,我们将不得不完全使用不同的端口.

看起来我们正在为自己创造更多的工作,而不是解决问题并开始验证SMTP

Dar*_*ust 10

我快速阅读了RFC,他们的想法是将SMTP世界分为两个方面:传输邮件(这就是为SMTP开发的)和提交邮件.

作者认为SMTP不是由邮件客户端(MUA,消息用户代理)使用,而是仅由邮件服务器使用,将邮件路由到其目的地.他们认为,如果您以这种方式划分SMTP世界,那么您可以编写一个SMTP服务器,该服务器只能由MUA访问,然后能够执行并使假设成为"正常",转发SMTP服务器应该/可能不会."普通"SMTP服务器始终称为MTA,即邮件传输代理.作者建议将新类型的SMTP服务器MSA命名为Message Submission Agent.

他们似乎认为这会使实现两种服务器类型更容易,甚至可能更安全.RFC解释了与MTA相比MSA需要有什么不同.例如,RFC要求使用授权,而原始SMTP协议没有使用授权(稍后添加了SMTP AUTH,它似乎是RFC 2476;但是SMTP AUTH本身是后来在RFC 2554中指定的,已被替换通过RFC 4954).

需要将消息从各种源中继到各个目标的MTA无法对每条消息使用身份验证(另一台服务器应如何向您的服务器进行身份验证?).但是,作为消息起点的MSA可以而且必须要求来自其对等方(邮件客户端)的身份验证.虽然MTA必须不加改变地传递消息,除了添加Received标题,MSA可以"清理"电子邮件,例如填写缺少的标题和类似的东西.


Doo*_*oon 7

请参阅.

http://www.uceprotect.net/downloads/MAAWGPort25English.pdf

我认为您缺少的是端口587仅通过身份验证.无论收件人是否是本地收件人,您都不应接受端口587上未经身份验证的电子邮件.我们(作为ISP)阻止出站端口25以防止直接到mx的垃圾邮件.例如来自僵尸计算机.阻止我们的住宅/动态用户群在端口25上发送出站(我们仍允许从端口25上的IP空间进行未经过身份验证的中继),滥用报告的下降率为85%以上.

ISPS不会开始阻止587(好吧,他们不应该因为它不是MTA使用MTA,只有MUA到MTA,因为它是提交端口).它允许更容易的管理.同样在MTA端,强制所有本地用户进行身份验证可以更轻松地减少垃圾邮件.当他们的盒子被拥有,并偷走他们的smtp信誉.您需要做的就是禁用他们的帐户/密码.当通过ip使用中继时,您需要阻止它们连接到邮件服务器(我们通过dnyamically将ACL应用于其DSL/Cable连接来实现此目的).

如果您正在编写MUA或MTA,则需要同时支持两者,对于MUA或发送电子邮件的情况,它应该默认为587尝试TLS和smtp auth,并且只能失败回到465,如果失败了.