首页 » 知识库 » 第五层：运维实践 » Postfix MTA 架构深度解析 — 多进程模型、队列系统与性能调优

Postfix MTA 架构深度解析 — 多进程模型、队列系统与性能调优

2026-07-04

Wietse Venema 在 1997 年 IBM T.J. Watson 研究中心启动 Postfix 项目时，前身 IBM Secure Mailer 的设计目标非常明确——替换 Sendmail 的单体架构，用一组独立、最小权限的协作进程来构成 MTA。二十多年后，这套多进程隔离模型仍然是邮件传输代理设计领域的参考实现。本文从 master(8) 调度层出发，逐层拆解 Postfix 进程拓扑、五队列生命周期、Content Filter 管道机制，以及在高吞吐量场景下需要关注的并发与限流参数。

一、master(8)：全局调度与进程生命周期

Postfix 启动后第一个驻留进程就是 master(8)。它不与邮件数据直接打交道——它的唯一职责是读取 master.cf 和 main.cf，按配置创建、监控、销毁子进程。每种子进程（smtpd、cleanup、qmgr、local、smtp 等）在 master.cf 中是一个服务条目，拥有独立的进程上限、监听方式和权限上下文。

master(8) 的调度策略分两类：按需 fork 和预派生池。按需 fork 是默认行为——当新连接到达 smtpd 的监听端口时，master 从服务定义中 fork 一个 smtpd 实例，用完即销毁（直到触达 process_limit）。预派生池由 smtpd（以及某些配置下的 cleanup）使用，通过在 master.cf 的对应行追加 -o XXX 参数来预先保持一定数量的空闲进程，避免连接高峰期的 fork 开销。需要注意的是，master 自身崩溃不会导致邮件丢失——所有邮件已经写入磁盘队列，重启后 qmgr 会从断点恢复投递。 

# 查看 master(8) 当前管理的所有子进程
$ postfix status
postfix/postfix-script: the Postfix mail system is running: PID: 1283

# 查看每个服务类型的活跃进程数
$ ps aux | grep -E '(smtpd|cleanup|qmgr|local|smtp|trivial-rewrite)' | grep -v grep
root     1284  ... qmgr -l -t unix -u
postfix  1421  ... smtpd -n smtp -t inet -u -o stress=yes
postfix  1422  ... proxymap -t unix -u
postfix  1433  ... cleanup -z -t unix -u
postfix  1434  ... trivial-rewrite -n rewrite -t unix -u
postfix  1439  ... smtp -t unix -u
postfix  1440  ... local -t unix -u

二、进程分工：谁做什么

Postfix 的核心理念之一是"每个进程只做一件事，并且假设所有输入都可能不可信"。这种设计不是出于微服务流行——1997 年还没有这个说法，而是 Venema 在分析 Sendmail 的安全漏洞后得出的工程结论。以下是各守护进程的职责边界：

