1. 隔离区的定位与设计原则

邮件隔离区（Quarantine）是反垃圾过滤系统与用户收件箱之间的"缓冲区域"——被判定为疑似垃圾或恶意内容的邮件在进入收件箱之前被暂存在隔离区，等待用户或管理员的进一步决策。隔离区解决了反垃圾系统最核心的实用矛盾：阈值设高则漏放垃圾邮件（false negative），阈值设低则误拦正常邮件（false positive）。隔离区的工程本质是"将二分类问题转化为延迟决策问题"，用存储成本换取误报的修复空间 [1]。

设计隔离区系统时需遵循以下原则：

1. 最小保留原则：仅隔离"边界模糊"的邮件（评分在可疑区间内），明确判定为垃圾的邮件应直接拒绝或标记，明确正常的邮件直接放行。隔离区不是垃圾箱的替代品。
2. 快速释放原则：用户自助释放应在 30 秒内完成（对用户感知而言，超过 30 秒的操作即属于"等待"状态）
3. 审计完整原则：所有释放和删除操作必须记录供后续审计；误报释放数据应作为反馈信号输入过滤引擎的调优管道
4. 存储即成本原则：隔离区存储不应与主邮箱存储共用同一存储池，建议使用独立磁盘卷或不同的存储层级

2. 隔离区存储架构与保留策略

2.1 存储后端选择

2.1 存储后端选择

方案	优点	缺点	适用规模
MySQL/PostgreSQL（BLOB）	统一管理、支持 SQL 查询、事务性一致性	大 BLOB 的备份/恢复复杂、性能随邮件数增长下降	千级用户
文件系统（目录树）	简单、无数据库依赖、可通过 rsync 同步	大量小文件的写入性能差、元数据查询慢	万级用户
对象存储（S3/MinIO）	水平扩展、按需计费、HTTP 直接下载	延迟较高（NoSQL 层需整合）、需要额外的元数据索引	十万级以上
Redis（暂存）	极低延迟、适合临时候选隔离	持久化有限、不适用于长期保留	配合其他方案使用

2.2 保留策略模型

# 推荐的分层保留策略
# 邮件在隔离区中的保留时间取决于其风险评分和用户干预状态

# 评分区间与保留期对应关系：
# Score 0-3（低风险）：保留 7 天 → 未干预自动删除
# Score 3-6（中风险）：保留 14 天 → 未干预自动删除
# Score 6-9（高风险）：保留 30 天 → 管理员审核后处理
# Score 9+（明确垃圾）：不进入隔离区，直接标记/丢弃

# 用户操作后的保留调整：
# 用户标记为误报：立即移入收件箱，保留隔离区副本 24h 后删除
# 用户确认删除：立即删除，保留操作日志 90 天
# 管理员审核放行：移至收件箱 + 反馈至过滤引擎，隔离区副本 72h 删除

# 存储配额限制
quarantine_quota_per_user = 500   # 每用户隔离区容量上限（MB）
quarantine_global_quota = 50      # 隔离区总容量上限（GB）
quarantine_low_watermark = 0.80   # 使用率达到 80% 时触发告警

3. 用户自助释放机制

用户自助释放（Self-Service Release）是降低运维压力的关键功能——据统计，部署自服务释放机制可将管理员介入的误报处理请求减少 80% 以上。设计上应考虑三个用户触达渠道：邮件摘要通知、Web 管理界面、以及 IMAP 扩展。

3.1 摘要通知邮件

摘要邮件（Digest）应在固定时间间隔（建议每日 09:00 发送一次，不推荐实时通知——实时通知违反"最小打扰"原则）向用户发送隔离区概况。摘要内容应包括：

Subject: [QUARANTINE DIGEST] 您有 8 封邮件被隔离（2026-07-24）

尊敬的 user@example.com：

以下邮件于过去 24 小时内被隔离，请审核：

1. 来自: "中奖通知" <spam@badsender.com>
   主题: 恭喜您获得 iPhone 15
   评分: 7.5/10 | 被拦截原因: DNSBL + Bayesian
   [释放] [删除]

2. 来自: "王经理" <wang@client-asia.org>
   主题: FY2026 Q2 报告修改意见（重要）
   评分: 4.2/10 | 被拦截原因: 发件方 IP 信誉低
   [释放] [删除] [标记为误报]

...

一键操作链接（有效期 72 小时）：
https://mail.ztpop.net/quarantine/release?token=xxxx

其中关键设计是"短时效的 HMAC 令牌"——每个释放操作链接使用 hmac_sha256(uid || email_id || expire) 签名，有效期 72 小时，公开该令牌不会泄露保密信息。

3.2 Web 管理界面

Web 管理界面需要实现以下 API：

# REST API 设计参考
# --- 用户端 ---
GET  /api/v1/quarantine/inbox
  → 返回当前用户的隔离邮件列表（分页）

POST /api/v1/quarantine/{id}/release
  → 将指定邮件释放到收件箱（需验证令牌或 session）

POST /api/v1/quarantine/{id}/delete
  → 删除隔离区中的邮件

POST /api/v1/quarantine/{id}/mark-false-positive
  → 标记为误报（将邮件体作为反馈信号输入过滤引擎的自学习管道）

# --- 管理员端 ---
GET  /api/v1/admin/quarantine/pending
  → 返回需要管理员审核的隔离邮件列表

POST /api/v1/admin/quarantine/{id}/approve
  → 管理员批准释放

POST /api/v1/admin/quarantine/{id}/deny
  → 管理员拒绝并保留删除记录

