凌晨两点，监控系统把我从睡梦里拽了出来。告警内容很简单：一批订单通知邮件全部积压，没有一封发出去。我登录服务器，第一件事就是敲下mailq，看到队列里躺着上百封信，状态全部卡在"正在投递"。

那一刻我就知道，问题出在服务器上那个被我忽略了很久的老伙计身上——sendmail。没错，就是那个1983年诞生、让无数运维又敬又怕的传统邮件传输代理。很多刚入行的朋友可能只在面试题里见过它的名字，但现实世界里，它仍然顽固地运行在大量旧系统、内网服务器、嵌入式Linux设备里。这篇博文不是来给你讲历史的，我想把我实际配置sendmail、排查sendmail、最终决定什么时候该抛弃它的完整经验，从原理到命令行，从头到尾捋一遍。无论你是在维护一台老掉牙的RHEL 5，还是为了一个临时需求在内网搭个发信服务，这篇文章都能让你少走弯路。

1. 从一个"发不出邮件"的深夜说起：sendmail的江湖地位与真实处境

1.1 它到底是个什么角色

要理解sendmail，先得明白它在邮件体系里的位置。我们平时用Outlook、Foxmail、或者各种Webmail客户端发信，这些是邮件用户代理（MUA）。而真正负责把邮件从一台机器运送到另一台机器的，是邮件传输代理（MTA）。sendmail就是这样一个MTA。它在OSI应用层上，按照SMTP协议工作，默认监听25端口，负责收信也负责发信。

它的核心工作是三件事：接收本机用户投递的邮件、解析收件人地址并决定投递路线、通过SMTP协议把邮件传送到目标服务器。这听起来不难，但sendmail把这个流程做得极其复杂，复杂到甚至产生了一句流传很广的玩笑话："sendmail的配置文件只有上帝和Eric Allman能完全看懂。"（Eric是它的作者。）

我从2008年开始碰它，当时接手了一台跑着老版本CentOS的内网邮件服务器。那时候我天真地想，不就是发个邮件嘛，改改配置不就行了。结果当我打开/etc/mail/sendmail.cf看到将近一千行密密麻麻的宏定义时，人直接傻了。但正是这段经历，逼着我把它的逻辑彻底搞明白了。

1.2 什么场景下你才会被迫碰它

你不是每天都会遇到sendmail。但下面这些场景，一旦碰到，你没有别的选择，只能硬着头皮上：

• 遗留系统维护：很多国企、传统工厂、学校的内部系统，十几年前就部署了sendmail，运行稳定没人敢动，出了毛病就得你会修。
• 最小化系统安装：有些精简版的Linux发行版（比如早期的容器镜像、某些嵌入式固件），自带的就是sendmail，不装它，很多系统工具（比如crontab发通知、logwatch报告）就没办法正常工作。
• 开发环境模拟：你想本地测一下邮件发送逻辑，不想搭维护成本高的Postfix，直接yum装个sendmail，配置五分钟搞定。
• 合规审计要求：某些行业的老旧审计系统只认sendmail的日志格式，换MTA意味着审计流程重写，成本太高。

我经常跟同事说，你不需要喜欢sendmail，你只需要在它出问题的时候"能收拾它"。这就是写这篇博文的主要动机。

1.3 你需要什么样的基础才能看明白这篇

这篇博文不是零基础入门课程。你应该已经会基本的Linux操作（vi编辑、systemctl重启服务、tail看日志），了解DNS的A记录和MX记录大概是什么鬼。如果你连MX记录是啥都不知道，去补十分钟基础再回来。但如果你是刚接触邮件服务的新手，也别慌，我会尽量把每个命令为什么这么敲、每个配置项背后的逻辑解释清楚，你跟着做，一样能把这台老机器收拾得服服帖帖。

2. 配置文件不是给人看的：sendmail的宏处理与m4体系

2.1 从sendmail.cf到.mc：绕不开的生成链路

很多人拿到sendmail后，第一反应是去编辑/etc/mail/sendmail.cf。但我要先给你泼盆冷水：这不是给人直接改的文件。sendmail.cf是一种混合了宏语言和规则集的文本，里面充满了 $#、$@、$: 这样的符号，看起来就像键盘被猫踩过一样。而且，如果你通过宏文件重新生成配置，所有手改的内容会瞬间被覆盖，排错的时候你根本不知道自己在改什么。

正确的做法是：修改以.mc结尾的宏配置文件，然后用m4工具把它编译成sendmail.cf。这个链路等价于：你用高级语言写好代码，再编译成可执行文件。.mc文件位于/etc/mail/sendmail.mc（CentOS/RHEL系），或者/etc/mail/下其他自定义.mc文件。

