沙雕发信服务器引发的TLS思考

背景：

某发信服务器在发信日志里一直显示TLS Fail 看protocal log 发现一直出现“454 TLS not available due to temporary reason” 错误，也有其他的服务器出现类似错误，但是其他服务器接着会重试，使用非TLS连接发送成功。这个服务器它只尝试一次就会放弃，和常见邮件发送服务器的行为多次尝试重发相比，简直就是一股清流。但是这个服务器发往QQ邮箱的邮件可以收到。

信息2：因为邮件头信息中会显示关于TLS的信息，所以我把QQ邮箱里的邮件头弄了出来，发现QQ邮箱的邮件传输是没有走TLS的。

初步判断：

1. 没有重传机制，这个是致命伤。

2. 对方服务器的TLS肯定在某个地方有问题。可能是证书没有配置好、可能是网络问题导致证书协商失败。

初步解决：

1. 查到对方的发信IP地址只有一个，我把该服务器IP的TLS传输强制设置为非加密。问题解决，可以收到信了，似乎到此就该结束了。但我还是有个疑问没有解决，为什么QQ邮箱的就成功了，腾讯的邮箱也是使用了TLS Prefer,就是你用STARTTLS 对方就会尝试TLS 加密，如果不支持TLS就走非加密，那么为什么和QQ邮箱协商成功了呢。QQ邮箱不可能对该地址做特殊设置的。

尝试解释454 错误：

“454 TLS not available due to temporary reason”出现的原因是什么，这个疑问一直在脑子里转悠，搜索引擎搜的内容里面，基本没有对这个问题进行详细解释，RFC也是一笔带过的解释了下454 代码的意思。所以我只能通过抓包对比来发现问题所在。

下图是我抓包看到的同样出现过454 TLS not available temprorary reason的其他服务器的行为，和沙雕服务器相比，就多了个使用非TLS重试的动作,其他似乎找不到原因了:

1. Client Hello 后，我方回复454

2. 但是对方可能没有意识到，又接着发来了识别不了的Command

3. 我方看到识别不了的command ,断开连接

4. 对方重新传输 (包50351 开始重新握手到50371 之间使用非TLS进行重新发送）

新发现：

在出现454 代码之前，仅有一个Client Hello 的交互，难道是这个地方出问题了么？对方的证书是不是有问题？带着这个问题，我使用了一个测试ssl的网站（非常的棒，这个工具在后续发挥了很大的作用）

https://www.checktls.com/TestReceiver

对对方服务器进行了测试，发现了几个关键点：

1. 对方支持TLS协商，TLS是可选项

2. SSL 版本是v1.0    （检查自己的TLS版本支持配置，仅勾选了V1.1和V1.2,这个是454 TLS not available due to temporary reason的真正原因么？)

3. 对方的证书和hostname 不匹配  （检查自己并没有校验服务器名称和证书的匹配情况）

再次验证：

既然QQ邮箱可以发送成功，那么QQ邮箱对TLS的支持是怎样的呢？

对smtp.qq.com 进行TLS测试，发现默认使用的是TLS1.2

那么对TLS v1.0 支持情况如何呢？ checktls.com 支持指定TLS 版本、TLS加密协议进行测试。

在测试选项里，自定义TLS版本

测试证明，QQ邮箱支持TLS v1.0

那么沙雕服务器的TLS版本支持情况如何？一样拿这个工具测试（参考前面的图可以看出对方应该只支持v1.0 也就是TLSv1)

优化配置:

这个note 小字部分，不看还好，看的时候误让我理解为TLSv1.2 不能和v1.0 同时存在，只能v1.2和v1.1 或者v1.1和v1.0 这样的组合。结果实际意思是TLS v1.0 和TLS1.2 一起存在时，必需要启用V1.1 ，尼玛…………..英文不好就要被歧视

发自灵魂的再次拷问：

就算QQ邮箱的TLS是可选项、沙雕服务器的TLS也是可选项，QQ邮箱也支持TLSv1.0 ,那么为什么QQ邮箱还是走了非TLS传输呢（参见背景部分的QQ邮箱邮件头的分析），鉴于沙雕服务器的一股清流操作，它不会重试，请问它是如何办到的呢？

欲知后事如何：

请等我的最终抓包图，等待沙雕服务器发送连接可能要一周，运气好可能改天