Postal 3.3.7 介绍与选型指南

目标：面向正在为应用系统选型「自建邮件发送基础设施」的读者，系统性介绍 Postal 的定位、核心架构、功能特性、部署要求与版本现状，并与 Mailcow、Stalwart、docker-mailserver、Listmonk、Haraka、Maddy 以及 Mailgun/SendGrid/Amazon SES 等托管服务做横向对比，帮助读者判断 Postal 是否适合你的场景。本文为认知与选型篇，不涉及安装实操；文内版本、活跃度与兼容性信息均于 2026-10-19 实查官方公开资料（GitHub Releases、官方文档站、仓库主页）获得，动手部署与入门实操见本专栏《Postal Docker Compose 部署指南》与《Postal 快速入门与实战示例》。

一、Postal 是什么

先把 Postal 的"身份"说清楚：它不是给最终用户提供邮箱的全家桶邮件服务器（没有 IMAP/POP3、没有 webmail、没有用户邮箱账号），而是一个开源的邮件投递平台（mail delivery platform）——你的应用通过 SMTP 或 HTTP API 把邮件交给 Postal，Postal 负责剩下的全部"脏活"：DKIM 签名、持久化队列、失败重试与退避、退信与抑制名单管理、投递日志留存，并提供 Web 管理界面让你实时观察每一封邮件"接收 → 签名 → 排队 → 投递 → 送达/失败"的全过程。

典型用途：SaaS 产品的事务邮件（注册验证、密码重置、账单通知）、系统告警邮件，以及作为 newsletter/营销工具的底层投递引擎。

理解 Postal 的关键词是「投递」和「可观测」：

• 投递基础设施：它像一座"邮件发射台"——应用只管把信交进来，重试节奏、退信处理、无效地址抑制、IP/中继投出这些投递工程细节全部由 Postal 托管，且对应用侧只暴露一个 SMTP 端点或一个 HTTP API。
• 可观测：与传统 MTA（如 Postfix 排障要翻日志文件、拼日志行）不同，Postal 把每一封消息、每一次投递尝试、原始报文全部落库，Web 界面可按收件人/主题/标签检索，配合 webhook 把投递事件实时推给你的业务系统——这在自建发信方案里是稀缺的完整度。

二、版本现状与演进节奏

2.1 发布历史

来源：GitHub Releases（查询日期 2026-10-19）。版本发布由 release-please 自动化驱动，补丁号随合并修复自动递增。

节奏解读：3.3.4（2024-06）与 3.3.5（2026-02）之间存在约 19 个月的补丁空窗，2026 年起恢复高频迭代（3.3.5 → 3.3.6 间隔约 3 个月，3.3.6 → 3.3.7 间隔约 5 周）。生产选型建议跟随最新补丁版，不要停留在 3.3.4 及更早版本。

2.2 3.3.7 修复的安全问题

依据 GitHub 3.3.7 Release 说明（查询日期 2026-10-19）：

• SSRF 防护：出站 webhook 与 HTTP endpoint 的外呼增加防护，避免被诱导访问内网地址；
• SQL 注入修复：message-db 查询的注入漏洞（官方公告编号 GHSA-x2hq-rfpg-3xr5）；
• 依赖升级：rack / rails 等基础依赖升级到已修复版本。

对一个"消息与原始报文全量入库"的发信平台来说，这两类修复直接命中其核心攻击面，也是建议生产环境至少升到 3.3.7 的直接理由。

2.3 v3 相对 v2 的架构变化

依据官方升级文档（upgrade-to-v3，查询日期 2026-10-19）：

• 移除 RabbitMQ：v2 时代消息队列依赖 RabbitMQ，v3 起不再需要，部署栈少一个有状态组件；
• 移除 cron/requeuer：v2 的定时任务与重新入队组件在 v3 中并入常驻 worker，不再需要额外进程；
• 配置与日志改进：配置支持环境变量注入，日志体系结构调整，对编排化/自动化部署更友好；
• 数据库仅支持 MariaDB：官方明确 v3 只支持 MariaDB 10.6 及以上，不支持 MySQL。

