【2022争霸赛*干货满满】内网无法正常发送邮件

【问题描述】

客户反馈反馈内网无法正常发送邮件的情况

【处理过程】

（1）反馈初步排查结果。

老架构设备，开启邮件安全，邮件客户端与服务器握手后2s内服务器回复响应包。

新架构设备，不开启邮件安全，邮件客户端与服务器握手后20s服务器才回复响应包。

新架构设备，开启邮件安全，邮件客户端与服务器握手后20s服务器才回复响应包。

（2）查抓取并分析新墙失败的报文(如下)，发现服务器在TCP三次握手后超过5s没有回应smtp报文，导致连接超时断开。

（3）通过以上信息，制定初步策略。

关闭安全策略，封锁、过滤等服务，判断是不是基础网络问题。

基于前一步缩小范围，查看日志，确定tcp报文路径异常点。

（4）协调测试环境出现问题，检查防火墙本身配置，未发现异常。

（5）以上未发现异常，分析网络拓扑是否存在问题，网络拓扑不复杂，理应不存在环路等问题。

（6）远程环境有问题，通过多次协商，查看邮件异常时的日志，没有错误信息，处理正常，查看邮件SMTP协议，是否存在什么机制导致延迟回包？未发现此机制。

（7）开启安全策略存在问题，尝试跳过安全策略查看问题是否还存在，通过配置白名单bypass安全策略，问题仍存在，服务器仍延迟10秒以上回应，报文如下：

（8）对比老墙和新墙的报文，如下：

老墙客户端及经过AF后的报文

新墙客户端及经过AF后的报文：

对比发现TCP MSS存在差异，修改新墙MSS值验证，仍存在问题。

对比去除option，与老墙保持一致，验证仍存在问题。

（8）通过以上信息做阶段性总结：

新架构开启邮件代理，抓包查看，tcp三次握手后，服务器回包慢，导致连接超时销毁，发送邮件失败。

老架构会将tcp握手包 option(Window Scale、SACK、NOP..)去除，代理后只保留tcp头部转发，新架构按照规范保留option字段处理，修改新架构同样去除option，服务器仍回包慢，无法抓取服务器处理，不知服务器对那个字段敏感，而导致回包慢。

新架构把邮件服务器加入白名单，只走基本转发流程，原始报文原封不动转发，不做修改，服务器仍回包慢，推测是流量本身有问题或服务器处理问题。

（9）由于缺少服务器端关键信息，分析不出原因，询问客户服务器端操作系统、邮件服务器软件版本，准备本地复现，信息如下：

邮件客户端：foxmail 7.0，7.2

服务端操作系统：windows Server 2008 R2 Enterprise

邮件服务器：Mdemon V10.1.2

（10）本地搭建好环境，尝试复现未发现问题，应该是配置和网络有差异，协商客户实际服务器查看问题。

       协商到服务器远程，由于此时已换为老墙，邮件服务器未找到历史日志，并且按照抓包工具wireshark无法使用，内部对齐下一步排查方法。

（11）下一步排查方案：

       老墙开启bypass，看不是有异常？证明报文原始就有问题，经过老墙代理之后正常了，还是新墙处理有问题

       修复下服务器wireshark(wireshark缺失dll要装微软官方库https://www.microsoft.com/zh-CN/download/details.aspx?id=40784)，使其正常抓包，拿到新墙/老墙， 开启bypass/经过代理的入口、出口、服务器报文及日志，对比下不同点。

       准备好环境和工具，技术去现场换上新墙，通过服务器日志，发现服务器响应慢是因为请求DNS超时。

       通过定位发现，服务器回应客户端邮件信息，会有两次根据客户端IP反查域名的过程，客户端IP不会绑定域名，这个过程一定是失败的，默认10s超时失败，2次请求邮件就延迟了至少20s。

       已经确认是服务器域名配置的问题，和客户协商修改服务器DNS服务器配置，如下可解决问题。

        修改配置过程中，保存发现问题，由于开始设置的邮件域名不符合通用格式，无法保存，告知客户需要将域名添加.com，即fujichinon.com，保存成功。

        修改域名后，验证发送邮件无问题，但是客户反映邮箱无法使用了，因为域名发生变更，尝试修改回来，发现邮件服务器限制更改，无法更改回来，由于客户在域名后加上.com影响范围太大，不能统一修改，需要想办法回复业务。

        查看邮件服务器帮助信息，通过修改映射，包头转译均无用，恢复修改，查看其他办法，查找Mdemon官网信息，看到有域名别名配置选项，遂尝试将域名fujichinon通过别名映射到fujichinon.com上，测试发现问题解决。

【问题原因分析】

新墙：服务器回应客户端邮件信息，会有两次根据客户端IP反查域名的过程，客户端IP不会绑定域名，这个过程一定是失败的，每次反查域名10秒超时失败，服务器继续往下进行，2次请求就导致邮件发送延迟了至少20秒。

老墙：老墙也有3秒的延迟，由于后续无法把老墙替换到客户环境中，无法进一步分析老墙行为。

【解决方案】

通过修改邮件服务器Mdemon的DNS配置，使其向本地请求快速得到回应，避免服务器延迟回应。

如果其他服务器有同样问题，可以开启DNS透明代理，让AF代理DNS报文，可减小响应时间，加快邮件收发。

注：建议邮件域名符合通用规范，目前服务器可使用fujichinon和fujichinon.com，此后新用户可配置fujichinon.com。

感谢楼主分享，文章介绍了一例无法发送邮件的排障案例，整体思路清晰，期待更多分享

感谢楼主分享，学习一下

楼主分析的很详细，不错的实战经验，小白用户一看就懂，非常好的技术干货帖，顶一个！

感谢楼主分享，学习一下

感谢楼主分享，学习一下

每天学习一点，每天进步一点。

学习一下，感谢分享！！！！！！

楼主的文章图文并茂，清晰易懂，看完这波操作可以轻松上手了，如遇到问题再向楼主请教~

学习一下，感谢楼主分享