守护进程职责输入来源输出目标以什么用户运行
smtpd(8) 接受入站 SMTP 连接，执行 SMTP 协议对话（EHLO/MAIL FROM/RCPT TO/DATA），完成 SMTP 级别访问控制（客户端限制、收件人限制、HELO 限制），将接收到的邮件注入 cleanup 管道 远程 MTA（端口 25/587）或本地 MUA（端口 587/465） cleanup(8)，通过 pipe postfix
cleanup(8) 对原始邮件进行规范化处理：补全缺失的 Message-ID 和 Date（如果缺失），移除重复头域，添加 Received 头（记录传输路径），插入缺少的发件人信息，最后将规范化后的邮件写入 incoming 队列 smtpd(8)、pickup(8)、postdrop(1)（来自 sendmail 命令行） incoming 队列（磁盘文件） postfix
trivial-rewrite(8) 执行地址重写和路由解析。查询 transport 表和 canonical 映射，将收件人地址转换为"投递方式 + 投递目标"对（如 smtp:gmail.com 或 local:user@example.com），确定每条消息的下一跳投递方式 cleanup(8)、qmgr(8)（查询请求） qmgr(8)（地址解析结果） postfix
qmgr(8) 队列管理器，整个 Postfix 的心脏。从 incoming 队列取出新邮件移入 active 队列，调用 trivial-rewrite 解析路由，根据投递方式分拣邮件，调度投递代理（smtp/lmtp/local/virtual/pipe）进行实际投递。支持并发投递和每站点并发控制 incoming 队列、deferred 队列 投递代理（smtp/local/virtual/pipe），通过触发 postfix
smtp(8) 出站 SMTP 客户端。连接远程 MTA，发送 SMTP 命令，传输邮件。支持 TLS 加密、SMTP 认证、连接复用（connection cache）、多 MX 失败转移 qmgr(8)（投递请求） 远程 MTA 或延迟队列（deferred） postfix
local(8) 本地投递代理。将邮件写入本机用户邮箱（mbox 或 maildir），执行 alias 展开、.forward 文件处理，调用外部命令（通过 pipe 或其内置管道）投递到 LMTP 服务或外部程序 qmgr(8)（投递请求） 用户邮箱（maildir/mbox）或外部命令 postfix（可能需要 root 权限进行最终用户切换）
pipe(8) 通用外程序投递代理。将邮件内容通过 stdin 管道传送到外部命令或脚本（如垃圾邮件过滤器、病毒扫描器、邮件归档脚本），支持按成功/失败返回值分类处理 qmgr(8)（投递请求） 外部程序 stdin 可配置
spawn(8) 非投递用外部程序守护——daemon 化运行外部进程。通常用于 Content Filter 的进程管理，由 master 负责生命周期 master(8)（调度指令） 外部守护进程 可配置
pickup(8) 从 maildrop 队列中拾取由 postdrop(1) 写入的本地提交邮件（sendmail 命令行方式提交），交给 cleanup(8) 规范化 maildrop 队列（磁盘） cleanup(8) postfix

一个关键细节：上述进程之间不共享内存，不通过信号通信。数据流完全走文件系统（队列）和 Unix Domain Socket。这是 Postfix 能在极端负载下保持稳定的根本原因——任何一个子进程崩溃（包括 segfault），master 会在日志中记录，重新 fork，邮件数据不受影响。

三、五队列系统：从 incoming 到投递

队列是 Postfix 的持久化总线。所有邮件在投递过程中的任何时刻都位于磁盘上的某个队列目录中。Postfix 使用 queue_directory（默认 /var/spool/postfix）下的分层目录结构来管理队列文件。每封邮件在队列中以两个文件的形式存在：一个包含信封信息（收件人列表、发件人地址、到达时间），另一个包含邮件正文和信头。这种双文件设计使队列操作（扫描、删除、重新排队）只需操作几十字节的信封文件，而无需触碰可能达到数十 MB 的正文文件。

队列目录作用邮件生命周期阶段
maildrop maildrop/ 本地提交队列：当用户通过 /usr/sbin/sendmail 命令行提交邮件时，postdrop(1) 将邮件写入此处。pickup(8) 定期扫描此目录并拾取邮件 提交
incoming incoming/ 入站队列：cleanup(8) 处理完的邮件首先写入此队列。qmgr(8) 检测到新邮件后将文件移入 active 队列。这个"先写入 incoming、再移入 active"的两步写入是 Postfix 的可靠性保证——写入 incoming 期间如果系统崩溃，文件只损毁不丢失 接收
active active/ 活动队列：qmgr(8) 实际调度投递的队列。qmgr 用内存中的调度器维护此队列的投递尝试状态——哪些邮件正在投递、哪些收件人已成功、哪些失败待重试。限制：active 队列的条目数受 qmgr 内部内存预算约束，默认约 20,000 封 投递中
deferred deferred/ 延迟队列：投递失败（临时故障，4xx 响应）的邮件存放处。qmgr 会按指数退避策略（初始几十分钟，最大数小时）重新将其移回 active 重试。长时间无法投递的邮件在此停留直至 maximal_queue_lifetime 到期后被退回 等待重试
hold hold/ 暂停队列：管理员手动将邮件移入此处（通过 postsuper -h）。hold 队列中的邮件不会被 qmgr 调度。典型场景：正在排查某封可疑邮件的来源，临时冻结其投递以便取证 管理员暂停
corrupt corrupt/ 损坏队列：队列文件在读写过程中发生不可恢复的损坏时，Postfix 自动将其移入此目录。管理员应定期检查此目录——如果文件持续出现，排查磁盘或文件系统问题 异常

