Docker-Mailserver中Rspamd拒绝asciinema邮件的故障排查与解决方案

问题背景

在使用Docker-Mailserver搭建邮件服务器时，用户发现来自asciinema.org的登录验证邮件被Rspamd直接拒绝，而非被标记为垃圾邮件。邮件服务器日志显示这些邮件因被识别为垃圾邮件而被拒绝，但通过其他邮件服务商测试发现这些邮件评分良好（10/10），表明问题可能出在本地服务器配置上。

故障现象分析

邮件服务器日志中关键错误信息包括：

1. 主机名解析不匹配警告："hostname wfhigh3-smtp.messagingengine.com does not resolve to address 64.147.123.154"
2. Rspamd拒绝记录："milter-reject: END-OF-MESSAGE from unknown[64.147.123.154]: 5.7.1 Spam message rejected"

Rspamd日志详细显示邮件因"HFILTER_HOSTNAME_UNKNOWN"规则被扣6分，导致总分超过11分的拒绝阈值。这表明Rspamd无法正确验证发送服务器的反向DNS记录。

根本原因

经过深入排查，发现以下关键问题点：

1. DNS解析问题：Rspamd在容器内部无法正确完成DNS反向查询，导致主机名验证失败。虽然手动测试dig命令可以解析，但Rspamd使用的DNS解析路径可能不同。

2. 容器网络配置：Docker容器的hostname设置与DNS解析存在冲突。使用compose文件中的hostname参数而非环境变量OVERRIDE_HOSTNAME会导致容器内部DNS解析异常。

3. Rspamd严格规则：相比SpamAssassin，Rspamd对主机名验证更为严格，对DNS解析失败的情况惩罚更重。

解决方案

临时解决方案

对于急需解决问题的用户，可以采用以下临时方案：

1. 切换至SpamAssassin：在Docker-Mailserver配置中禁用Rspamd，启用SpamAssassin和OpenDKIM组合。这需要：

   • 修改配置环境变量
   • 迁移DKIM密钥文件到正确位置
   • 确保DNS记录更新

2. 调整Rspamd阈值：通过修改Rspamd配置文件，提高垃圾邮件判定阈值或禁用特定规则。

长期解决方案

1. 修复DNS解析：

   • 确保容器使用可靠的DNS服务器（如1.1.1.1）
   • 检查并修复容器内部的resolv.conf配置
   • 验证Rspamd实际使用的DNS服务器配置

2. 正确设置容器hostname：

   • 避免在compose文件中使用hostname参数
   • 改用OVERRIDE_HOSTNAME环境变量设置邮件服务器主机名

3. Rspamd规则调优：

   • 针对可信发件人（如asciinema.org）设置白名单
   • 调整HFILTER模块的敏感度
   • 确保灰名单(greylisting)设置合理

技术细节深入

Rspamd的DNS验证机制

Rspamd在验证邮件时会执行严格的DNS检查流程：

1. 通过IP地址查询PTR记录获取主机名
2. 验证该主机名是否有有效的A记录
3. 确认A记录解析的IP与连接IP匹配

这一机制能有效阻止大量垃圾邮件，但也对DNS解析可靠性要求极高。任何环节失败都可能导致合法邮件被误判。

Docker网络配置最佳实践

邮件服务器容器对网络配置特别敏感，建议：

1. 使用自定义网络而非默认桥接网络
2. 显式指定DNS服务器
3. 避免hostname参数与内部服务冲突
4. 定期检查容器网络连通性

经验总结

1. 分层排查：邮件服务器问题应从底层网络开始，逐步向上排查应用层配置。

2. 组件替代测试：通过临时切换组件（如Rspamd到SpamAssassin）可以快速定位问题范围。

3. 日志分析：Rspamd的详细日志是诊断垃圾邮件过滤问题的宝贵资源，应学会解读各规则得分。

4. 环境一致性：开发测试环境与生产环境的微小差异可能导致难以预料的问题，保持环境一致至关重要。

通过系统性地应用这些解决方案和最佳实践，用户可以构建更稳定可靠的Docker-Mailserver邮件系统，避免类似邮件被错误拒绝的问题。