2.4 3.3.7 已知问题

官方配置文档标注（查询日期 2026-10-19）：出站 SMTP 中继的 ssl_mode 配置中，STARTTLS 取值因源码拼写错误在 3.3.7 中不生效；需要 STARTTLS 行为时请使用 Auto 或 TLS 替代。部署时若发现出站中继 TLS 行为异常，先核对这一项（排障细节见《Postal 日常运维与排障手册》）。

三、核心架构解析

先看整体数据流，再逐层拆解：

  应用/客户端                     Postal 3.3.7
 ───────────┐        ┌────────────────────────────────────────┐
  SMTP 提交  │        │  smtp   ：SMTP 服务器（收出站提交/入站邮件） │
  HTTP API  ├───────►│  web    ：管理界面 + HTTP API（Rails）      │
  浏览器管理  │        │  worker ：队列出站投递 + 后台任务             │
 ───────────┘        └───────┬─────────────────────▲──────────┘
                             ▼                     │
                  MariaDB：postal（主库）            │ webhook 事件推送
                          postal-server-<id>（消息库）│
                             ▼                     ▼
                  出站投递（直连或经 smtp_relays） → 收件方 / 你的系统

• 三个常驻服务：web（Rails 应用，承载 Web 管理界面与 HTTP API）、smtp（SMTP 服务器，同时接收应用的出站提交与外部入站邮件）、worker（后台任务执行者，出站队列投递、webhook 通知等均由它完成）。官方安装辅助工具生成的编排文件中还有一个 runner 服务（tools profile），仅执行维护命令时启用、平时不常驻——postal 命令行工具正是通过它进入环境完成初始化、建号、备份等操作。
• 多组织/多邮件服务器模型：Organization → Mail Server → Credentials（SMTP 凭据/API 密钥）、Domains、Routes 逐层挂载，每台邮件服务器有独立的模式（Live/Development）、发送限额与统计。多团队共用一套 Postal 时按服务器隔离、互不干扰。
• 消息库按服务器分库：主库存组织/服务器/域名/凭据等配置数据；每创建一台邮件服务器，Postal 会自动为其创建独立消息库（默认前缀 postal-server-，官方前置条件文档明确说明），messages、deliveries、按日期分表的 raw 原始报文、suppressions、webhook_requests 等都在消息库内。单台服务器的留存策略、数据清理因此互不影响。
• 队列与重试：出站消息先落队再异步投递；投递失败自动重试，状态标记为 SoftFail（源码默认最多 18 次尝试、从 5 分钟起按约 1.3 倍指数退避），期间可随时手工"立即重投"；连续失败还可能进入抑制名单，避免对无效地址反复投递（运维实操见《Postal 日常运维与排障手册》）。
• DKIM 双轨签名：支持域级密钥（每个域名独立密钥，记录名形如 postal-<selector>._domainkey）与安装级密钥两级；域名级密钥未就绪时自动回落到安装级签名（postal default-dkim-record 命令输出安装级记录值），配置文件中的 signing.key 即安装级私钥。出站签名可按官方 DNS 文档验证。
• DNS 五件套：官方 DNS 配置文档要求为安装环境配置 SPF、DKIM、MX、Return-Path（rp 子域）与 Tracking（track 子域）五类记录，Web 界面内置 DNS 检查可逐项核对。
• 可观测性：官方提供健康检查端点与 Prometheus 格式指标（特性页 health & metrics）；webhook 把 MessageSent / MessageDelayed / MessageDeliveryFailed / MessageHeld / MessageBounced 等事件实时推送到你的 HTTP 端点（官方 Webhooks 文档），并保留最近 7 天的 webhook 请求记录用于排障（官方功能清单）。

四、功能特性全景

依据官方功能清单页（docs.postalserver.io，查询日期 2026-10-19）归纳：

4.1 通用能力

