"spam"不是一个标签，而是一个 需要被证明的指控——每一封合法邮件误入 Junk 文件夹，都是对 SPF/DKIM 鉴权体系 的一次无声嘲讽。——FreeLamp.com
本文看点
01
定位误报背后的三个"帮凶"符号
02
白名单域名 + 组合规则精准对冲误判分
03
从 Junk 移回 19 封邮件的完整操作流程
01
BACKGROUND
背景
我的邮件服务器（Postfix + Dovecot + rspamd，作为本域 MX）跑了一段日子后，发现本地客户端（Thunderbird）的 Junk 文件夹里积压了很多 明明是正常订阅的新闻通讯 ：Debian 邮件列表、McKinsey 邮件、LinkedIn 邮件、dev.to 邮件、Amazon/AWS 营销邮件。它们的共同点：都通过了 SPF/DKIM ，属于高信誉机构，但 rspamd 仍给了高分，被判定为垃圾。
02
ROOT CAUSE
根本原因分析
用 rspamc 对几封误报邮件重新打分，定位到三个 "帮凶"符号 ：
| 符号 | 默认分值 | 触发原因 |
|---|---|---|
| FORGED_SENDER | +5.0 | envelope sender ≠ From 头，ESP 常用子域做弹回地址 |
| FORGED_RECIPIENTS | +2.0 | 收件人 To: 是列表地址而非个人邮箱，常见于邮件列表 |
| BLACKLIST_DMARC | +6.0 | 供应商经 SES 等代发平台代表主域发送，DMARC 对齐检查标记为黑名单 |
所有误报邮件 SPF 均通过（R_SPF_ALLOW），这是判为合法的关键依据——只要发件域在白名单内且通过 SPF/DKIM，就应视为可信。
03
RULE ADJUSTMENT
规则调整
- 扩展白名单域名
在 local.d/maps.d/whitelist_domains.inc 中追加了已订阅的新闻通讯/厂商域名：mckinsey.com、email.mckinsey.com、dev.to、mail.dev.to、em4984.dev.to、linkedin.com、amazon.com、amazonaws.com 等。
- 新增三条组合规则
在 local.d/composites.conf 中追加，针对每个误报原因 精准对冲 ：
. . . composites.conf
# 对冲 FORGED_SENDER(+5.0)
TRUSTED_NEWSLETTER_PASS {
expression = "WHITELIST_DOMAINS_FROM & (R_SPF_ALLOW | R_DKIM_ALLOW)";
score = -5.0;
}
# 对冲 FORGED_RECIPIENTS(+2.0)
TRUSTED_NEWSLETTER_RECIPIENTS {
expression = "WHITELIST_DOMAINS_FROM & FORGED_RECIPIENTS & (R_SPF_ALLOW | R_DKIM_ALLOW)";
score = -2.0;
}
# 对冲 BLACKLIST_DMARC(+6.0)
BLACKLIST_DMARC_TRUSTED {
expression = "WHITELIST_DOMAINS_FROM & BLACKLIST_DMARC & (R_SPF_ALLOW | R_DKIM_ALLOW)";
score = -7.0;
}
设计要点：限定白名单域、要求强鉴权（SPF/DKIM 至少一个通过）、负分只对冲不给加成——普通垃圾邮件不在白名单内绝不吃负分，伪装白名单域的钓鱼因 SPF/DKIM 失败会被 +10 分击穿。
- 重新加载并验证
sudo systemctl reload rspamd
语法检查无警告，服务状态 active。用 rspamc 对原误报邮件重新打分， 所有邮件分数从正分压到负值 ：
| 邮件 | 调整前 | 调整后 |
|---|---|---|
| McKinsey | +4.80 | -3.00 |
dev.to +4.80 -3.00
Debian 列表 +6.20 -23.20
LinkedIn +4.80 -4.50
AWS +7.90 -9.90
所有误报分数都从正分压到负值，远低于 add_header（6 分）和 reject（15 分）阈值， 不会再进 Junk 。
04
MANUAL CLEANUP
手动处理已进 Junk 的旧邮件
- 备份与 dry-run 扫描
备份将被移动的文件，对 Junk 中每封邮件重新打分，确认哪些是"清白"邮件后再做移动。
- 改写头部并移动
对确认清白的邮件，重写头部 X-Spam: Yes → X-Spam: No，将文件从 Maildir/.Junk/cur/ 移动到 Maildir/cur/ 。原始文件先备份留档。
- 同步 Dovecot 索引（服务端）
sudo /usr/bin/doveadm force-resync -u USERNAME INBOX
sudo /usr/bin/doveadm force-resync -u USERNAME Junk
- 客户端重建（Thunderbird）
服务端 resync 完成后，在 Thunderbird 里重建索引：右键 Inbox → 属性 → 重建索引（Rebuild Index）；Junk 文件夹同样处理；执行压缩（Compact）回收空间。
「 先服务端 force-resync，再客户端重建索引——顺序颠倒时，Thunderbird 可能用本地残留缓存把修复覆盖掉。」
- 结果
本轮从 Junk 移回 Inbox 19 封 。Junk 中剩余 4 封经复核确为垃圾（诈骗/健康广告/疑似群发），予以保留。
05
BACKUP
备份与回滚
所有改动都已带时间戳备份，可一键回退：用备份覆盖原文件 + sudo systemctl reload rspamd 即可恢复。
∞
EPILOGUE
小结
根因：合法 ESP 用子域做 envelope sender / 列表 To: 地址 / 供应商代发，触发了 rspamd 的 FORGED_* 与 BLACKLIST_DMARC 误判符号 。
解法：白名单域名 + 三条"白名单域 & 强鉴权"的组合规则，精准对冲误判分，且 不给垃圾邮件留口子 。
关键数据：SPF/DKIM 通过是判断合法性的核心信号——宁可多设白名单，也不要放松对伪造域的惩罚 。
END
我是 FreeLamp.com，致力于分享 Linux 底层与 DevSecOps 深度技术。
如果你觉得今天这篇有收获，欢迎 点赞、在看、转发 三连，我们下篇见。
JMAP 协议与 Stalwart Mail Server：现代邮件基础设施的 Rust 革命 MTA（邮件传输代理）核心架构与工作原理解析 封禁 25 端口下的 Postfix 发信逆袭：从 GOST、Proxychains 踩坑到 DirectMail 的终极救赎 ISO 27001:2022 认证完全解读——从零到合规的工具箱
常见问题（FAQ）
Q1：为什么 Debian 列表、LinkedIn 这类高信誉邮件还会进 Junk？ A1：rspamd 仍给了高分，主因三个符号：FORGED_SENDER（+5.0）、FORGED_RECIPIENTS（+2.0）、BLACKLIST_DMARC（+6.0）。这些邮件虽通过 SPF/DKIM，但触发了上述规则。
Q2：怎么定位误报的根因？
A2：用 rspamc 对误报邮件重新打分，看具体触发了哪些符号及其分值。
Q3：怎么精准对冲误判？
A3：在白名单域名里加上已订阅的通讯/厂商域，再写组合规则：当 WHITELIST_DOMAINS_FROM & (R_SPF_ALLOW | R_DKIM_ALLOW) 时扣分（如 BLACKLIST_DMARC 对冲 -7.0、FORGED_SENDER 对冲 -5.0）。
Q4：误判邮件怎么移回收件箱？ A4：文中给了从 Junk 移回 19 封邮件的完整操作流程。