邮件在队列间的流转遵循以下路径（正常流程）： 

maildrop ──(pickup)──> incoming ──(qmgr)──> active ──(投递代理)──> 远程MTA/本地邮箱
                          │                      │
                          └──────────────────────┼── 投递失败(4xx) ──> deferred
                                                 │        │
                                                 │   (qmgr 重试)
                                                 │        │
                                                 └────────┘

hold 队列为手动插入路径（postsuper -h），
corrupt 队列为异常迁移路径（自动触发）。

四、Content Filter：管道式内容检查

Postfix 的内容过滤支持通过三种机制实现：before-queue 过滤、after-queue 过滤、以及通过 SMTP 访问策略委托（RFC 要求的外部程序调用）。每种机制在延迟、可靠性和功能完整性上有根本区别。

Before-queue 过滤：邮件在进入 incoming 队列之前经过外部内容过滤器（如病毒扫描器、垃圾邮件引擎）的检查。实现方式：在 master.cf 中定义一个基于 smtpd 的过滤服务（通常在端口 10025），主 smtpd 通过 content_filter = smtp:[127.0.0.1]:10025 将邮件直接注入该过滤端口。过滤器检查完毕后通过 sendmail 命令将邮件重新注入 Postfix（回到 cleanup 管道）。优点：不接受有问题的邮件，垃圾邮件/病毒不会被写入队列，节省磁盘 IO。缺点：过滤延迟直接影响 SMTP 对话——如果过滤器处理慢或崩溃，远程发送方将遇到超时，导致邮件被重新排队到发送方队列。

After-queue 过滤：邮件先写入 incoming 队列（SMTP 对话已完成，发送方已收到 250 OK），然后由 qmgr 通过 pipe(8) 或 smtp(8) 交付给外部过滤器。过滤器处理完毕后通过 sendmail 重新注入。优点：SMTP 对话不受过滤器延迟影响；过滤器崩溃不会导致 SMTP 连接超时。缺点：邮件已经接受并写入磁盘，如果过滤器判定为垃圾/病毒，需要生成退信通知（投递后的"事后拒绝"在用户体验上不够理想，且退信本身可能成为 backscatter 问题）。

SMTP 访问策略委托（RFC 要求）：Postfix 的 smtpd 在 SMTP 对话的不同阶段（连接、HELO/EHLO、MAIL FROM、RCPT TO、DATA、EOD）可以调用外部策略服务。这个机制基于简单的行协议——smtpd 将上下文信息（客户端 IP、HELO 名称、发件人地址、收件人地址等）通过 socket 发送给策略守护进程，后者返回一个动作（OK/REJECT/DUNNO 等）。策略委托在 RCPT TO 阶段执行时可以在邮件数据到达之前拒绝，是最高效的拦截点。例如，Postfix 内置的 check_policy_service 配合 greylisting 守护进程（如 postgrey）就是在这一层工作。 

# master.cf 中的 after-queue Content Filter 示例
# 定义一个过滤服务（通过 pipe 交付）
filter    unix  -       n       n       -       10      pipe
  flags=Rq user=filter argv=/usr/local/bin/mail-filter -f ${sender} -- ${recipient}

# main.cf 中启用 after-queue 过滤
content_filter = filter:

