Ubuntu 18.04下Postfix邮件中继配置实战指南

1. 为什么在 Ubuntu 18.04 上亲手部署 Postfix 仍是运维基本功

Postfix 不是那种装完就扔的“一次性工具”，它是 Linux 系统里真正扛起邮件中转大梁的底层服务。很多人看到“Ubuntu 18.04”这个版本号，第一反应是“太老了，该升级了”，但现实恰恰相反——大量生产环境中的监控告警系统、CI/CD 流水线通知模块、内部工单系统的自动回执功能，至今仍稳定运行在 Ubuntu 18.04 LTS（长期支持版）之上。它的生命周期官方支持到 2028 年 4 月，这意味着你今天配好的一套 Postfix，只要不碰核心依赖变更，五年内几乎不用动它。这不是技术保守，而是对稳定性的极致尊重。

我去年接手一个金融后台系统的告警链路改造，发现所有 Slack 和邮件告警都卡在一台跑了五年的 Ubuntu 18.04 虚拟机上。运维同事说“这台机器不能动，一动全链路告警就断”。我查日志才发现，它用的正是 Postfix + 自定义 shell 脚本做 SMTP 中继，连 TLS 都没开，纯明文走内网。当时我就意识到：不是大家不想用新方案，而是旧方案太稳、太轻、太可控。Docker 化的邮件服务？启动慢、依赖多、出问题要查三层日志；云邮箱 API？要配密钥、有调用量限制、网络策略还得额外放行。而 Postfix，一条 apt install postfix ，再改三行配置，5 分钟内就能让 echo "test" | mail -s "hello" admin@local 成功落地到收件箱——这种确定性，在关键业务场景里比任何炫技都值钱。

关键词里没有明确给出具体用途，但结合“Install”和“Configure”这两个动作本身，就能锁定真实需求：不是要搭建公开邮件服务器（那得配 SPF/DKIM/DMARC，还要防被黑成垃圾邮件中继），而是为本地系统服务提供 可靠的、可审计的、低延迟的邮件投递能力 。比如 Jenkins 构建失败后发通知、Zabbix 告警触发时发邮件、Logwatch 每日摘要自动推送——这些场景下，Postfix 的角色更像一个“系统级邮局管理员”，它不对外收信，只负责把本机生成的邮件，干净利落地交给上游 SMTP 服务商（如腾讯企业邮、阿里云邮件推送）或内网另一台中心邮件服务器。

这里有个关键认知差：很多人以为“配置 Postfix 就是填个 SMTP 地址”，其实远不止。Postfix 的核心价值在于它的 分层控制能力 ——你可以精确指定：哪些用户发的信允许外发（ myorigin ）、哪些域名的信必须走特定中继（ transport_maps ）、哪些收件人地址要强制重写（ canonical_maps ）、甚至某类主题的邮件要自动抄送审计邮箱（ always_bcc ）。这些能力不是靠插件堆出来的，而是写在 /etc/postfix/main.cf 里的原生命令。它不像 Web 应用那样有图形界面点点点，但正因如此，它的行为完全透明、可版本化、可 diff、可一键回滚。我把这套配置文件直接放进 Git 仓库，每次修改都有 commit message 记录“为何要加这一行”，上线前还能用 postconf -n 快速校验当前生效参数——这种掌控感，是任何 SaaS 邮件服务给不了的。

所以，这篇文章不讲“如何用 Postfix 搭建 Gmail 替代品”，也不教你怎么发钓鱼邮件。我们要做的，是还原一个真实运维现场：一台刚装好的 Ubuntu 18.04 服务器，没有预装任何邮件服务，你需要在 15 分钟内让它具备发送系统通知的能力，并确保三年后你换人接手时，他看一眼配置就能懂你在做什么、改哪里不会翻车。这才是“Install and Configure”的本质——不是完成安装动作，而是建立可持续维护的通信基础设施。

2. 安装阶段的三个隐形陷阱与绕过方案

在 Ubuntu 18.04 上执行 sudo apt install postfix 看似简单，但实际操作中，有三个高频踩坑点，它们不会报错，却会让后续配置全部失效。我见过太多人卡在“明明配置写了，但邮件就是发不出去”，最后发现根源全在这一步。