GET  /api/v1/admin/quarantine/audit-log
  → 审核日志（按时间倒序，支持日期筛选）

4. 管理员审核工作流

管理员审核工作流用于处理：a) 高风险隔离邮件（评分 > 6），b) 由多个用户报告的同一发件人的批量误报，c) 合规保留要求（如法律保留令）。工作流应支持"单封逐一审核"和"批量模式（Select All + Approve/Deny）"两种模式。

4.1 审核状态机

状态转换图（简化）：

    ┌───────────┐
    │  PENDING  │  ← 邮件刚到达隔离区
    └─────┬─────┘
          │
     ┌────┴────┐
     │  REVIEW │  ← 管理员开始审核
     └────┬────┘
          │
     ┌────┴──────────┐
     │               │
  ┌──▼───┐      ┌───▼──┐
  │RELEASED│    │ DENIED│
  └──┬───┘      └───┬──┘
     │               │
  ┌──▼───┐      ┌───▼──────┐
  │INBOX │      │DELETED   │
  │      │      │+ AUDIT   │
  └──────┘      └──────────┘

4.2 批量误报处理

当一个 IP 或域名在同一天内被 3 个以上用户标记为误报时，系统应自动生成管理员通知并将其置入"排除候选列表"。管理员审核后可选择将该发件人加入白名单（whitelist_from）或对其域名的 SPF/DKIM 记录进行再验证。

# 误报聚合逻辑示例（Python 伪代码）
def process_false_positive_feedback(email_headers):
    sender_ip = email_headers.get('Received-From-IP')
    sender_domain = email_headers.get('From-Domain')

    ttl_window = timedelta(hours=24)
    reports = db.query('SELECT COUNT(*) FROM quarantine_fp_feedback WHERE target_ip = ? OR target_domain = ? AND created_at > NOW() - ?', sender_ip, sender_domain, ttl_window)

    if reports >= 3:
        notify_admin(
            f"疑似批量误报：IP {sender_ip} 或域名 {sender_domain} "
            f"在24小时内被 {reports} 名用户标记为误报",
            priority='medium'
        )

5. SpamAssassin 与 Rspamd 隔离实现对比

5. SpamAssassin 与 Rspamd 隔离实现对比

特性	SpamAssassin	Rspamd
隔离机制	通过 spamd 的 --quarantine 选项 + spamd-quarantine 插件，生成 .msg 文件或通过 sa-learn 的 --spam / --ham 标记	内置 quarantining 模块，支持 Redis/文件/HTTP 三种后端（quarantine_type = "redis" 或 "fscrypt"）
评分阈值模型	单阈值：required_score 仅为拒绝/标记的分界线；隔离需外部脚本配合（如 sa-quarantine.pl）	三区间模型：reject_score（拒绝阈值）> quarantine_score（隔离阈值）> subject_score（标记阈值），支持浮点数精度
误报反馈通道	需手动调用 sa-learn --ham；无用户自助释放接口	内置 HTTP API /quarantine 支持释放操作；rmilter 模块集成自助释放
批量处理性能	单线程模型，隔离大量邮件时 CPU 消耗高	事件循环 + 异步 I/O，支持数千封/秒的隔离写入
隔离区元数据	无内置元数据索引；隔离邮件的检索依赖文件系统命名约定或外部数据库	Redis 中维护隔离邮件元数据索引，支持按评分/发件人/时间范围查询
自动清除	无内置 TTL 过期机制；需 cron 脚本配合	内置 TTL 过期（quarantine_expire_time = 7d），由 controller worker 自动检查并清理

从运维复杂度角度看，Rspamd 的内置隔离功能显著优于 SpamAssassin 的外部脚本方案。对于日均邮件吞吐超过 10 万封的环境，建议优先使用 Rspamd 隔离模块 + Redis 后端的组合。SpamAssassin 的隔离方案更适合低吞吐量（日均 < 1 万封）或已有成熟的外部隔离流程的场景。

# Rspamd 隔离模块配置（/etc/rspamd/local.d/quarantine.conf）
quarantine_type = "redis";
quarantine_score = 5.0;
quarantine_expire_time = 14d;
quarantine_max_size = 10M;
quarantine_url = "https://mail.ztpop.net/quarantine/release";

# Redis 键前缀配置
quarantine_redis_prefix = "rq";

# 控制器 worker 中启用隔离管理
worker {
  type = "controller";
  bind_socket = "*:11334";
  secure_ip = "127.0.0.1";
  count = 2;
  # 隔离区管理端点
  extra_capabilities = ["quarantine"];
}

6. 误报处理最佳实践

• 反馈闭环：用户每次自助释放的邮件应自动流入过滤系统的训练集——Rspamd 的 autolearn 功能可将释放操作自动转为 ham 训练样本，SpamAssassin 需通过 cron 定期调用 sa-learn --ham
• 定期校准：每月从隔离区随机抽取 100 封用户标记为误报的邮件进行人工复查，复查结果用于调整过滤引擎的规则权重和白名单策略
• 白名单粒度：部署三层白名单——全局白名单（管理员维护）、域级白名单（IT 部门维护）、用户个人白名单（用户自助维护），优先级逐层递减
• 误报统计分析：建立误报报告仪表盘，按"被拦截发件人"、"拦截原因（DNSBL/Bayesian/RBL 规则等）"、"用户组"三个维度聚合，定位过滤引擎权重偏差
• 熔断机制：当某个拦截原因在 1 小时内导致的误报数超过历史基线 3 倍标准差时，自动暂停该规则的生效并通知管理员