# before-queue 过滤示例：在 master.cf 中定义额外的 smtpd 实例
127.0.0.1:10025 inet  n       n       n       -       10      smtpd
  -o content_filter=
  -o local_recipient_maps=
  -o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
  -o smtpd_helo_restrictions=
  -o smtpd_client_restrictions=
  -o smtpd_sender_restrictions=
  -o smtpd_recipient_restrictions=permit_mynetworks,reject
  -o mynetworks=127.0.0.0/8
  -o smtpd_authorized_xforward_hosts=127.0.0.0/8

Milter 集成：Postfix 2.3 及之后版本通过 sendmail 兼容的 milter 协议支持外部过滤器。与策略委托不同，milter 可以修改邮件头、修改正文、甚至在不完全拒绝邮件的情况下添加头标记。milter 应用（如 OpenDKIM、MIMEDefang、rspamd 的 rmilter）通过 Unix socket 与 Postfix 通信。在 main.cf 中通过 smtpd_milters 和 non_smtpd_milters 配置，milter 的调用时机比 SMTP 访问策略晚（在 DATA 阶段），因此开销稍高，但功能更灵活。

五、性能调优：关键参数与基准

Postfix 的默认调优参数面向 1999 年的硬件水平（单核 CPU、512MB 以下内存、IDE 磁盘）。在现代硬件上不加调整地使用默认值意味着大量性能被闲置。以下是关键参数及调优建议，注意所有 postconf 示例均需要 root 权限或在 main.cf 中修改后执行 postfix reload。

参数默认值建议值说明
default_process_limit 100 100~200 全局进程数上限。影响所有未单独指定 process_limit 的服务。在 64GB+ 内存的服务器上可设为 200~300，前提是磁盘 IO 能跟上
qmgr_clog_warn_time 300s 300s qmgr 活动的"心跳"日志输出间隔。如果连续 qmgr_clog_warn_time 无日志输出，将写入警告。这个值无需调整，但管理员应关注此警告——它意味着队列调度停滞
smtpd_client_connection_count_limit 50 10~30 同一客户端 IP 的并发连接数上限。发送大量邮件的合法 MTA（如大公司邮件服务器）可能需要更高值，但对普通垃圾邮件源来说降低此值能显著减少资源占用
smtpd_client_message_rate_limit 0（无限制） 10~30 同一客户端每秒可发送的邮件数上限。配合 anvil(8) 服务的速率计数值使用——如果 anvil 未启用（在 master.cf 中），此参数无效
smtpd_client_recipient_rate_limit 0（无限制） 100~300 同一客户端每秒可指定的收件人数上限。防止邮件炸弹式攻击
default_destination_concurrency_limit 20 20~50 到同一目的地的最大并发 SMTP 连接数。增大此值可加快出站投递速度，但可能触发远程服务器的连接限制
default_destination_recipient_limit 50 50~100 单次 SMTP 连接中可投递的最大收件人数。对大部分收件人在同一域的邮件（如发往 @qq.com 的批量邮件）提高此值可显著减少连接建立开销
smtp_connection_cache_on_demand yes yes（维持） 启用出站 SMTP 连接缓存。smtp(8) 在与远程 MTA 完成一次投递后，将该连接保持打开一段时间（由 smtp_connection_cache_time_limit 控制），后续发往同一目的地的邮件可复用该连接，减少 TCP 握手和 TLS 协商开销
smtp_connection_cache_time_limit 2s 10s~60s 缓存的出站连接保持时长。增大此值在高频发送场景中效果显著，但如果远程服务器主动关闭空闲连接，实际缓存命中率不会同步提升
smtp_tls_session_cache_database （空，不启用） btree:/var/lib/postfix/smtp_scache TLS 会话缓存。启用后 smtp(8) 可将 TLS 会话参数存入 btree 数据库，下次连接同一目的地时尝试会话恢复（RFC 5077），省去完整的 TLS 握手（节省 1-2 个 RTT）
smtpd_tls_session_cache_database （空，不启用） btree:/var/lib/postfix/smtpd_scache 服务端 TLS 会话缓存。与客户端对称，允许入站连接复用 TLS 会话
smtp_tls_security_level （空，不写即 may） may 或 dane 出站 TLS 策略。根据 RFC 3207（STARTTLS）和 RFC 8314（隐式 TLS）定义的等级设置。may=尝试 TLS 但允许回退；encrypt=强制 TLS；dane=基于 DNSSEC TLSA 记录的证书验证
maximal_queue_lifetime 5d 2d~5d 邮件在 deferred 队列中的最大停留时间。超时后生成退信并删除。减小此值可以让反复失败的邮件早些退信，减少队列膨胀
bounce_queue_lifetime 5d 1d~3d 退信本身在队列中的最大停留时间。退信投递失败不会产生"退信的退信"，超时后直接丢弃
qmgr_message_active_limit 20000 20000~50000 active 队列的最大邮件数。在大规模邮件服务器上（日均百万封出站），需要增大此值以避免新邮件卡在 incoming 中等待移入 active
qmgr_message_recipient_limit 20000 保持或增大 单封邮件的收件人数上限。群发邮件的每个收件人都占用 active 队列中的一个 slot，如果系统处理大量大收件人列表的邮件，需增大此值

