灰名单（Greylisting）延迟多久合适？会不会导致丢信？

灰名单对首次出现的（客户端 IP、发件人、收件人）三元组返回 4xx 临时拒绝。RFC 5321 要求合规 MTA 收到 4xx 后必须重试，而大量批量发送工具不实现重试队列，于是一次退避就把它们过滤掉了。RFC 6647 把这一机制定位为「低成本、对特定类型滥用有效」的手段，同时明确它会引入投递延迟。

关键推论：灰名单拦的是「不重试的发送方」，不是「内容可疑的邮件」。它对已被攻陷的合法邮件系统发出的钓鱼邮件几乎无效，不能替代内容与认证检查。

RFC 6647 讨论了延迟窗口的权衡：太短则重试即通过、过滤效果下降；太长则正常邮件延迟明显。实践区间通常在 1 到 5 分钟，多数场景取 5 分钟左右较稳妥——常见 MTA 的首次重试间隔多在数分钟到十几分钟，这个窗口既能滤掉不重试的发送方，又不会显著推高正常邮件的端到端延迟。

同时要设「首次出现的记录保留时长」：若三元组在该时间内没有重试出现（例如 4 到 8 小时），记录过期删除，避免状态表无限增长。

一旦某三元组重试成功，应把它加入白名单并给足够长的有效期（常见 30 至 40 天），否则每月都会对同一条正常通信重新延迟一次。

粒度上有一个重要调整：对使用大规模出站集群的发送方，同一封邮件的重试可能来自不同 IP，严格三元组会导致反复延迟。缓解办法是把客户端 IP 归并到 /24（IPv4）或更粗的前缀再参与匹配，或对已通过 SPF/DKIM 校验的发送域直接跳过灰名单。

时效性邮件是灰名单最大的风险面：登录验证码、密码重置、监控告警、支付通知。这类邮件延迟 5 分钟等同于失败。可操作做法是建立豁免清单，按收件人地址（如告警收件组）、按发送域（自有业务域、已签约的通知服务商域名）、按 SPF/DKIM 通过状态三个维度任选其一命中即跳过。

另一类需要豁免的是与你有稳定往来的对端 MTA。Postfix 侧灰名单一般以策略服务（SMTPD_POLICY_README 描述的 policy delegation 协议）实现，可在策略服务前用 check_client_access 直接放行白名单网段，避免请求进入策略服务。

灰名单是有维护成本的：状态表、豁免清单、延迟投诉。评估留存的判定条件是「它现在还拦下多少」——统计一个周期内因灰名单被拒且此后再未重试的连接数占总入站连接的比例。若该比例已降到很低（说明滥用流量已被前置的连接级过滤或信誉判定拦掉），继续承担延迟成本就不划算，应当退役或缩小到仅对无认证、无信誉的源生效。