2.1 陷阱一：交互式配置向导的默认选项埋雷

安装过程中会弹出一个基于 debconf 的文本界面（ncurses），让你选择服务器类型。选项有四个：

• Internet Site（互联网站点）
• Internet with Smarthost（带智能主机的互联网站点）
• Satellite system（卫星系统）
• Local only（仅本地）

绝大多数人凭直觉选第一个“Internet Site”，觉得“我就是要联网发邮件啊”。但这是最大误区。选它之后，Postfix 会把本机当成 权威邮件服务器 ，尝试直接连接收件人 MX 记录进行投递。这意味着：

• 如果你发 admin@example.com ，Postfix 会自己去查 example.com 的 MX 记录，然后直连对方 SMTP 端口；
• 一旦对方启用了反垃圾策略（如要求 TLS、验证 HELO 域名、限制并发连接），你的邮件大概率被拒收或进垃圾箱；
• 更糟的是，很多云厂商（如阿里云、腾讯云）的 ECS 默认屏蔽 25 端口出站，你连连接都建立不了。

正确做法是选 “Internet with Smarthost” 。这个选项会引导你输入上游 SMTP 中继地址（smart host），比如 smtp.exmail.qq.com:587 或 smtp.mailgun.org:587 。Postfix 从此只做一件事：把本机生成的邮件，原样打包，通过加密通道（STARTTLS）转发给这个中继服务器，由它来搞定所有复杂的投递逻辑。这就像你寄快递不自己开车跑全国，而是交给顺丰统一处理——既规避了端口限制，又复用了专业服务商的信誉白名单。

提示：如果安装时手快选错了，别重装！用 sudo dpkg-reconfigure postfix 重新进入向导即可。注意：此命令不会清空已有配置，只会覆盖 main.cf 中被向导管理的参数（如 mydestination , relayhost ），其他手动添加的行保留。

2.2 陷阱二：systemd 服务状态的“假启动”

安装完成后，系统会自动启动 postfix.service 。但你执行 sudo systemctl status postfix 时，可能看到绿色的 active (exited) ，误以为服务已就绪。实际上，Postfix 的主进程（ master ）是独立于 systemd 启动脚本之外的。 active (exited) 只表示 systemd 执行了 /usr/sbin/postfix start 这条命令并成功返回，但 master 进程是否真在跑，得另查。

验证方法只有两个：

1. sudo ss -tlnp | grep :25 —— 查看 25 端口是否被 master 进程监听（注意：仅当本机需接收邮件时才需要监听 25，我们当前场景不需要）；
2. sudo postqueue -p —— 查看邮件队列状态。如果返回 Mail queue is empty ，说明 master 已启动且工作正常；如果报错 postqueue: fatal: Queue directory missing ，则 master 根本没起来。

我遇到过最诡异的一次： systemctl status 显示 active， postqueue -p 却报错。排查发现是 /var/spool/postfix 目录权限被误删， chown -R root:root /var/spool/postfix 并 chmod 755 /var/spool/postfix 后恢复正常。Postfix 对目录权限极其敏感，它要求 /var/spool/postfix 所有者必须是 root:root ，子目录如 maildrop 必须是 postfix:postdrop ，否则 master 进程启动时会静默失败。

2.3 陷阱三：防火墙与 AppArmor 的双重拦截

Ubuntu 18.04 默认启用 ufw （Uncomplicated Firewall）和 apparmor 。虽然我们不监听外部 25 端口，但 Postfix 内部组件间通信（如 qmgr 与 smtp 进程）依赖 Unix socket 和本地 TCP 端口（如 127.0.0.1:10025 ），这些路径可能被安全策略阻断。

典型症状： mail 命令执行无报错，但 sudo tail -f /var/log/mail.log 发现日志停在 sending via relayhost ，后续无任何 status=sent 记录。用 sudo strace -p $(pgrep master) -e trace=connect,sendto 抓包，会看到 connect(10, {sa_family=AF_INET, sin_port=htons(587), sin_addr=inet_addr("123.123.123.123")}, 16) = -1 EACCES (Permission denied) —— 这是 AppArmor 在拦截。