bulk-mode 与 connection_cache：Postfix 有两个批量投递优化机制，在调优文档中经常被混淆。smtp_connection_cache_on_demand 是连接级缓存——同一次 smtp(8) 进程生命周期内复用连接。default_destination_concurrency_limit 则控制到同一目的地的并行连接数。两者互动产生实际效果：如果连接缓存时间很短但并发连接数很高，相当于每次投递都重新建连，缓存实质无效；如果缓存时间很长但并发很低，队列中的其他邮件等待同一个连接释放才能发送，造成投递延迟。

六、队列诊断命令

日常运维中最常用的三个命令：postqueue 查看队列状态、qshape 可视化队列分布、postconf 检查配置。 

# 查看所有队列摘要（等同于 mailq）
$ postqueue -p
-Queue ID-  --Size-- ----Arrival Time---- -Sender/Recipient-------
A1B2C3D4E5  12345   Sat Jul  4 07:30:00  sender@example.com
                                          recipient@domain.com

-- 12 Kbytes in 3 Requests.

# 按域分组查看队列分布
$ qshape deferred
                T  5  10  20  40  80 160 320 640 1280 1280+
TOTAL          42  8   5   7   9   5   4   2   1    1     0
gmail.com      12  3   1   2   3   1   1   1   0    0     0
outlook.com     8  2   1   1   2   1   0   1   0    0     0
qq.com          6  1   1   1   1   1   1   0   0    0     0
example.com     5  0   1   2   1   1   0   0   0    0     0

# qshape 输出解读：按邮件在队列中的停留时间分桶
# T=Total, 5=1-5分钟, 10=6-10分钟, 20=11-20分钟...1280+=超过1280分钟
# 如果大量邮件堆积在 1280+ 分钟，说明目的地持续不可达或已永久 5xx 拒绝

# 查看各队列总体情况
$ qshape
                T  5 10 20 40 80 160 320 640 1280 1280+
active          18 18  0  0  0  0   0   0   0    0     0
deferred        42  8  5  7  9  5   4   2   1    1     0
incoming         0  0  0  0  0  0   0   0   0    0     0
hold             3  3  0  0  0  0   0   0   0    0     0

# 将一封邮件从 active 移入 hold（暂停投递）
$ postsuper -h A1B2C3D4E5

# 从 hold 放回 deferred / active
$ postsuper -H A1B2C3D4E5

# 清空 deferred 队列中的所有邮件（谨慎！）
$ postsuper -d ALL deferred

# 重新排队所有 deferred 邮件（例如修复了投递路由问题后）
$ postsuper -r ALL deferred

# 查看非默认配置（最常用的排错命令）
$ postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
inet_interfaces = all
mail_owner = postfix
mydestination = $myhostname, localhost.$mydomain, localhost
myhostname = mail.example.com
mynetworks = 127.0.0.0/8, 192.168.1.0/24
queue_directory = /var/spool/postfix
smtp_tls_security_level = may
smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.com/privkey.pem
smtpd_tls_security_level = may