我见过有人直接用vi改cf，也没出大事，但那种人基本是能把整个cf背下来的老怪物。对于普通人，我强烈建议你想改任何东西都去改.mc，然后重新生成。

2.2 常用的FEATURE、define、MASQUERADE到底在干嘛

.mc文件的本质是一堆宏命令的集合。我不打算教你怎么从头写一个.mc，那是几百行的工作。我只挑几个高频的、你一定会碰到的宏来解释。

define宏：用来设置全局参数。最常见的是define(\SMART_HOST', `your-relay.example.com')`。这个的意思是：我的sendmail不直接投递邮件到目标服务器，而是把所有外发邮件都扔给一个叫 your-relay.example.com 的智能中继主机。为什么这么干？因为很多公司网络只允许发信到内部中继，不让直接连外网25端口。

FEATURE宏：这是控制sendmail行为方式的开关。比如：

• FEATURE(\access_db')`：启用基于access数据库的收发权限控制。
• FEATURE(\mailertable')`：支持按域指定不同的投递方式。
• FEATURE(\masquerade_envelope')`：在投递时修改信封发件人，配合MASQUERADE_AS使用。

MASQUERADE_AS：设置伪装域名。假设我的机器主机名叫web01.internal.local，但我不想让收件人看到这么难看的发件后缀，就加一行MASQUERADE_AS(\example.com')，再配合FEATURE(`masquerade_envelope')，这样发出的邮件在别人邮箱里显示的发件人就是root@example.com而不是root@web01.internal.local`。

MAILER宏：定义系统支持的投递方式。通常你会看到MAILER(\smtp')和MAILER(`local')` 这两行。没有它们，sendmail就不知道如何把信交给本地邮箱或通过SMTP发出去。

这里的关键认知是：.mc是"配置的配置"，它的目标不是给你直接执行，而是让m4宏处理器把它编译成真正的配置。所以你修改完.mc之后，必须跑一遍编译命令才能生效。

2.3 我当年因为直接改cf付出的代价

有一段经历让我彻底放弃了"直接改cf"这个念头。当时内网一台服务器需要修改发信伪装域名，我一时图快，直接在/etc/mail/sendmail.cf里用vi全局替换了example.net为example.org。替换完重启，看起来一切正常，发信也成功。

但过了两周，公司IT审计要求检查所有服务器的邮件安全配置。我把cf文件打印出来对照官方文档一看，发现那几十处替换里，有两处替换的错误地修改了规则集里"拒绝该域邮件"的判断逻辑，让一个本该被拦截的垃圾域名变成了放行状态。当时的冲击感让我明白：不要在不懂规则集的情况下手改cf，那是真正的"在雷区跳舞"。从那以后，无论多小的修改，我都是改.mc，然后重新用m4生成。

3. 让sendmail把信真正发出去：一套能落地的配置流程

3.1 环境准备：主机名、DNS、依赖包

在动手改配置之前，有三件事必须检查清楚，顺序不能错。

第一，主机名必须是FQDN（完全合格域名）。sendmail启动时会尝试解析主机名，如果它拿不到完整的域名，服务可能无法正常启动。这个坑我踩过不止一次。检查命令：

hostname -f

如果输出不是类似于mail.example.com这样带域名的格式，而是localhost或者一个短名，你得先把/etc/hostname（或/etc/sysconfig/network）和/etc/hosts改好。我在/etc/hosts里添加：127.0.0.1 mail.example.com mail。

第二，检查25端口监听状态。旧版sendmail默认只监听本机的localhost:25，这对客户端发信是够的，但如果你想让它作为外部发信服务器接收远程投递，必须监听所有接口。怎么改后面会讲到。

第三，确认依赖。在CentOS/RHEL上，你需要安装的就是sendmail和sendmail-cf两个包。没有sendmail-cf你连m4编译都做不了。安装命令：

yum install sendmail sendmail-cf m4 -y

3.2 三种典型业务需求，三种核心配置思路

我总结了几个实际工作里最常见的需求，你可以对号入座。这三种需求在配置上有明确的差异。

场景A：纯本地发信，不需要收信。比如监控脚本每天调用mail命令给管理员发告警。这种情况最简单，只需要保证sendmail能够投递到域内或外域即可。实际上默认配置几乎就能用，你只需要确认/etc/mail/local-host-names里包含你的域名，确保本机信件能正确投递。

场景B：通过SMTP中继发送外邮。公司内部网禁止直连外部25端口，要求所有邮件通过指定的邮件中继服务器（比如mailgate.company.com）发送。这就要用到上面提到的SMART_HOST配置。

场景C：作为内网邮件服务器，需要收信并投递到各用户。这需要监听外网接口、启用访问控制、配置本地投递。常见于内网测试环境。

3.3 配置BLOCK级别的实操步骤

假设我们是场景B，一台需要伪装域名、走中继发信的内网服务器。

第一步，备份并编辑/etc/mail/sendmail.mc：

cp /etc/mail/sendmail.mc /etc/mail/sendmail.mc.bak vi /etc/mail/sendmail.mc

在文件里，我们要改动几处关键内容：

• 注释掉DAEMON_OPTIONS里只监听本地端口的行（如果有的话）。
• 添加define(\SMART_HOST', `mailgate.company.com')`，这是核心，它让sendmail把外发信全部交给中继。
• 添加伪装域名行：MASQUERADE_AS(\company.com')`。
• 添加FEATURE(\masquerade_envelope')`。
• 确保MAILER(\smtp')和MAILER(`local')` 存在。

第二步，生成新的sendmail.cf并重启服务：

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf systemctl restart sendmail

这里必须提醒一个细节：m4命令可能会因为缺少include路径而报错。如果报找不到文件，可以执行：

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

如果依然失败，尝试先进入/etc/mail目录再执行。

3.4 为什么这么选型：SMART_HOST和MASQUERADE的取舍逻辑

也许你会问：为什么不直接把DNS MX记录设成自己，然后直发外网？答案是现实网络环境不允许。绝大多数企业的安全策略不允许业务服务器直接跟互联网上的25端口建立连接，因为那是垃圾邮件和病毒的重灾区。所以通过中继服务器发信，既符合网络安全管理的要求，又能让业务服务器保持"轻量"状态。

那为什么需要MASQUERADE_AS？因为内网服务器的主机名通常是web01.corp.internal，如果不做伪装，发出的邮件发件人就是root@web01.corp.internal，这个域名在外网根本不存在，会导致好多反垃圾系统直接把这个邮件标记为可疑，甚至直接拒收。伪装成公司正式域名，能极大提高邮件的送达率。

这个取舍的核心原则是：sendmail的配置要服务于真实网络环境，而不是环境的理想状态。

3.5 配置后的验证清单

配置完不要急着宣布"搞定"，按下面的清单逐项验证，缺一不可：

1. 检查服务状态：systemctl status sendmail，确认active (running)。
2. 查端口监听：netstat -tlnp | grep :25，确认sendmail已经监听在需要的接口上。
3. 发测试信：用sendmail命令直接发一封信：

echo -e "Subject: test mail\n\nhello world" | sendmail -v test@example.com

-v参数会实时打印投递日志，你会看到它尝试连接mailgate.company.com的过程。 4.查队列：mailq。如果输出显示邮件还在队列里，说明投递没成功，进入下一步排查。 5.查日志：tail -f /var/log/maillog，看有没有 "stat=Sent" 的关键字。看到这个单词，这封信才算真正出去了。

4. 队列与日志：排错时你需要的不是玄学，是证据

4.1 邮件队列机制：它为什么要"赖着不走"

sendmail有一个复杂的队列系统，目录通常在/var/spool/mqueue。邮件不是一投递就必须立即成功。当sendmail尝试投递失败时，它会把邮件放进队列，并按一定的时间间隔（默认是一小时）多次重试。连续重试四天不成功，邮件才会被退回发件人。

理解这一点特别重要。很多人查看发信失败，发现mailq里能看到邮件，就以为邮件马上能发出去。我之前犯过这个错误——深夜排查监控告警邮件，发现队列里上百封邮件，一度以为全部卡死，后来才发现是网络断了几分钟，重试还没到时间而已，等网络恢复后每封信都正常投递了。队列不是故障，队列是重试机制。

另一个容易忽略的点：/var/spool/mqueue目录会存放两种文件。qf开头的文件是队列控制文件，df开头的文件是邮件正文内容。这两个文件必须配套存在，如果df文件丢失而qf还在，sendmail会报错。所以清理队列时，要用sendmail -q或者专门的工具，别手动rm，会把队列搞坏。

4.2 日志字段的逐字解读

sendmail的日志是/var/log/maillog，格式看起来唬人，但最关键的是每一行结尾的stat=字段。下面用一个真实日志片段说明：

May 30 03:15:11 mailhost sendmail[1523]: r4U9FBho01523: to=<test@example.com>, ctladdr=<root@mailhost> (0/0), delay=00:00:05, xdelay=00:00:03, mailer=smtp, pri=30090, relay=mailgate.company.com [10.1.1.20], dsn=2.0.0, stat=Sent (OK)

拆开来看：

• relay=mailgate.company.com [10.1.1.20]：这封信实际是通过哪个服务器投递的，这是判断"是否走了中继"的最快方式。
• dsn=2.0.0：投递状态码。以2开头是成功，以4开头是临时失败，以5开头是永久失败。
• stat=Sent (OK)：最终投递结果。

我排查问题时，习惯先grep sendmail /var/log/maillog | grep 'stat='，快速过滤出所有终态，再从中挑出stat=Deferred或stat=Permission denied等异常状态。这样比一页一页翻日志高效得多。

4.3 三个高频坑的完整排查链路

坑一：本地主机名解析不了，邮件积压

现象是mailq里全是本域邮件，日志显示My unqualified host name (mail) unknown。根因是sendmail启动时无法解析主机名的完整域名。排查链路：

1. 检查/etc/hosts，确保有主机名到IP的映射。
2. 执行hostname -f验证。
3. 修改后重启sendmail，并清理旧队列：sendmail -q。

坑二：被中继服务器拒信

现象是日志里stat=Deferred: 503 5.3.5 Config error: mail exchanges this domain not allowed。这通常是因为你的服务器没被中继服务器加入允许列表。这一步只能去找邮件中继的管理员把你的服务器IP加入白名单。没别的办法，别纠结配置。

坑三：权限错误导致本地投递失败

日志里出现stat=System Error: Permission denied。这个我印象很深，因为/var/mail目录的权限或者SELinux上下文不正确，会导致sendmail无法把信写入用户的mailbox。排查链路：

1. ls -ld /var/mail，看属主是否为root。
2. getenforce检查SELinux状态。如果SELinux是 enforcing，加上restorecon -Rv /var/mail恢复上下文。
3. 临时关闭SELinux测试验证：setenforce 0，如果恢复正常就说明是SELinux策略问题，然后针对性地调整布尔值。

这三件事基本上能覆盖我接触过的90%的sendmail故障场景。

5. 实测总结：sendmail的边界与更优解

5.1 什么场景下我仍推荐sendmail

说到最后，很多人会问：sendmail都这个岁数了，是不是该死透了？我的答案是：不同的场景，选择完全不同。

我仍然推荐在下面这些地方坚持用sendmail：

• 对配置没有特别要求的遗留系统。它被验证了十几年，稳如老狗，没事别动它。
• 嵌入式环境或极简容器。postfix虽然也轻，但sendmail是很多发行版自带的，依赖最少。
• 学习目的。如果刚接触邮件系统，熟悉一次sendmail的配置，能让你对SMTP协议和邮件路由的理解比直接用postfix深一个层次。因为sendmail把路由规则、投递选择都暴露出来了。

5.2 什么场景下我会果断换掉它

如果项目是新搭建的、应用未来有增长可能、或者需要大量复杂反垃圾策略，我会直接选Postfix或Exim。

原因很简单：sendmail的配置语言过于晦涩，维护成本极高。一旦遇到复杂需求（比如多域名虚拟邮箱、按IP段路由、与LDAP集成），它的配置难度会指数级上升，而Postfix的主配置/etc/postfix/main.cf只有一百多行，逻辑清晰明了，一个下午就能上手。

另外，现代邮件安全要求TLS加密和SASL认证。sendmail虽然也支持，但配置过程和排错难度比Postfix高出一大截。我在一个项目里被要求在sendmail上配置SMTP AUTH认证，折腾了整整一天，同样的需求在Postfix里半小时搞定。从那以后，新项目我再也没用过sendmail。

5.3 最后分享一段真实体会

我从2008年第一次被迫接触sendmail，到后面在运维中不断跟它周旋，再到后来亲手在公司内部把所有外部邮件服务切换到Postfix，这个过程让我学到一个很重要的道理：工具的价值不在于它有多新，而在于你是否知道它适合解决什么问题。sendmail非常适合"一台机器安静地把信送到该去的地方"这种场景，而一旦你的需求开始复杂化，承认它不合适并果断迁移，才是运维该有的觉悟。

如果你现在手头正有一台带sendmail的老服务器，我的建议是：先别急着抱怨，按这篇文章的思路，花两小时把所有配置和日志摸一遍。等你真的搞懂它的思维逻辑，你会发现，这个"老家伙"其实并不可怕，它只是用了比你想象中更底层的语言来跟你沟通。而你需要的，只是一本能把这门语言翻译成人话的字典而已。