参考 Postfix 队列管理与网络诊断最佳实践

邮件投递延迟是运维中最常见的用户体验问题。收件方在发送邮件后迟迟未收到，可能的原因涉及网络、认证、收件方策略和发送方队列管理等多个方面。

延迟的分类与定位

发件方内部延迟

邮件在发件方 MTA 内部停留的时间可以进一步细分：

阶段	Postfix 日志标记	典型延迟原因
SMTP 提交阶段	smtpd → cleanup → qmgr	极高的并发提交导致 cleanup 队列阻塞
DSN 处理	qmgr → bounce/smtp	退信生成过程占用系统资源
SMT 阶段	smtp → 远程 MX	DNS 查询超时、TLS 握手、连接队列等待
远程 MX 响应	远程 MTA	收件方反垃圾策略验证、邮件队列

收件方策略导致的延迟

邮件的延迟可能源于收件方邮件服务器的策略配置：

• 灰色名单（Greylisting）：常见于很多自建邮件系统。收件方首次收到来自未知 IP 的邮件时返回 4xx 错误，要求发件方重试。合法发件方会在 15-30 分钟后重试。配置确认过的发件列表可以避免 greylisting
• 速率限制：当短时间内的邮件数量超过收件方的限制阈值时，收件方返回 4xx 错误要求发件方延迟重试
• DNSBL 检查：收件方在 SMTP 会话期间检查发件 IP 的 DNSBL 状态，超时可能导致延迟

Postfix 延迟监控和调优

延迟指标收集

Postfix 在每个邮件投递日志行中包含 delay 字段，格式为 delay=秒数，表示邮件从在 qmgr 中入列到投递成功（或失败）的总时间。

常见的延迟调优方案

• DNS 缓存：通过 nscd 或 dnsmasq 启用 DNS 缓存可以显著减少 MX 查询时间
• 并发连接数：增加 Postfix 的 smtp_destination_concurrency_limit 可以加快邮件投递速度
• greylisting 白名单：收集被 greylist 影响的域，通过 Postfix 的 sender_dependent_default_transport_maps 绕过
• 邮件大小限制：合理配置 message_size_limit 可以减少大文件（附件）传输导致的重试次数
• Outbound TLS 会话复用：启用 TLS 会话缓存可以减少远程 MX 连接时的 TLS 握手时间

排障工具

• swaks：灵活的 SMTP 测试工具，可以精确控制每个 SMTP 命令之间的延迟
• dig +trace：逐层诊断 DNS 查询延迟和 MX 缓存问题
• mtr (My TraceRoute)：结合 traceroute 和 ping 的网络诊断工具，排查网络路径延迟
• tcptraceroute：针对 TCP 端口的 traceroute，用于诊断 MX 25 端口的网络路径