七、main.cf 关键参数表

以下按照功能域整理 main.cf 中最常涉及的核心参数，便于管理员在配置和排错时快速定位：

功能域参数类型简要说明
基础配置 myhostname FQDN 本机完全限定域名，Postfix 所有自动生成的引用（如 EHLO 名称、Received 头）以此为基准
mydomain域名本域，默认从 myhostname 中剥离主机名部分
myorigin域名本地发出的邮件中发件人地址的默认域，默认 = $myhostname，通常设为 $mydomain
mydestination域名列表本机负责本地投递的域。匹配此列表的收件人邮件由 local(8) 投递
mynetworksCIDR 列表受信任的客户端网络范围。此范围内的客户端绕过绝大部分 SMTP 限制
inet_interfaces接口Postfix 监听网络接口。all=全部，loopback-only=仅本地
邮件限制 message_size_limit 字节数 单个邮件最大体积（含信封和信头），默认约 10MB
mailbox_size_limit字节数单个本地邮箱最大体积，0=无限制
recipient_limit整数单封邮件的收件人数上限
maximal_queue_lifetime时间在队列中的最大停留时间
delay_warning_time时间投递延迟警告通知时间
TLS / 安全 smtpd_tls_security_level 等级 入站 TLS 策略：may/encrypt。参考 RFC 3207
smtp_tls_security_level等级出站 TLS 策略：may/encrypt/dane。参考 RFC 3207, RFC 7672
smtpd_tls_cert_file路径服务器证书（含中间 CA）
smtpd_tls_key_file路径服务器私钥
smtpd_tls_session_cache_databasebtree 路径TLS 会话缓存路径，RFC 5077
smtp_tls_session_cache_databasebtree 路径出站 TLS 会话缓存
限制类 smtpd_client_restrictions 限制列表 客户端连接级限制规则链
smtpd_helo_restrictions限制列表HELO/EHLO 名称的验证规则
smtpd_sender_restrictions限制列表MAIL FROM 阶段的限制规则
smtpd_recipient_restrictions限制列表RCPT TO 阶段的限制规则（最关键的限制层）
投递控制 transport_maps hash 表路径 指定特定域/收件人的投递方式（smtp/lmtp/local 等）
relayhost主机名 所有出站邮件的下一跳中继主机（留空=直接投递）
default_transport传输方式默认投递方式，默认为 smtp
default_destination_concurrency_limit整数同一目的地并发连接数
smtp_connection_cache_on_demand布尔是否启用出站连接缓存

八、设计哲学：Postfix 的可靠性保证

Postfix 架构的五个核心可靠性设计原则，来自 Venema 在 comp.security.unix FAQ 中发布的 Postfix Architecture Overview 文档：

1. 无内存状态 = 无内存崩溃：所有邮件数据永远先落盘再处理。smtpd 在收到 DATA 结束的 . 后不返回 250 OK 直到 cleanup 完成磁盘写入；qmgr 不把投递状态放在纯内存中——每次投递尝试结果立即写入队列文件。系统崩溃后重启，qmgr 扫描队列文件恢复调度状态，不丢邮件、不丢投递进度。这是 Postfix 设计中最根本的一条：把磁盘当作唯一的持久化状态存储，进程只为速度做内存缓存。

2. 最小权限隔离：每个守护进程拥有自己的 chroot 环境和独立用户。smtpd 运行在 postfix 用户下，权限仅限于读写队列和监听网络端口；local 投递代理需要 root 权限来切换为用户身份写入邮箱，但仅在投递的最后一步进行权限提升并立即释放。没有一个进程同时拥有"接收邮件"和"写入用户文件"的权限——攻击者即便控制了 smtpd 也无法直接写入用户邮箱。