解决步骤：

1. 临时关闭 AppArmor 验证： sudo systemctl stop apparmor ，再试发邮件。若成功，则确认是它导致；
2. 永久修复：编辑 /etc/apparmor.d/usr.sbin.postfix.master ，在 #include <abstractions/nameservice> 下添加：

   /usr/lib/postfix/smtp PUx,  
   /usr/lib/postfix/qmgr PUx,  
   capability net_admin,  
   network inet stream,  
   

3. 重载策略： sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.postfix.master ；
4. 重启 Postfix： sudo postfix reload 。

注意：不要直接禁用 AppArmor 全局策略，这会降低系统安全性。Postfix 的 AppArmor profile 是精细控制的，只需按需放开必要权限。

这三个陷阱，每一个都曾让我在凌晨三点对着日志抓狂。它们不写在官方文档里，因为文档假设你是在“干净环境”下操作。但真实世界里，服务器可能装过 Docker、改过 SELinux、或者被 Ansible 脚本批量配置过——这些“历史痕迹”才是故障的真正源头。记住：Postfix 的哲学是“显式优于隐式”，它不会替你猜测意图，你给什么配置，它就严格照做。所以安装阶段的每一步，都要带着“它到底在干什么”的疑问去验证，而不是盲目相信终端输出的 OK。

3. 配置文件的黄金三角：main.cf、master.cf 与 transport_maps 的协同逻辑

Postfix 的配置体系常被初学者视为“一堆杂乱的 .cf 文件”，但其实它有非常清晰的分层逻辑。核心就三份文件，构成一个稳固的“黄金三角”： /etc/postfix/main.cf 定义全局策略， /etc/postfix/master.cf 控制进程模型， /etc/postfix/transport_maps 实现路由决策。理解它们如何协同，比死记硬背参数重要十倍。

3.1 main.cf：不是参数列表，而是策略声明书

main.cf 不是简单的键值对集合，它是 Postfix 的“宪法”。每一行都在声明一条不可妥协的系统规则。比如：

• myhostname = mail.internal.company —— 声明本机在邮件协议中的“法定名称”，所有 HELO/EHLO 问候、邮件头 From 域、证书 CN 都由此派生；
• mydomain = internal.company —— 声明本机所代表的“行政区域”，影响地址解析（如 user@ 自动补全为 user@internal.company ）；
• myorigin = $mydomain —— 声明本机发出邮件的“发件人域”，决定 mail -s "test" user 这种不带 @ 的地址如何补全。

最容易被误解的是 mydestination 。很多人把它当成“允许接收邮件的域名列表”，于是填上 localhost.$mydomain, localhost, $mydomain 。但如果你的场景只是“发信”， 请务必将 mydestination 设置为空 ：

mydestination =  

原因很简单：Postfix 默认会把 mydestination 列表里的域名视为“本机终态收件人”，所有发往这些域名的邮件都会被投递到本地磁盘（ /var/mail/root ）。这不仅浪费资源，更会导致路由混乱——比如你本想把 admin@internal.company 转发给腾讯企业邮，但 mydestination 包含 $mydomain ，Postfix 就直接存本地了，根本不会走 relayhost 。真正的“收信”需求，应由专门的 IMAP/POP3 服务（如 Dovecot）处理，Postfix 只负责“发”。

另一个关键参数是 inet_interfaces 。默认值是 all ，意味着监听所有网卡的 25 端口。但在仅发信场景下， 必须设为 loopback-only ：

inet_interfaces = loopback-only  

这能防止外部网络扫描到你的 Postfix 并尝试投递垃圾邮件（即使你没开认证，Postfix 也会拒绝非 mydestination 的收信请求，但扫描行为本身已构成风险）。

3.2 master.cf：进程工厂的流水线设计

master.cf 是 Postfix 的“进程管理器”，它定义了每个功能模块以何种方式运行。格式为：
service type private unpriv chroot wakeup maxproc command + args

我们重点关注三行：

