SpamAssassin 是一款基于 Perl 开发的开源反垃圾邮件系统，它通过规则匹配、贝叶斯统计、黑名单查询等多种手段给邮件打分，分数超过阈值就判定为垃圾邮件。不过在裸机上直接安装它并不轻松，依赖几十个 Perl 模块，稍有不慎就会出现版本冲突，而且一旦服务器重装，环境重建的工作量相当可观。把 SpamAssassin 放进 Docker 容器里运行，不仅可以做到一次构建处处运行，还能方便地做版本管理和横向扩展。本文将从镜像选择、服务编排、规则更新以及与邮件服务器对接几个方面，完整讲解容器化部署的落地过程。
一、选好基础镜像，理解 spamd 的工作模式
在动手之前，先要弄清 SpamAssassin 在容器里的运行形态。它有两种典型用法：一种是作为命令行工具 spamassassin 或 spamc 直接对邮件文件做一次性扫描，另一种是以守护进程 spamd 的形式常驻内存，监听 783 端口，接收客户端提交的邮件内容并返回打分结果。容器化部署推荐使用 spamd 模式，因为守护进程启动时会加载全部规则和贝叶斯数据库，这个初始化过程可能需要十几秒，如果每封邮件都冷启动一次，性能损耗非常大。
基础镜像有两个思路：一是直接使用社区维护的现成镜像，比如 Docker Hub 上的 spamassassin 官方相关镜像，优点是开箱即用，缺点是规则和配置的定制自由度有限；二是自己编写 Dockerfile，基于 debian 或 alpine 安装 spamassassin 包。以 Debian 为例，核心安装只需要一条 apt 命令，随后把自定义的 local.cf 配置文件拷贝进镜像即可。自建镜像的好处是所有配置都纳入版本控制，重建环境只是一条 docker build 的事情。
下面是一个简单可用的 Dockerfile 示例，基于 Debian 安装 SpamAssassin，并设置容器启动时自动运行 spamd：
FROM debian:bookworm-slim
# 安装 SpamAssassin 及推荐的 Perl 依赖
RUN apt-get update && \
apt-get install -y --no-install-recommends spamassassin cron && \
apt-get clean && rm -rf /var/lib/apt/lists/*
# 拷贝自定义配置，覆盖默认规则阈值等参数
COPY local.cf /etc/spamassassin/local.cf
COPY init /docker-entrypoint.sh
RUN chmod +x /docker-entrypoint.sh
EXPOSE 783
# 启动 spamd，允许外部网络连接，创建子进程池提升并发能力
CMD ["/docker-entrypoint.sh"]
对应的入口脚本里，可以先执行 sa-update 拉取最新规则，再以 spamd --listen=0.0.0.0:783 --allowed-ips=0.0.0.0/0 --max-children=5 的参数启动服务。注意默认配置只允许本机连接，容器场景下必须显式放开来源 IP，否则宿主机或其他容器将无法访问。
二、用 docker-compose 编排服务，持久化规则数据
单个容器用 docker run 启动当然可以，但生产环境更推荐 docker-compose 管理。关键点是数据卷的规划：贝叶斯数据库和自动学习的数据默认存放在 /var/lib/spamassassin 目录下，如果这部分数据放在容器的可写层，容器一旦删除，长期训练出来的过滤模型就全部丢失，垃圾识别准确率会明显回落。因此必须把这个目录挂载为命名卷，规则目录 /var/lib/spamassassin/compiled 也一并持久化。
一份典型的 compose 配置如下：
version: "3.8"
services:
spamassassin:
build: .
container_name: sa-spamd
restart: unless-stopped
ports:
- "127.0.0.1:783:783"
volumes:
- sa-data:/var/lib/spamassassin
- ./local.cf:/etc/spamassassin/local.cf:ro
environment:
- TZ=Asia/Shanghai
healthcheck:
test: ["CMD-SHELL", "echo 'PING SPAMC' | spamc -c || exit 1"]
interval: 60s
timeout: 10s
retries: 3
volumes:
sa-data:
这里有几个细节值得展开。端口映射写成 127.0.0.1:783:783 是为了只暴露给宿主机本机使用，避免 spamd 被公网直接访问而成为开放代理；如果你的 Postfix 也跑在容器里并处于同一个 compose 网络，那么可以干脆不做端口映射，直接通过服务名 spamassassin:783 访问。健康检查部分用 spamc 发送一条探测指令，比单纯检查进程存活更可靠。另外环境变量里设置时区很重要，因为垃圾邮件规则里有不少和时间相关的判断逻辑，时区错乱可能导致部分规则误判。
关于资源配置，建议给容器分配至少 512MB 内存。SpamAssassin 的规则数量庞大，加载完成后常驻内存通常在 200MB 到 400MB 之间，如果配合 Pyzor、Razor 或 DNSBL 查询，内存占用还会进一步上升。并发方面由 --max-children 参数控制，每个子进程大约额外占用几十 MB，中小型邮件服务器设成 5 左右即可。
三、与 Postfix 对接及规则自动更新
容器跑起来之后，剩下的问题是如何把它接进邮件链路。最常见的方式是在 Postfix 侧使用 spamass-milter，这是一个 milter 协议的适配器，Postfix 把邮件交给它，它再通过 spamc 协议转发给容器里的 spamd，拿到分数后写回邮件头，甚至可以直接在主题前加上标记。Postfix 主配置里需要增加两行：
smtpd_milters = inet:127.0.0.1:12345 non_smtpd_milters = inet:127.0.0.1:12345
其中 12345 是 spamass-milter 自己的监听端口，它内部再去连接 spamd 的 783 端口。如果两者都在容器里，记得把 milter 容器的连接目标改成服务名而不是 127.0.0.1，这是容器网络中最常见的踩坑点。另一种更轻量的做法是不用 milter，而是在 Postfix 的 master.cf 中为 smtp 服务配置管道，通过 spamc -f 过滤后再投递，实现简单但灵活性略差。
规则的时效性直接决定过滤效果。SpamAssassin 官方规则库通过 sa-update 命令更新，容器环境下有两种做法：一是在入口脚本里每次启动前更新一次，简单但重启不频繁时规则会过期；二是利用容器内安装的 cron，或者在宿主机上配置定时任务执行 docker exec sa-spamd sa-update && docker exec sa-spamd sa-compile，更新后用 docker exec sa-spamd pkill -HUP spamd 让守护进程平滑重载规则。建议每天更新一次，频率过高对官方镜像源并不友好。
最后说说排查思路。判断过滤服务是否正常，最直接的方式是用 spamc 手动投递一份测试邮件并观察返回分数，SpamAssassin 自带的 GTUBE 测试串可以触发一个固定的 1000 分，用来验证整条链路是否通畅。日志方面，spamd 默认输出到标准错误，配合 compose 只需执行 docker logs -f sa-spamd 即可看到每封邮件的处理耗时和得分。如果发现大量超时，多半是 DNSBL 查询走的外部 DNS 响应太慢，可以在容器里指定一个响应更快的 DNS 服务器，或者干脆禁用部分查询类规则，在准确率和延迟之间找到平衡点。整体而言，容器化并没有改变 SpamAssassin 本身的过滤逻辑，它改变的是部署和维护的方式，让这套经典工具在现代基础设施中继续发挥价值。
SpamAssassinDocker部署邮件过滤修改时间：2026-09-11 16:30:45