[2026 Remastered · 04] 告别 /etc/mail.rc 明文密码与 NSS 证书折腾：Debian 13 安全邮件投递与零依赖告警实战

🛸 站长重制导读（Anti Gravi's Remaster Note）

本文是 「来时路 · 2026 Debian 13 真机重制企划（4/12）」 的第 4 篇，对应本站 2020 年 2 月发布的 《linux邮件客户端配置》（CID: 30）。

2020 年的原稿记录了在 CentOS 7 下用 Heirloom mailx 配置 QQ 邮箱告警的过程。站在 2026 年回看，当年那套写法存在三个致命伤：把邮箱授权码明文写进全局可读（0644）的 /etc/mail.rc、一边用 certutil 大费周章导 NSS 证书库一边却写 set ssl-verify=ignore 自废武功，以及 旧版 set smtp=... 变量在现代 s-nail 中已被正式废弃。

我们在 Proxmox VE 的 Debian 13 (s-nail 14.9.25 + msmtp 1.8.28 + curl 8.14.1) 真机上升起一座本地 TLSv1.3 SMTPS 靶机，亲手验证 2026 年最干净、最安全的 Linux 服务器发信方案。

一、 2020 原稿 (`CID: 30`) 三大安全与兼容性硬伤

先对比当年原稿的配置与 2026 生产安全红线：

维度	2020 原稿 (`CID: 30`) 写法	2026 真实环境后果	2026 Remastered (Debian 13) 根治方案
1. 全局可读配置明文泄密	将 `set smtp-auth-password=授权码` 直接追加到 `/etc/mail.rc`（默认权限 `-rw-r--r-- 0644`）	机器上任何低权限用户、容器或存在任意文件读取漏洞的 Web 服务，只需读 `/etc/mail.rc` 即可直接拿走你的核心邮箱授权码	改用 `msmtp` 独立 `0600` 配置文件，并通过 `passwordeval` 从加密凭据或受控命令动态读取密钥，拒绝落盘明文
2. 证书校验左右互搏	先花 5 行命令执行 `openssl s_client` + `certutil -A` 手动构建 `/root/.certs` NSS 数据库，最后却配了 `set ssl-verify=ignore`	既然 `ssl-verify=ignore` 直接关闭了 TLS 证书验证（允许中间人劫持窃听密码），前面导出和导入证书的操作完全成了无效折腾	直接复用 Debian 13 系统级权威根证书库 `/etc/ssl/certs/ca-certificates.crt`，开启严格 TLS 1.3 证书校验
3. Heirloom `mailx` 旧变量废弃	使用 `set smtp=smtps://...`、`set smtp-auth=login`、`set nss-config-dir=...`	现代 Debian 13 搭载的 `s-nail v14.9.25` 已全面转向 v15 语法，旧变量全部触发 `variable superseded or obsoleted` 警告，且已彻底移除 NSS 库支持（改用原生 OpenSSL 3.5）	推荐使用专为服务器发信设计的轻量级 `msmtp`，或零依赖原生 `curl --ssl-reqd smtps://`

Debian 13 真机复现：旧版 `mail.rc` 语法触发废弃警告

我们在 Debian 13 (10.0.0.140) 真机上检查 /etc/s-nail.rc 的默认权限（确认为全局可读的 -rw-r--r--），并尝试传入 2020 原稿的旧变量，当场收到 s-nail v14.9.25 的废弃警告：

=== [1. DEBIAN 13 MAIL TOOLCHAIN VERSIONS] ===
Linux localhost 6.12.96+deb13-cloud-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.96-1 (2026-07-20) x86_64 GNU/Linux
s-nail v14.9.25, 2024-06-27 (built for Linux)
msmtp version 1.8.28
curl 8.14.1 (x86_64-pc-linux-gnu) libcurl/8.14.1 OpenSSL/3.5.7

=== [2. REPRODUCE 2020 CID:30 OBSOLETE SYNTAX & PERMISSION FLAW ON DEBIAN 13] ===
-rw-r--r-- 1 root root 9581 Nov 21  2024 /etc/s-nail.rc
s-nail: Warning: variable superseded or obsoleted: smtp
s-nail: Warning: variable superseded or obsoleted: ssl-verify
s-nail: Warning -- v15-compat=yes will be default in v14.10.0!

二、 2026 方案 A：使用 `msmtp` + `passwordeval` 打造生产级安全发信通道

在不需要接收外部邮件的业务服务器上，千万不要安装笨重的 Postfix / Exim4 常驻监听 25 端口。msmtp 是 Debian 官方源内置的无守护进程 SMTP 客户端，支持 0600 强权限检查与 passwordeval 动态凭据注入。

1. 安装并编写 `0600` 权限配置

sudo apt-get update && sudo apt-get install -y msmtp msmtp-mta ca-certificates

# 强制设定 umask 077，确保创建的配置文件仅当前属主可读 (-rw-------)
umask 077
cat << 'EOF' > ~/.msmtprc
defaults
auth           on
tls            on
tls_starttls   off
tls_trust_file /etc/ssl/certs/ca-certificates.crt
logfile        ~/.msmtp.log