3. 文件系统即通信协议：进程之间不通过共享内存、信号或 Unix socket 传递邮件数据。smtpd → cleanup → incoming 队列 → qmgr → smtp/local 的整条流水线中，每步之间都是磁盘文件。这消除了进程间通信的竞态条件和死锁风险，也让调试变得简单——任何阶段的邮件可以手动从队列目录中拷贝出来用 postcat 检查。

4. 优雅降级而非崩溃：如果某个外部服务（DNS、LDAP、MySQL 查找表）不可用，Postfix 默认返回临时失败（4xx 状态码），邮件进入 deferred 队列等待重试。系统不会因为外部依赖宕机而拒收邮件。这个行为可以通过配置收紧（如在 smtpd_recipient_restrictions 中硬拒绝查表失败），但不建议。

5. 退信必须可读：Postfix 生成的退信（bounce）包含原始错误信息、完整的邮件头、可选的邮件正文片段，甚至提供 SMTP 对话原文。这与 Sendmail 时期晦涩的退信形成鲜明对比。退信还包含明确的 "Reporting-MTA" 字段（RFC 3464 DSN 格式），收件人可以直接从退信中定位问题。

九、典型排错场景

场景 1：deferred 队列堆积，但 qshape 显示大部分邮件在 20 分钟内。 分析：如果邮件在 deferred 中但年龄不高，说明目的地在重试——可能是远程服务器偶发性返回 4xx（灰名单、临时限流）。用 qshape deferred 按域查看，找到占比最高的目的域，然后 mailq | grep '目的域' | head -5 查看具体错误。如果是灰名单，等几分钟自动恢复；如果是远程服务器容量不足，联系对方管理员。

场景 2：deferred 队列持续增长，所有邮件年龄超过 640 分钟。 分析：目的地持续不可达（网络断开、DNS 解析失败、远程服务器下线）。检查 /var/log/maillog 中对应域的实际 SMTP 对话错误——是 "Connection timed out"（网络问题）还是 "Name service error"（DNS 问题）还是 5xx 永久拒绝后被错误配置的软弹处理卡住。

场景 3：active 队列为空，incoming 队列有邮件但不减少。 分析：qmgr 可能卡住了。检查 postfix status 确认 qmgr 进程存在；检查 /var/log/maillog 中是否有 qmgr 错误（如 "fatal: " 开头的行）。qmgr 卡住的常见原因有：队列目录权限变化（postfix 用户无读写权限）、磁盘满（队列文件无法创建或改名）、进程被 oom-killer 终止。

场景 4：启用 TLS 会话缓存后，日志中出现大量 "TLS session reused"。 这是好消息——说明会话恢复正常工作，每次出站连接节省了约 1 个 RTT 的 TLS 握手时间。可以用以下命令检查缓存命中率： 

# 检查 TLS 会话缓存内容
$ postmap -s btree:/var/lib/postfix/smtp_scache | wc -l
547

# 检查服务端 TLS 会话缓存
$ postmap -s btree:/var/lib/postfix/smtpd_scache | wc -l
312

总结

Postfix 的多进程架构不是"用多个进程比较安全"的表面选择，而是一套经过形式化验证的工程设计——每个守护进程独立承受故障、独立被 master 守护和重启、独立限制资源。五队列系统的磁盘优先设计确保了从 incoming 到 deferred 的每个环节都有持久化保证。Content Filter 的管道机制使病毒扫描、垃圾检测等外部逻辑可以无侵入地嫁接在邮件流上。掌握了这些架构层面的知识，管理员的日常运维（查看 qshape、调整 maxproc、排查队列堆积）就不再是盲目试错，而能精确地对症下药。

参考来源：RFC 5321 - Simple Mail Transfer Protocol; RFC 3207 - SMTP Service Extension for Secure SMTP over TLS; RFC 8314 - Cleartext Considered Obsolete: Use of TLS for Email; Postfix Architecture Overview (Wietse Venema, comp.security.unix FAQ); Postfix SMTP Access Policy Delegation 协议文档; Postfix 官方文档 (http://www.postfix.org/documentation.html)。