• 多组织、多邮件服务器、多用户与权限管理；
• 收发件量的图表与统计，历史消息与完整消息队列可视化查询；
• 服务器范围的消息搜索工具，快速定位需要调查的邮件；
• webhook 实时推送投递事件，最近 7 天请求记录可回查；
• 域名 DNS 配置内置检查与监控，保障投递可达性；
• 按服务器的消息保留策略（数据库留存时长与磁盘占用上限）；
• 完整投递日志（含原始消息内容）。

4.2 出站投递

• SMTP 端点与 HTTP API 两种提交方式，每服务器可配多组凭据；
• 出站 DKIM 签名；
• Development 模式：邮件只入队挂起、不真正投出，供界面审阅；
• 内置抑制名单（自动与手工维护双通道），避免向不存在或拒收的地址反复投递；
• 点击与打开追踪（click & open tracking）；
• 每服务器发送限额，防止滥用；
• 发送 IP 池管理（默认关闭，postal.yml 中 use_ip_pools: true 开启）：不同邮件服务器、不同发件人/收件人可指定从不同 IP 地址投出；
• 消息标签（tag），按业务线分组统计与检索。

4.3 入站接收

• 入站邮件可转发到 HTTP 端点、其他 SMTP 服务器或其他邮箱地址（Routes 机制，支持通配与标签地址）；
• 可选对接 SpamAssassin 与 ClamAV 做垃圾/病毒检查，阈值与处理方式可配置。

4.4 HTTP API 与集成

• HTTP API 覆盖发送（send/message、send/raw）、消息查询、抑制名单管理等能力（官方 API 文档）；
• 官方与社区提供多种语言的客户端库（官方 client libraries 页），应用侧接入成本低。

五、部署要求与快速上手（官方口径）

5.1 资源与环境要求

5.2 快速上手路径

官方安装流程（installation 文档）概括为六步，本站已按此路径在 Ubuntu 22.04 全流程实测并成文：

1. 安装 Docker Engine 与 Compose 插件，准备 git/curl/jq；
2. 克隆官方安装辅助仓库 postalserver/install 并注册 postal 命令；
3. 准备 MariaDB 10.6+ 数据库实例（官方提供参考启动方式）；
4. postal bootstrap <主机名> <配置目录> 生成 postal.yml、签名密钥与编排文件；
5. postal initialize 初始化数据库，postal make-user 创建管理员；
6. postal start 启动三个常驻服务，随后按官方 DNS 文档配置五件套记录与 DKIM。

完整命令、参数与真实回显见《Postal Docker Compose 部署指南》；创建组织/邮件服务器/DKIM、SMTP 与 API 两种方式发信、入站路由的入门实操见《Postal 快速入门与实战示例》。

六、适用场景与限制

6.1 适合选择 Postal 的场景

• 应用事务邮件发送基础设施：注册验证、密码重置、通知告警等系统邮件的统一出口，SMTP/API 双通道便于应用接入；
• 多产品线/多团队集中发信：多组织-多服务器-多凭据模型加每服务器独立限额与统计，一套 Postal 服务多个业务互不干扰；
• 对投递过程有审计与排障诉求：完整投递日志、原始报文按日期分表留存、保留策略可配，出问题能"看到每一封邮件发生了什么"；
• 入站邮件自动化：MX 收信后按 Route 转发到 HTTP 端点，做解析、工单、自动回复等流水线；
• 作为 newsletter/营销工具的投递底座：与 Listmonk 这类订阅管理工具组合——Listmonk 管内容与订阅，Postal 负责投递。

6.2 需要接受的限制与风险

1. 没有邮箱服务：不提供 IMAP/POP3/webmail，不能替代 Mailcow/Stalwart 这类全家桶；需要收件邮箱的团队两者要分开选型；
2. 数据库只有 MariaDB 一条路：官方明确不支持 MySQL，PostgreSQL 体系团队需要单独维护一个 MariaDB 实例；
3. 版本节奏有波动史：3.3.4 → 3.3.5 之间约 19 个月补丁空窗（2024-06 至 2026-02），2026 年虽已恢复高频，维护活跃度仍值得持续观察；
4. 官方部署路径面向单机：官方安装文档未提供多节点/高可用参考架构，高可用场景需自行设计（数据库高可用、多投递节点等）；
5. 3.3.7 已知问题：出站中继 ssl_mode 的 STARTTLS 取值失效（拼写错误），需用 Auto/TLS 替代（官方文档已标注，见 2.4 节）；
6. 生态规模：社区体量与教程积累不如 Postfix/Dovecot 传统体系，中文资料相对有限，深度排障更多依赖官方文档与源码。

