从邮件认证超时，到 SMTP 报文级故障定位
一、案例背景：邮件延迟为什么会变成关键业务问题
在企业网络中，邮件延迟通常不会立刻被认为是严重故障。很多时候，用户只是觉得邮件晚到几分钟，似乎并不影响整体业务运行。
但在某些场景下，邮件延迟会直接造成业务中断。例如 Microsoft 365 登录验证、门户网站注册、账号激活、密码重置、工单系统访问等流程，往往依赖邮件接收一次性验证码或认证链接。一旦邮件传输时间超过认证窗口，用户就会遇到登录失败、注册失败或无法访问关键业务系统的问题。艾体宝 Profitap 的案例正是这种情况：组织并非完全收不到邮件，而是部分邮件出现延迟，导致基于邮件的认证流程超时。
更麻烦的是，这类问题具有间歇性。它不是所有邮件都失败，也不是固定某一个发件方失败，而是 Apple、Google、Microsoft 等多个来源的邮件都可能受影响，但只有约一部分连接最终超时。间歇性故障使传统日志分析很难直接定位根因，因为日志通常只能记录“连接超时”这一结果，却无法完整还原协议交互过程。
二、受影响的邮件链路：问题可能出现在多个节点
该组织的邮件传输路径大致如下：
外部发送客户端
→ 发送方邮件服务器
→ 受影响组织的互联网边界防火墙
→ DMZ 区域的邮件传输代理 MTA
→ DMZ 防火墙
→ 内部 Exchange 邮件服务器
从架构上看，邮件在进入企业内部邮箱系统之前，需要经过互联网边界防火墙、DMZ 区域的 MTA，以及内部侧防火墙等多个节点。任何一个节点在 SMTP 会话处理、报文检查、地址转换或安全策略执行过程中出现异常，都可能导致邮件延迟或连接超时。
排障团队首先回溯故障发生前的变更，发现近期有两项变化值得关注：一是新部署了一套 Mail Transfer Agent，二是互联网边界防火墙升级到了新的软件版本。这两个变化都与邮件链路直接相关，因此成为最先排查的对象。
三、第一阶段排查：日志没有给出答案
管理员首先检查边界防火墙日志。结果显示，防火墙没有记录丢包，IPS 日志中也没有明显拦截事件。防火墙内置的 MTA 功能已经关闭，DNAT 规则也正常命中。也就是说，从防火墙日志角度看，似乎没有发现异常。
随后，管理员检查 DMZ 区域中的 MTA 日志。该 MTA 是基于 Postfix 的虚拟设备，日志中只能看到来自源端连接的超时信息。典型表现是：客户端连接建立后，MTA 等待后续 SMTP 命令，但直到超时也没有收到有效命令，最后断开连接。
到这里，问题进入了一个常见排障困境：
因此，继续看日志已经不足以判断根因。真正需要确认的是：SMTP 会话中的报文到底是如何交互的，客户端有没有发送后续命令，服务器有没有返回正确响应，中间防火墙有没有修改、丢弃或阻断某些报文。
四、第二阶段排查：转向数据包分析
在日志无法解释问题后，分析人员决定进行数据包级排查。由于链路中涉及多个组件，他们没有只在一个点抓包，而是在两个关键位置进行多点位抓包：
第一个位置是互联网边界防火墙的 WAN 接口，用于观察外部邮件流量进入企业网络前的状态。
第二个位置是 MTA 与防火墙之间，用于观察邮件流量穿越防火墙之后是否发生变化。
这个选择很关键。单点抓包只能证明某个位置看到什么，无法判断报文是在进入防火墙前就异常，还是在穿越防火墙后被改变或丢弃。多点位抓包可以把同一条连接在不同链路位置上的表现进行对比，从而定位问题发生在哪一段路径。
特别说明，该数据中心此前没有预先部署 TAP。由于链路负载较高，团队没有采用 SPAN 镜像或主机侧抓包，而是使用 ProfiShark 以 inline 方式接入两个关键位置，尽量避免因为镜像口性能限制或主机抓包能力不足造成丢包。
这也是 ProfiShark 在该案例中的核心作用：它不是替代 Wireshark 做协议分析，而是提供更可靠、更接近真实链路状态的数据包采集能力。Wireshark 负责分析，ProfiShark 负责把关键链路上的真实报文完整采集下来。
五、第一次发现：MTA 的 SMTP Greeting 格式异常
抓包完成后，分析人员在 Wireshark 中根据 MTA 日志中的源 IP 进行过滤，并追踪对应的 TCP Stream。首先可以确认的是，TCP 三次握手是成功的。这说明问题不是基础网络不可达，也不是 TCP 建连失败。
真正的异常出现在 SMTP 会话开始阶段。SMTP 服务器在建立连接后会返回 220 Greeting，告诉客户端服务已经就绪。正常情况下，单行 SMTP 回复应当使用状态码后接空格的格式，例如：
而在多行回复中，前面的行可以使用状态码后接连字符，最后一行必须以状态码后接空格作为结束。例如：
RFC 5321 对 SMTP 回复格式有明确规定，多行回复中除最后一行外可以使用连字符，最后一行需要用空格表示回复结束。
该案例中的 MTA 返回了类似 220-域名 的格式，但它实际上只有一行回复。这会让部分 SMTP 客户端误以为服务器还没有完成完整的 Greeting，于是客户端继续等待正确的 220 响应，而不是立即发送 EHLO 命令。
于是，双方进入一种协议状态错位：
从日志看，好像是客户端没有继续发送命令；但从数据包看，真正原因是 MTA 的 SMTP Greeting 格式异常，导致客户端没有进入下一步 SMTP 交互。
排障团队随后向 MTA 供应商提交问题。供应商通过补丁修复了错误的 Greeting 消息。
六、第二次发现：防火墙仍在异常处理 EHLO 报文
MTA Greeting 修复后，问题并没有完全消失。于是团队再次使用 ProfiShark，在互联网边界防火墙的外侧接口和 DMZ 接口重新抓包。
这次对比发现了新的异常：在防火墙外侧接口，可以看到客户端不断重传 EHLO 报文；但在 DMZ 侧接口，却看不到这些 EHLO 报文。与此同时，MTA 在 DMZ 侧持续重传 220 Greeting。
这个现象说明，EHLO 报文在穿越防火墙的过程中出现了问题。客户端确实发出了 EHLO，但该报文没有到达 MTA。MTA 因为没有收到 EHLO，只能继续等待或重传 Greeting。更关键的是，防火墙日志并没有记录这些报文被丢弃。
进一步排查后，防火墙供应商确认：即使 SMTP inspection 已经关闭，防火墙内置的 MTA/SMTP 相关逻辑仍然在检查 SMTP 报文，并在特定情况下影响了 EHLO 报文转发。最终，防火墙供应商提供补丁，确保当所有 SMTP 检查功能关闭时，防火墙不再继续检查或干预 EHLO 报文。
七、完整根因：不是一个问题，而是两个问题叠加
这个案例的复杂之处在于，它并不是单一故障，而是两个问题先后暴露：
第一，MTA 返回的 SMTP Greeting 格式不符合预期，导致部分客户端等待正确响应，无法继续发送 EHLO。
第二，防火墙在 SMTP 检查关闭的情况下，仍然对 SMTP 报文进行处理，导致 EHLO 报文没有正常到达 DMZ 侧的 MTA。
这也解释了为什么前期排查非常困难：MTA 日志只能看到“客户端超时”，防火墙日志又没有显示丢包。每个系统从自己的视角看都没有完整答案，只有通过链路上的原始报文对比，才能还原真实过程。
八、ProfiShark 在该案例中的价值
这个案例并不是简单证明“ProfiShark 可以抓包”，而是说明在复杂网络故障中，高保真、多点位抓包可以解决日志无法回答的问题。
它的价值主要体现在三个方面。
设备日志反映的是设备软件认为发生了什么，但不一定等于链路上真实发生了什么。尤其是当防火墙没有记录丢包、IPS 没有记录拦截、应用日志只显示超时时，日志之间很容易互相“甩锅”。
通过 ProfiShark 抓到原始数据包后，工程师可以直接看到 SMTP 会话中每一个关键报文的发送、重传、缺失和响应情况。
如果只在 MTA 一侧抓包，只能看到 MTA 没有收到 EHLO；但无法证明 EHLO 是客户端没发，还是中间设备丢了。
如果只在防火墙外侧抓包，只能看到客户端发出了 EHLO；但无法证明该报文有没有进入 DMZ。
多点位抓包的价值就在于对比：外侧有、内侧没有，就可以把问题范围锁定到防火墙处理路径上。
在高负载链路中，SPAN 镜像可能受交换机资源、镜像口带宽、转发策略影响，导致抓包不完整。主机侧抓包也可能受操作系统、网卡驱动、CPU 负载影响。团队选择 inline 模式接入 ProfiShark，就是为了降低这些采集误差，获得更可靠的链路级证据。
九、对客户沟通时可以怎么总结
这个案例可以提炼成一个很适合售前沟通的表达：
关键业务故障不一定能通过日志定位。尤其当问题发生在协议交互、安全设备中间处理或跨设备链路路径上时，日志往往只能提供局部结论。ProfiShark 的价值在于帮助工程师快速获取可信的原始数据包证据，把“怀疑是某个设备的问题”转化为“在哪个接口、哪个报文、哪个协议阶段出现异常”的可验证结论。
如果面向客户进一步说明，可以强调：
对于邮件、认证、金融交易、工业控制、视频会议、VoIP 等对时延和协议完整性敏感的业务，间歇性故障往往不是简单的连通性问题，而是协议状态、报文转发、安全检查、设备补丁或中间路径处理共同作用的结果。此时，只有在关键链路上进行高保真抓包，才能获得足够可信的排障证据。
十、结论
这个案例最终说明了一个很朴素但重要的原则：
日志可以帮助缩小范围，但真正的网络真相往往在数据包里。
ProfiShark 的作用不是替代工程师判断，而是为工程师提供可靠证据。当多个系统日志互相矛盾，或者都没有记录明显错误时，原始数据包才是判断问题边界、还原协议过程和推动供应商修复的关键依据。
扫一扫
364
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