• smtp unix - - n - - smtp —— 这是 发信出口 。它告诉 master 进程：“当有邮件需要外发时，调用 /usr/lib/postfix/smtp 这个程序，以非特权用户身份运行，不限制 chroot”。
• pickup unix n - n 60 1 pickup —— 这是 本地投递入口 。它监听 /var/spool/postfix/public/pickup 这个 FIFO 队列， mail 命令生成的邮件就丢到这里，由 pickup 进程读取并交由 qmgr 排队。
• qmgr unix n - n 300 1 qmgr —— 这是 队列管家 。它不直接发信，只负责调度：从 pickup 拿邮件 → 根据 transport_maps 决定走哪条路 → 把任务分发给 smtp 或其他传输进程。

为什么强调 qmgr ？因为它是整个流程的“大脑”。当你修改 relayhost 或 transport_maps 后，必须执行 sudo postfix reload （而非 restart ），因为 reload 只会向 qmgr 发送 HUP 信号，让它重新加载配置；而 restart 会杀死所有进程再重建，可能导致队列中断。实测中， reload 的平均耗时是 0.2 秒， restart 是 1.8 秒——在高负载系统上，这 1.6 秒的差异就是几百封邮件的积压。

3.3 transport_maps：让每封邮件走对路的导航图

transport_maps 是 Postfix 最强大的路由机制，它让“发往不同域名的邮件走不同通道”成为可能。比如：

• 发给 @gmail.com 的邮件走 Mailgun（高送达率）；
• 发给 @company.com 的邮件走内网 Exchange（低延迟）；
• 发给 @test.local 的邮件强制重写为 admin@company.com （测试环境隔离）。

实现步骤：

1. 创建映射文件 /etc/postfix/transport ：

   gmail.com       smtp:[smtp.mailgun.org]:587  
   company.com     smtp:[192.168.10.5]:25  
   test.local      smtp:[127.0.0.1]:10025  
   

2. 生成哈希数据库： sudo postmap /etc/postfix/transport （生成 /etc/postfix/transport.db ）；
3. 在 main.cf 中启用： transport_maps = hash:/etc/postfix/transport ；
4. 重载配置： sudo postfix reload 。

这里的关键细节是方括号 [ ] 的作用：它告诉 Postfix “跳过 DNS MX 查询，直接连接方括号内的 IP 或域名”。没有它，Postfix 会先查 smtp.mailgun.org 的 MX 记录，而 Mailgun 的 MX 是用于收信的，不是发信的——这会导致连接失败。

注意： transport_maps 的匹配是 最长前缀优先 。比如你同时有 gmail.com 和 mail.gmail.com 两条规则，发往 user@mail.gmail.com 会匹配后者。这为精细化路由提供了基础。

这个黄金三角的协同逻辑是： main.cf 设定总则（谁可以发、发给谁、怎么发）， master.cf 提供执行单元（谁来干活、怎么调度）， transport_maps 给出动态指令（这封信具体交给谁）。它们共同构成一个可预测、可审计、可扩展的邮件基础设施。下次你看到别人在 main.cf 里堆砌几十行参数，不妨问问：这些参数，是属于“宪法条款”，还是该交给 transport_maps 去动态管理？

4. 认证与加密：为什么 STARTTLS 是底线，而 SASL 是刚需

在 Ubuntu 18.04 上配置 Postfix 发信，绕不开一个现实：主流邮件服务商（腾讯、阿里、Mailgun、SendGrid）早已废弃明文 SMTP（25 端口无加密），强制要求 TLS 加密通道，并使用 SASL（Simple Authentication and Security Layer）进行身份校验。这不是为了增加复杂度，而是对抗日益猖獗的邮件伪造和中间人攻击。忽略这一点，你的配置永远停留在“能跑”，而非“可用”。

4.1 STARTTLS：不是可选项，而是连接建立的第一道门

很多人以为“配置了 relayhost = [smtp.exmail.qq.com]:587 就万事大吉”，但 587 端口本身不保证加密——它只是“提交端口”（Submission Port），真正的加密由 STARTTLS 协议协商。Postfix 的 smtp_tls_security_level 参数就是控制这个协商行为的开关。

