我是一名软件工程师,编写了自己的 SMTP 交付代理。我最近为我的软件添加了 STARTTLS 支持,在进行一些测试时,我注意到 Google 的 SMTP 传输代理没有STARTTLS
向我的服务器发送命令。这让我非常惊讶!
有人知道为什么谷歌的邮件服务器甚至不尝试将连接升级为安全连接吗?
我的日志显示许多传输代理正在升级其连接,包括微软运营的传输代理。
我的服务器正在接受端口 25、587 和 2525 上的连接。我做了一些实验,以确定如果STARTTLS
通过暂时关闭端口 25 而强制连接到 587 而不是 25,Google 的传输代理是否会发送。但那时我完全停止了传送尝试。我的理解是端口 25 是用于中继电子邮件的标准端口,而 587 是提交的标准端口,所以我想这是有道理的。
以下是来自 Microsoft 的 MTA 的日志示例:
[20:00:00 INF] Session established
< 220 ***REDACTED***
> EHLO NAM11-DM6-obe.outbound.protection.outlook.com
< 250-STARTTLS
< 250 8BITMIME
> STARTTLS
< 220 Go ahead
[20:00:01 INF] Connection is now using TLS
> EHLO NAM11-DM6-obe.outbound.protection.outlook.com
< 250 8BITMIME
> MAIL FROM:<***REDACTED***>
< 250 ok
> RCPT TO:<mstest@***REDACTED***>
< 250 ok
> DATA
< 354 ok
…
当 Google 连接到我的服务器时:
[20:10:00 INF] Session established
< 220 ***REDACTED***
> EHLO mail-ed1-f45.google.com
< 250-STARTTLS
< 250 8BITMIME
> MAIL FROM:<***REDACTED***>
< 250 ok
> RCPT TO:<***REDACTED***>
< 250 ok
> DATA
< 354 ok
…
如您所见,没有尝试升级连接。我仍在学习协议和惯例,因此如果有原因,并且我可以鼓励更多传输服务器升级到 TLS,我想知道我能做些什么。或者,如果只是出于我无法控制的其他原因,那么这也是有用的信息。
谢谢!
答案1
描述服务器应如何响应 EHLO 命令的文档位于rfc5321 4.1.1.1,与你发送的内容最明显的区别是您的回复中的第一行包含您的域名,之后才包含扩展名可能会被列出。
引用以下例子rfc2487 6- 在 STARTTLS 提供之前有域名(和习惯性问候):
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.ietf.org
S: 250-mail.imc.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
我不会太担心微软会尝试这个命令,尽管它没有正式宣布可用。这一次他们做对了,服务器有多坏并不重要,潜在的私人消息应该通过具有一定隐私级别的连接发送。此外,在教育之外,从头开始重新实现这些东西可能不是最好的解决方案。