account        qq_alert
host           smtp.qq.com
port           465
from           [email protected]
user           [email protected]
# 使用 passwordeval 动态读取密钥文件或解密命令，避免配置文件直接暴露明文密码
passwordeval   "cat /etc/secrets/smtp_token"

account default : qq_alert
EOF
chmod 600 ~/.msmtprc

提示：安装了 msmtp-mta 包后，系统会自动将 /usr/sbin/sendmail 软链接到 msmtp，这意味着服务器上的 cron 定时任务报错与 mail 命令都会自动走这条加密通道！

三、 2026 方案 B：零额外依赖！直接用系统自带 `curl smtps://` 发邮件

很多极简生产机器或 Docker 容器里既没有装 msmtp 也没有装 s-nail，但 100% 装了 curl！
其实自 curl 7.20+ 起就已经原生内置了完整的 SMTP / SMTPS 协议栈，一行命令即可通过 465 端口（Implicit TLS 1.3）发送标准 RFC 5322 邮件，连一个额外软件包都不用装：

curl --silent --show-error --ssl-reqd \
  --url "smtps://smtp.qq.com:465" \
  --user "[email protected]:$(cat /etc/secrets/smtp_token)" \
  --mail-from "[email protected]" \
  --mail-rcpt "[email protected]" \
  --upload-file - << 'EOF'
From: Zero-G Alert Bot <[email protected]>
To: Ops Team <[email protected]>
Subject: [PROD ALERT] Service Health Check

Sent directly via curl over TLSv1.3 without installing mailx or postfix!
EOF

四、 PVE Debian 13 真机双通道投递实测

为了在不暴露真实公网邮箱凭证的前提下 100% 验证 TLS 握手与 SMTP 状态机，我们在 Debian 13 (10.0.0.140) 真机上启动了一个监听 127.0.0.1:8465 的 TLSv1.3 SMTPS 服务端，分别用 msmtp 1.8.28 和 curl 8.14.1 发起真机投递：

=== [4. TEST METHOD A: MSMTP 1.8 WITH 0600 CONFIG & STRICT TLS CA VERIFY] ===
-rw------- 1 codex codex 364 Nov  4 12:20 /tmp/mail-lab/msmtprc
--- msmtp Delivery Log ---
Nov 04 12:20:23 host=127.0.0.1 tls=on auth=on [email protected] [email protected] [email protected] mailsize=335 smtpstatus=250 smtpmsg='250 2.0.0 OK: queued as ZG20261104' exitcode=EX_OK

=== [5. TEST METHOD B: ZERO-DEPENDENCY CURL SMTPS://] ===

=== [6. SMTPS SERVER RECEIVED PAYLOADS] ===
[SMTPS Server Received Message] (8 lines):
  | Date: Wed, 04 Nov 2026 12:20:23 +0000
  | Message-ID: <[email protected]>
  | From: Zero-G Monitor <[email protected]>
  | To: Ops Team <[email protected]>
  | Subject: [DEBIAN 13 MSMTP] High CPU Load Alert
  | 
  | Node: ds1.zero-g.internal (10.0.0.140)
  | Status: Verified via msmtp 1.8.28 with strict TLS CA validation!

[SMTPS Server Received Message] (1 lines):
  | From: Zero-G Curl Bot <[email protected]>
  | To: Ops Team <[email protected]>
  | Subject: [DEBIAN 13 CURL SMTPS] Zero-Dependency Alert
  | 
  | Sent directly via curl 8.14.1 over TLSv1.3 without installing mailx/postfix!

[!TIP]
真机排障微距镜头：msmtp 与 curl 在 RFC 4954 AUTH PLAIN 上的微妙差异
在编写本地 SMTPS 靶机时我们发现了一个非常有趣的底层协议细节：

msmtp 发送的是单步初始响应：AUTH PLAIN <base64_credentials>\r\n（一行带走，服务端直接回 235 2.7.0 Authentication successful）；

curl 发送的是两步挑战响应：先发不带参数的 AUTH PLAIN\r\n，等待服务端返回 334 \r\n 空挑战后，再发送第二行 <base64_credentials>\r\n！如果自研或内网网关没有处理两步 334 挑战，curl 就会报 curl: (67) Login denied。

五、 2026 架构演进：为什么生产告警正从 SMTP 全面转向 IM Webhook？

2020 年我们习惯配邮箱发告警，但在 2026 年的生产运维中：

公网云服务器常因反垃圾邮件策略被封禁出站 SMTP 端口，或因高频发信触发腾讯/阿里企业邮限流；
邮件折叠在收件箱里极易漏看，而 飞书机器人 2.0 卡片 / Telegram Bot / 企业微信 Webhook 只需走标准 443 HTTPS 端口，支持颜色分级、移动端强提醒与交互按钮，已经成为现代运维告警的首选。

[2026 Remastered · 04] 告别 /etc/mail.rc 明文密码与 NSS 证书折腾：Debian 13 安全邮件投递与零依赖告警实战

一、 2020 原稿 (CID: 30) 三大安全与兼容性硬伤

Debian 13 真机复现：旧版 mail.rc 语法触发废弃警告

二、 2026 方案 A：使用 msmtp + passwordeval 打造生产级安全发信通道

1. 安装并编写 0600 权限配置