必须设置为：

smtp_tls_security_level = encrypt  

含义是：“与中继服务器建立连接后， 必须 发起 STARTTLS 协商，如果对方不支持或协商失败，则拒绝发送邮件”。这比 may （可选）或 encrypt （强制加密）更严格，因为它要求双方都支持 TLS，且证书有效。

但问题来了：Ubuntu 18.04 的 OpenSSL 版本较老（1.1.1），而某些新证书（如 Let's Encrypt 的 ECC 证书）可能不被完全信任。你会看到日志里反复出现：
warning: TLS library problem: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

解决方案不是降级安全级别，而是更新 CA 证书库：

sudo apt update && sudo apt install ca-certificates  
sudo update-ca-certificates --fresh  

这条命令会从 Mozilla 的 CA 证书列表中下载最新根证书，并重建 /etc/ssl/certs/ca-certificates.crt 。实测后，99% 的证书验证失败问题消失。注意：不要手动复制 .crt 文件， update-ca-certificates 会自动处理符号链接和哈希索引。

4.2 SASL：用密码登录“邮局柜台”的唯一凭证

STARTTLS 解决了“信封不被偷看”，SASL 解决了“谁有资格寄信”。腾讯企业邮要求你用邮箱全名（如 admin@company.com ）和授权码（非登录密码）登录；Mailgun 要求 api:key-xxx 这样的 API Key。Postfix 通过 smtp_sasl_auth_enable = yes 启用 SASL，并用 smtp_sasl_password_maps 指向密码文件。

创建 /etc/postfix/sasl_passwd ：

[smtp.exmail.qq.com]:587    admin@company.com:your_app_password  
[smtp.mailgun.org]:587      api:key-1234567890abcdef  

然后生成哈希： sudo postmap /etc/postfix/sasl_passwd 。

关键安全措施：

• sudo chmod 600 /etc/postfix/sasl_passwd* —— 密码文件必须仅 root 可读写，否则 Postfix 启动时会报错并拒绝加载；
• 在 main.cf 中添加： smtp_sasl_security_options = noanonymous —— 禁止匿名登录，强制要求用户名密码；
• smtp_sasl_mechanism_filter = plain, login —— 指定只接受 PLAIN 和 LOGIN 两种认证机制（现代服务商基本都支持）。

这里有个易错点： sasl_passwd 文件里的主机名， 必须与 relayhost 或 transport_maps 中的完全一致 。比如 relayhost = [smtp.exmail.qq.com]:587 ，那么 sasl_passwd 里也必须写 [smtp.exmail.qq.com]:587 ，少一个方括号或端口号，Postfix 就找不到对应密码。

4.3 实战验证：用 telnet 手动走通 TLS/SASL 流程

所有配置写完，别急着发邮件。用 telnet 手动模拟一次完整握手，是排查认证问题的终极手段。步骤如下：

1. telnet smtp.exmail.qq.com 587 —— 建立原始 TCP 连接；
2. 收到 220 ... ESMTP 后，发 EHLO your-hostname ；
3. 查看响应中是否有 250-STARTTLS 和 250-AUTH PLAIN LOGIN —— 确认服务端支持；
4. 发 STARTTLS ，收到 220 Ready to start TLS 后，用 openssl s_client -connect smtp.exmail.qq.com:587 -starttls smtp 进入加密通道；
5. 在加密通道内，发 AUTH PLAIN AGFkbWluQGNvbXBhbnkuY29tAHBhc3N3b3Jk （base64 编码的 \0username\0password ）；
6. 收到 235 Authentication successful 即表示认证通过。

这个过程看似繁琐，但它能精准定位问题环节：是 DNS 解析失败？TCP 连接超时？TLS 协商中断？还是 AUTH 命令被拒？我曾用此法发现，某客户网络策略会重写 SMTP 流量，把 AUTH 命令替换成 XAUTH ，导致认证永远失败——这种底层网络问题，光看 Postfix 日志是找不到的。

提示： openssl s_client 的 -debug 参数可显示完整 TLS 握手细节， -showcerts 可打印服务器证书链，是调试证书问题的利器。

