导致服务器乱发信息,沙雕发信服务器引发的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的网站(非常的棒，这个工具在后续发挥了很大的作用)

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

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邮箱邮件头的分析)，鉴于沙雕服务器的一股清流操作，它不会重试，请问它是如何办到的呢？

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