端口465和587有什么区别?


245

这些端口465587都用于发送邮件(提交邮件),但是它们之间的真正区别是什么?


1
唯一的区别是正式标准和465端口是否支持旧版?
Ilia Rostovtsev

iana的“服务名称和传输协议端口号注册表”是建议使用端口的正式指南;在SMTP over SSL上使用465是非官方的。阅读有关SMTP中的端口的信息。iana的官方用法对于TCP和UDP传输协议并不总是相同的。注意:如果您是SMTP 服务器管理员,则可以控制使用哪个端口;如果您是客户端,则只会获得可用的端口。
gerryLowry 2014年


Answers:


235

SMTP协议:smtps(端口465)v.msa(端口587)

端口465和587用于电子邮件客户端到电子邮件服务器的通信- 使用SMTP协议发送电子邮件。

端口465用于smtps
SSL加密在任何SMTP级别的通信之前自动启动。

端口587用于msa
,几乎类似于标准SMTP端口。 MSA应该在身份验证后(例如在SMTP AUTH之后)接受电子邮件。它有助于阻止传出垃圾邮件时的netmasters DUL范围可以阻止传出到SMTP端口(端口25)连接。
SSL加密可以通过以下方式启动如果服务器支持,并且您的ISP不过滤服务器的EHLO答复, SMTP级别 STARTTLS命令(2014年报告)


MTA到MTA通信(邮件服务器到邮件服务器)使用端口25。它可能用于客户端到服务器的通信,但目前不推荐使用。标准SMTP端口无需身份验证即可接受来自其他邮件服务器的电子邮件发送到其“内部”邮箱。


7
标准SMTP端口无需身份验证即可接受来自其他邮件服务器的电子邮件 -实际上在技术上不正确。标准25端口可以既使用身份验证也可以不使用MTA的配置来传输邮件。
Ilia Rostovtsev

2
普通MTA的@Ilia标准SMTP端口无法拒绝(所有)未经身份验证的SMTP连接。
AnFi 2013年

1
Postfix呢?它不允许默认情况下中继邮件,而仅允许来自同一网络的连接吗?
Ilia Rostovtsev

4
@Ilia也有到本地电子邮件域的传入邮件
AnFi 2013年

6
请注意,虽然端口非正式,但端口465为最终用户提供了更多保证,即他们确实在通过加密通道进行通话。端口587(TLS是可选的)意味着最终用户可以通过未加密的通道提供其凭据。电子邮件客户端就是它们,您不能保证MUA甚至会警告用户连接已降级。
sporker '17

132

587和465

这些端口分配由Internet号码分配机构(IANA)指定

  • 端口587[SMTP]邮件提交(SMTP-MSA),该服务接受来自电子邮件客户端(MUA)的电子邮件提交。在RFC 6409中描述。
  • 端口465SSM的URL集合目录 (与电子邮件完全无关)

从历史上看,最初计划将端口465用于SMTP上的SMTPS加密和身份验证“包装器”,但很快就弃用了该端口(在几个月内和15年前),而推荐使用SMTP上的STARTTLS(RFC 3207)。尽管如此,可能仍有许多服务器支持不赞成使用的协议包装程序,主要是为了支持实现SMTPS的较旧客户端。除非您需要支持此类较旧的客户端,否则SMTPS及其在端口465上的使用只不过是一个历史脚注。

绝望的混乱和不精确的术语, SSL经常被用来表示SMTPS包装器,而TLS 则被用来表示STARTTLS协议扩展。

完整性:端口25

  • 端口25简单邮件传输(SMTP-MTA),该服务接受来自其他服务器(MTA或MSA)的电子邮件提交。在RFC 5321中描述。

资料来源:


1
很好的技术说明,当时正在寻找SSL与TLS。
13年

11
SMTPS and its use on port 465 should remain nothing more than an historical footnote. 除了Gmail和大多数其他电子邮件提供商使用SSL或SMTPS的端口465。无论IANA指明什么,这都是现实。
Eric J.

6
@EricJ。...但是gmail也支持端口587。您知道Google内部使用的端口吗?否则,他们支持 465 的事实并不能真正证明它是首选或什至是常用的证据。
Parthian Shot

2
好吧,我们现在是2018年,我看不到有任何港口成为历史。456仍然被大玩家使用。另外,我想编辑我的答案,以反映IANA是一个烂摊子,他们仍然不同意,如果他们应该使用456或不- RFC 8314 tools.ietf.org/html/rfc8314#page-6 - When a TCP connection is established for the "submissions" service (default port 465), a TLS handshake begins immediately-这RFC被引用您的“端口456”链接:)-注册日期:

1
“集合”的拼写现已在iana.org上
arni,

19

RFC 8314的发布已更改了对该问题的正确答案。结果,端口465和587都是邮件提交代理(MSA)的有效端口。端口465需要在连接建立时协商TLS / SSL,而端口587如果选择协商TLS,则使用STARTTLS。IANA注册中心已更新,允许为此目的合法使用端口465。对于邮件中继,仅使用端口25,因此STARTTLS是使用邮件中继进行TLS的唯一方法。将邮件中继和邮件提交视为两个碰巧使用相似的有线协议的两种非常不同的服务(具有许多行为差异,如要求身份验证,不同的超时时间,不同的消息修改规则等),将很有帮助。


使用端口465还是587更好?
亚伦弗兰克

如果您正在运行公共SMTP服务:两者都是出于兼容性。如果它是私有的,则最好在465上使用隐式TLS,除非您必须支持不支持它的客户端。支持摘录:“但是,为了最大程度地使用加密来进行提交,最好在过渡期中支持这两种通过TLS进行消息提交的机制。因此,客户端和服务器应在端口587和587上同时实现STARTTLS在此过渡期间,端口465上的隐式TLS” tools.ietf.org/html/rfc8314#section-3.3
Alain O'Dea

4

端口465: IANA已为该端口重新分配了新服务,并且该服务不应再用于SMTP通信。

但是,由于它曾经被IANA识别为有效,因此可能有旧系统只能使用此连接方法。通常,仅在您的应用程序需要时才使用此端口。快速的Google搜索,您会发现许多消费者ISP文章,建议将465端口作为推荐设置。希望这很快结束!它不符合RFC。

端口587: 这是默认的邮件提交端口。当邮件客户端或服务器提交要由适当的邮件服务器路由的电子邮件时,它应始终使用此端口。

除非您被上游网络或托管提供商明确阻止,否则每个人都应考虑使用此端口作为默认端口。此端口与TLS加密相结合,将确保电子邮件安全提交,并遵循IETF制定的准则。

端口25: 此端口继续主要用于SMTP中继。SMTP中继是电子邮件从电子邮件服务器到电子邮件服务器的传输。

在大多数情况下,现代SMTP客户端(Outlook,Mail,Thunderbird等)不应使用此端口。传统上,它被住宅ISP和Cloud Hosting Provider阻止,以抑制从受感染计算机或服务器中继的垃圾邮件数量。除非专门管理邮件服务器,否则您的计算机或服务器上不应有通过该端口的流量。


1

我不想命名,但是似乎有人完全错了。引用标准机构声明如下:通过TLS协议提交465 tcp消息提交[IESG] [IETF_Chair] 2017-12-12 [RFC8314]

如果您愿意,可以阅读参考的RFC。

这似乎清楚地表明,端口465是强制加密通信的最佳方式,并确保已就位。587端口不提供此类保证。


为什么使用端口465更好?
亚伦弗兰克

1

我一直在使用端口465。

丹诺顿答案已经过时。正如他和Wikipedia所说,端口465最初计划用于SMTPS加密,并在15年前迅速弃用。但是,许多ISP仍在使用端口465,尤其是为了符合RFC 8314的当前建议,该建议鼓励使用隐式TLS而不是对端口587使用STARTTLS命令。(请参阅第3.3节)。使用端口465是与充当邮件提交代理(MSA)的SMTP服务器开始隐式安全会话的唯一方法。

基本上,RFC 8314建议放弃明文电子邮件交换,并且在可能的情况下,仅在隐式TLS会话中使用所有三种常见的IETF邮件协议。那么,对于SMTPS,IMAP4S和POP3S,建议的安全端口分别为465、993和995。

尽管RFC 8314当然允许继续使用端口587和STARTTLS命令使用显式TLS,但是这样做会使邮件用户代理(MUA,邮件客户端)向降级攻击开放,中间人拦截了STARTTLS请求升级到TLS安全性但拒绝它,从而迫使会话保持为明文形式。


4
他是正确的。仅仅因为ISP滥用了它并且没有更新他们的文档并不能使它不正确。他没有说它没有被使用-只是它不是遵循RFC的一种做法。换句话说,您应该在电子邮件中使用25和587,并且出于某种原因,只有在必须使用465时才使用465。
dodexahedron
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.