把 STARTTLS 和 SASL 当作“寄信前的安检流程”，而不是可有可无的附加项。它们的存在，不是为了给你添麻烦，而是确保你的邮件能被目标服务器严肃对待——毕竟，一个连基础加密和认证都不愿做的发件方，凭什么让收件方相信你的邮件内容是真实的？

5. 故障排查全景图：从日志定位到逐层剥离的实战链路

Postfix 的日志（ /var/log/mail.log ）是它的“黑匣子”，记录了从邮件生成、排队、路由、连接、认证到最终投递的每一个原子操作。但日志本身不会告诉你问题在哪，它只提供线索。真正的排查，是一套结构化的“逐层剥离”流程：从最外层的用户命令开始，一层层向内验证，直到找到那个最先失败的环节。下面是我用这套方法解决过的真实案例，全程复现排查链路。

5.1 案例背景：Jenkins 构建失败邮件始终不发出

现象：Jenkins 配置了邮件通知，但构建失败后， /var/log/mail.log 里没有任何相关记录， sudo postqueue -p 显示队列为空。第一反应是“Jenkins 没调用 mail 命令”，但 ps aux | grep jenkins 显示 Jenkins 进程确实在运行。

排查链路第一步：确认邮件是否真的生成
Jenkins 发邮件本质是调用系统 mail 命令。我们在 Jenkins 服务器上手动执行：

echo "test body" | mail -s "test subject" admin@company.com  

等待 30 秒， sudo tail -f /var/log/mail.log 依然空白。这说明问题不在 Jenkins，而在 mail 命令本身。

第二步：验证 mail 命令是否接入 Postfix
which mail 返回 /usr/bin/mail （GNU mailutils），它默认使用 /usr/sbin/sendmail 接口。检查：

ls -l /usr/sbin/sendmail  
# 应该指向 /usr/lib/postfix/sendmail  

如果不是，执行 sudo ln -sf /usr/lib/postfix/sendmail /usr/sbin/sendmail 。再次执行 mail 命令，日志终于出现：
postfix/pickup[12345]: 6A7B8C9D: from=<ubuntu@server>, size=321, class=0, nrcpt=1
说明 mail 命令已正确将邮件交给了 Postfix 的 pickup 进程。

第三步：检查队列中邮件的生命周期
sudo postqueue -p 显示：

-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------  
6A7B8C9D     321 Mon Jun 10 14:22:01 ubuntu@server  
 (connect to 127.0.0.1[127.0.0.1]:10025: Connection refused)  
                                         admin@company.com  

关键线索出现了： Connection refused 。Postfix 想把邮件发给 127.0.0.1:10025 ，但没人监听这个端口。查 transport_maps 配置，发现错误地写了：

company.com    smtp:[127.0.0.1]:10025  

本意是让 company.com 邮件走本地一个测试代理，但该代理服务根本没启动。修正为：

company.com    smtp:[smtp.exmail.qq.com]:587  

sudo postmap /etc/postfix/transport && sudo postfix reload ，再发测试邮件，日志变为：
postfix/smtp[12346]: 6A7B8C9D: to=<admin@company.com>, relay=smtp.exmail.qq.com[123.123.123.123]:587, delay=2.1, delays=0.02/0.01/1.8/0.27, dsn=2.0.0, status=sent (250 Ok: queued as 1234567890)

问题解决。整个过程耗时 8 分钟，但每一步都排除了一个可能性，最终精准定位到 transport_maps 的错误路由。

5.2 日志解读核心字段解码表

Postfix 日志行信息量极大，掌握关键字段含义，能瞬间定位问题层级：

特别注意 status=deferred 的日志，它后面通常跟着 retry timeout exceeded 或 connect to ...: No route to host ，这直接指向网络层问题（防火墙、DNS、路由）；而 status=bounced 后跟 550 User unknown ，则是应用层问题（收件人不存在、中继服务器拒绝）。

5.3 三个必做验证动作：让配置“活”起来

所有配置写完，务必执行以下三个动作，它们比任何文档都可靠：

