Postfix 与 Dovecot 有什么区别：收件服务器职责与排障路径
Once Email 工程团队审校 Once Email 技术审校
文章导读
这篇文章值得阅读的原因
- 原创分析
- 本文把同一封入站邮件拆成 SMTP 接收、排队、LMTP 投递、邮箱存储和 IMAP 读取五个检查点，并把失败证据归给真正负责的组件。
- 趋势背景
- Postfix 与 Dovecot 仍常被组合使用，但容器镜像和面板会隐藏传输、最终投递与邮箱访问的边界，导致运维人员把不同故障混为一谈。
- 实用价值
- 读者可用职责表和有序证据链区分 SMTP 未接收、队列延迟、邮箱写入失败与客户端不可见，同时避免记录邮件敏感内容，并保留可审计但已经脱敏的运行证据。
本文导航
Postfix 与 Dovecot 经常安装在同一台邮件服务器上，但它们不是同一个东西。常见收件架构中，Postfix 接收 SMTP 连接并管理邮件队列，Dovecot 负责最终写入邮箱，或通过 IMAP 向已认证客户端提供邮件。其中一个服务显示正常，不代表完整收件流程正常。
本文是一张排障地图，不是可以直接复制到生产环境的配置教程。真实部署还涉及 DNS、TLS、收件人校验、反垃圾、存储权限、备份、监控和中继限制。Once Email 只接收邮件，不提供 SMTP 发信、回复、转发或群发；下文只讨论入站边界。
一张表看懂职责
| 问题 | Postfix | Dovecot |
|---|---|---|
| 主要网络协议 | 接收或发送 SMTP | 通过 IMAP/POP3 提供邮箱访问，也可用 LMTP 接收最终投递 |
| 是否拥有邮件队列 | 是 | 否 |
| 是否决定 SMTP 阶段接收某个收件人 | 通常由 Postfix 及其查询、策略服务决定 | 某些架构会由 Dovecot 提供用户或邮箱资料 |
| 谁把邮件写入最终邮箱 | Postfix 可本地投递，也可交给 Dovecot LMTP | Dovecot LMTP 可执行最终邮箱投递 |
| 谁让客户端列出和读取邮件 | 不负责 | 通常由 Dovecot IMAP 负责 |
所以，“Postfix 还是 Dovecot”通常不是二选一。对托管邮箱而言，真正的问题是一个组件的责任在哪里结束，下一个组件从哪里开始。
跟踪一封入站邮件
Postfix 官方架构说明描述了网络邮件进入 smtpd、经过 cleanup 并进入队列，随后由队列管理器选择投递代理。可以把一次收件拆成四个检查点：
- SMTP 连接：远端发送服务器能否连接 Postfix，并完成邮件事务。
- 收件人接收：Postfix 是否依据地址表和访问规则接收信封收件人。
- 队列与交接：已接收邮件是否进入队列，并由 local、virtual、pipe 或 LMTP 投递。
- 邮箱访问：最终投递后，Dovecot 是否允许已授权客户端通过 IMAP 列出并读取邮件。
SMTP 返回 250 不等于用户已经看见邮件。Postfix 可以先接收，随后因 LMTP、配额或存储错误将邮件保留在延迟队列。反过来，邮件可能已经写入邮箱，但 IMAP 认证、索引、命名空间或文件权限问题让客户端看不到它。
LMTP 如何连接两个服务
一种常见边界是 LMTP：Postfix 继续负责公网 SMTP 与队列，然后调用 Dovecot LMTP 完成最终投递。Dovecot 的 Postfix 与 Dovecot LMTP 指南使用 Postfix spool 内的受保护 Unix socket 展示这种交接。
这个 socket 不是从教程复制一个路径就结束。所有者、组、权限、chroot 位置和服务状态共同构成安全与可靠性合同。Postfix 无法访问它时，正确现象通常是队列延迟，而不是把收件箱伪装成空。LMTP 已接收邮件后，应优先检查 Dovecot 投递、配额和存储证据，而不是继续盯着公网 SMTP。
不要为了消除权限报错把 socket 改成所有人可写。应确认哪个服务账号确实需要访问，并授予最小权限；除非架构明确要求并具备认证与传输保护，也不要把 LMTP 暴露到公网。
按证据定位，不要先重启两个服务
| 观察到的证据 | 首先检查的边界 |
|---|---|
| 远端无法连接 25 端口 | DNS、防火墙、TLS 监听或 Postfix smtpd |
| SMTP 在邮件正文传输前拒绝收件人 | Postfix 收件人表和策略，以及它查询的用户目录 |
| SMTP 已接收，但邮件仍在 deferred 队列 | Postfix 队列状态和选中的投递 transport |
| 日志显示 LMTP socket 不存在或权限拒绝 | Postfix 到 Dovecot 的 socket、用户和权限 |
| LMTP 报配额或邮箱写入失败 | Dovecot 投递与邮箱存储 |
| 磁盘存在邮件，但客户端列不出来 | Dovecot IMAP 认证、命名空间、索引与文件权限 |
使用唯一测试标记和有限时间窗口，保留队列 ID、SMTP 状态类别、LMTP 结果和脱敏的邮箱结果。不要把真实邮箱、验证码、Token、主题、正文、附件名或完整 URL 写进共享日志和分析平台。
常见分类错误
安装 Dovecot 不会自动提供公网 SMTP 监听；安装 Postfix 也不会自动给用户一个 IMAP 收件箱。SPF、DKIM、DMARC 又是另一层，它们提供域名认证与对齐证据，不负责邮箱访问。这个任务应阅读独立的 SPF、DKIM 与 DMARC 结果指南。
队列为空不能证明投递成功：邮件可能退信、过期、被明确策略丢弃，或已经离开队列。收件箱为空也不能证明没有来信：查询可能失败、客户端可能离线，或选择了其他邮箱命名空间。必须区分“没有结果”“临时失败”和“已确认为空”。
改配置前先建立四字段追踪卡
对一封已授权测试邮件，只记录四类脱敏事实。把它们串起来，才能证明 SMTP 接收、队列交接、最终投递和邮箱可见性是否属于同一事务：
| 检查点 | 只保留 | 能证明什么 |
|---|---|---|
| SMTP 接收 | 时间、增强状态类别和缩短后的队列 ID | 证明 Postfix 接收了该事务，不等于最终投递成功 |
| 队列结果 | 同一缩短队列 ID、transport 名称及 delivered/deferred 状态 | 证明 Postfix 选择了投递通道，并完成或保留了交接 |
| LMTP 结果 | 成功或增强错误类别，不含收件人和正文 | 证明 Dovecot LMTP 接受最终投递，或返回了有限失败原因 |
| 邮箱可见性 | 测试前后邮件数量及应用读取结果 | 证明存储发生变化，并确认实际读取路径能否看见结果 |
先做只读检查。postqueue -p 可列出队列，应在本机按缩短 ID 筛选，不要导出完整队列；doveadm mailbox status -u TEST_USER "messages unseen" INBOX 可检查邮箱计数，但只能替换为已授权测试身份，也不要把输出贴到公开工单。Postfix 队列工具和 Dovecot mailbox status 官方说明界定了这些证据的含义。若时间与脱敏事务标记没有同时对应，任何一条命令都不能证明看到的就是本次测试邮件。
安全的验证顺序
先验证公网 SMTP 端点，再投递一封已授权且带唯一标记的测试邮件；记录 Postfix 是否接收，跟踪队列与最终投递结果，确认 Dovecot 邮箱状态，最后通过应用实际使用的 IMAP 路径读取。测试结束后删除测试邮箱，只保留脱敏运行证据。
这个顺序能告诉你故障发生在哪一层。先重启两个服务会丢失时间与队列证据，把可复现故障变成偶发问题，而且仍然解释不了根因。