七、同类选型对比

7.1 先分清四类「邮件方案」

选型最容易犯的错误是拿 Postal 和 Mailcow 比"谁功能多"——两者根本不在同一层。先把候选放进正确的分层：

Postal 的差异化在于：它是开源阵营里少有的把「MTA + Web 管理界面 + HTTP API + 完整可观测」成套打包的发送基础设施——Haraka 更像可编程 MTA 框架（无管理界面与 Web 观测面），而全家桶方案的重心是邮箱服务而非应用投递。

7.2 社区活跃度与版本节奏（2026-10-19 实查）

数据来源：各仓库 GitHub Releases / releases.atom 与 shields.io 徽章，查询日期 2026-10-19。Stars 为量级参考（四舍五入到千位），仅反映社区关注度，不代表质量排序。

7.3 兼容矩阵（Postal 官方口径）

7.4 分场景选型建议

• 应用系统事务邮件、要 Web 界面看投递：Postal 是开源阵营的第一选择——观测面完整（队列/日志/原始报文/webhook），MIT 协议对商用友好；
• 需要邮箱、webmail、日历联系人：在 Mailcow、docker-mailserver、Stalwart、iRedMail 里选（可参阅本站《docker-mailserver 16.0.1 介绍与选型指南》与《Stalwart v0.16.26 介绍与选型指南》），不要指望 Postal 提供邮箱；
• newsletter/邮件营销：Listmonk 管订阅与内容，投递端自建选 Postal、托管选 SES/Mailgun，两者通过 SMTP 对接；
• 要深度定制 SMTP 会话逻辑（自定义策略、协议扩展）：Haraka 的可编程框架更对口；要开箱即用的管理面则选 Postal；
• 个人域名、1 核 1G 小机器：Maddy/Stalwart 更合适——Postal 官方门槛即 4GB 内存，且其定位是"平台"而非个人邮箱；
• 不想自建：Mailgun/SendGrid/Amazon SES 按量付费免运维。与自建 Postal 的核心权衡是：数据主权与固定成本 vs IP 信誉冷启动与运维负担——大流量下自建成本优势明显，但需要自己维护 IP 信誉与 SPF/DKIM/DMARC 体系。

7.5 一句话结论

如果你的核心诉求是「给我的应用一套看得见、管得住、能审计的自建发信基础设施」，Postal 3.3.7 是当前完成度最高的开源答案；如果你的核心诉求是「给人提供邮箱」，请移步全家桶阵营。

八、参考链接

• 官方文档站（前置条件/安装/DNS/API/Webhooks/特性清单/升级说明）：https://docs.postalserver.io
• GitHub 仓库：https://github.com/postalserver/postal
• GitHub Releases（版本数据来源）：https://github.com/postalserver/postal/releases
• 安装辅助仓库（postal 命令与编排模板）：https://github.com/postalserver/install
• 对照方案仓库：docker-mailserver https://github.com/docker-mailserver/docker-mailserver ；Stalwart https://github.com/stalwartlabs/stalwart ；Mailcow https://github.com/mailcow/mailcow-dockerized ；Listmonk https://github.com/knadh/listmonk ；Haraka https://github.com/haraka/Haraka ；Maddy https://github.com/foxcpp/maddy
• 托管服务对照：Mailgun https://www.mailgun.com ；SendGrid https://sendgrid.com ；Amazon SES https://aws.amazon.com/ses/
• 版本、活跃度与兼容性数据查询日期：2026-10-19（来源：GitHub Releases / releases.atom / shields.io 徽章 / 官方文档站）