1. postconf -n ：查看当前生效的全部非默认参数
   这个命令会过滤掉所有 # 注释和默认值，只显示你真正修改过的配置。它相当于 Postfix 的“宪法全文”。执行后，快速扫一眼： relayhost 是否正确？ smtp_tls_security_level 是否为 encrypt ？ mydestination 是否为空？如果有遗漏，立刻补上。

2. postmap -q "admin@company.com" hash:/etc/postfix/transport ：实时查询路由结果
   输入收件人地址，立即返回它将被送往哪个中继。这是验证 transport_maps 的最快方式。如果返回空，说明没匹配到规则；如果返回错误地址，说明 transport 文件语法有误（如少了换行、多了空格）。

3. echo "test" | sendmail -v admin@company.com ：用 Postfix 原生命令发信并显示详细过程
   -v 参数会输出每一步操作： >>> MAIL FROM:<ubuntu@server> 、 >>> RCPT TO:<admin@company.com> 、 >>> DATA 、 >>> QUIT 。你能亲眼看到 Postfix 如何与中继服务器对话，哪里卡住一目了然。比 mail 命令更底层，比日志更实时。

这套排查链路，不是为了让你记住所有命令，而是培养一种“分层归因”的思维习惯。Postfix 的强大，在于它的模块化设计；它的难点，也在于模块化带来的责任分散。当你不再问“为什么邮件发不出去”，而是问“在 pickup 、 qmgr 、 smtp 这三个环节中，哪个环节的日志最先中断”，你就已经站在了问题解决者的起点上。

6. 生产就绪 checklist：从测试邮件到三年免维护的交付标准

配置完成不等于项目结束。真正的交付，是让这套 Postfix 服务达到“上线即稳定、三年不操心”的生产就绪状态。以下是我在多个客户现场沉淀下来的 checklist，每一条都来自血泪教训，不是理论空谈。

6.1 基础防护：四道安全围栏

1. 磁盘空间监控 ：Postfix 队列默认存放在 /var/spool/postfix ，如果中继服务器宕机，邮件会持续堆积。设置 queue_minfree = 100000000 （100MB），当剩余空间低于此值，Postfix 自动暂停接收新邮件（ postsuper -r ALL 会失败），避免磁盘写满导致系统崩溃。
2. 连接数限制 ：在 main.cf 中添加 default_destination_concurrency_limit = 5 和 default_destination_recipient_limit = 20 。前者限制同时连接中继服务器的数量，防止单个中继故障拖垮整个队列；后者限制单次连接最多发送 20 封邮件，避免被中继服务器判定为群发而限流。
3. 发信频率控制 ：添加 anvil_rate_time_unit = 3600 和 anvil_status_update_time = 600 ，配合 smtp_destination_concurrency_negative_limit = -2 ，实现“每小时最多发 100 封”的软限制。这能有效防止脚本 bug 导致的邮件风暴。
4. 日志轮转加固 ：Ubuntu 18.04 的 logrotate 默认不包含 /var/log/mail.* 。手动创建 /etc/logrotate.d/postfix ：

   /var/log/mail.log /var/log/mail.err /var/log/mail.info {  
       daily  
       missingok  
       rotate 30  
       compress  
       delaycompress  
       notifempty  
       create 644 syslog adm  
       sharedscripts  
       postrotate  
           /usr/bin/systemctl kill -s HUP rsyslog.service  
       endscript  
   }  
   

   确保日志不会无限增长，且 HUP 信号能通知 rsyslog 重新打开文件句柄。

6.2 可观测性：让运维人员一眼看懂健康状态

1. 自定义监控脚本 ：创建 /usr/local/bin/check-postfix.sh ：

   #!/bin/bash  
   # 检查 master 进程是否存在  
   if ! pgrep -x "master" > /dev/null; then  
       echo "CRITICAL: postfix master process not running"  
       exit 2  
   fi  
   # 检查队列长度  
   QUEUE_LEN=$(postqueue -p 2>/dev/null | grep -c "^[0-9A-F]")  
   if [ "$QUEUE_LEN" -gt 50 ]; then