🔒 邮件安全 FAQ — 加密传输、端口与中继防护

影响范围（证书到期即中断的服务）：(1) SMTP STARTTLS（端口 25/587）——到期的服务器与对端 MTA 无法建立加密连接，如果对方强制 TLS（MTA-STS），发信被拒；(2) IMAPS（993）/ POP3S（995）——客户端无法登录邮箱；(3) HTTPS WebMail ——用户无法通过浏览器访问邮箱。证书过期对所有外发和接收邮件的影响是全栈的，因为所有现代邮件协议都依赖 TLS 加密。

预防方案：
① 使用 Let's Encrypt / ACME 协议自动续签（推荐）。安装 certbot 并配置 cron 任务：

# 每日检查并自动续签（到期 <30 天时）
0 3 * * * certbot renew --quiet --post-hook "systemctl reload postfix dovecot nginx"

② 商业证书：在日历中设置到期前 30 天和 7 天两次提醒
③ 多级告警：监控工具（Zabbix / Prometheus + Blackbox Exporter）配置 HTTPS/STARTTLS 证书到期检查。

紧急恢复：如果证书已经到期——(1) 立即执行 certbot renew --force-renewal；(2) 如无自动续签工具，手动申请并安装证书后重启所有邮件服务；(3) 临时绕过：在 Postfix 中临时设置 smtpd_tls_security_level = may（降低安全等级，仅紧急使用，恢复后改回 encrypt）。

mDNS 干扰邮件 DNS 解析的机制：mDNS（Multicast DNS，RFC 6762）在 Linux 上通过 nsswitch.conf 的 mdns4_minimal 解析器模块或 avahi-daemon 实现。当 Postfix/Dovecot 查询目标域时，如果 DNS 配置不当，mDNS 可能在 DNS 解析链中插入 ".local" 域或拦截以特定后缀结尾的域名查询，导致本该发送到公网 MTA 的邮件被错误地解析为本地服务。

典型症状：
(1) 邮件队列中出现大量 connect to ...: Connection refused 但目标邮件服务器实际在线；
(2) /var/log/mail.log 中出现向 224.0.0.251（mDNS 组播地址）或 127.0.0.1 的怪异连接尝试；
(3) postqueue -p 中邮件延迟数小时，目的地址明明是外部域却报告"连接本地主机失败"。

修复：禁用它。在邮件服务器上 mDNS 没有实用价值，反而带来安全隐患（中间人攻击面增加、DNS 欺骗可能性）。执行：

# 停止并禁用 avahi-daemon
systemctl stop avahi-daemon
systemctl disable avahi-daemon

# 检查 /etc/nsswitch.conf，确保 hosts 行不包含 mdns
# 正确示例：
hosts: files dns
# 错误示例（需移除 mdns4_minimal）：
hosts: files mdns4_minimal [NOTFOUND=return] dns

重启 Postfix 和 Dovecot 后生效。验证：getent hosts example.com 确保返回公网 IP 而非本地地址。

背景：IETF 于 2021 年正式废弃 TLS 1.0（1999 年发布）和 TLS 1.1（2006 年发布），发布 RFC 8996 要求所有实现移除对两者的支持。当前邮件生态中，主流邮件服务均已关闭 TLS 1.0/1.1，仅接受 TLS 1.2 及以上。如果你的邮件系统仍在使用旧的 TLS 库（例如 OpenSSL <1.1.1），发往这些域时将出现 TLS 协商失败。

诊断方法：
① 手动测试 TLS 连接：openssl s_client -connect mx.receiver.com:25 -starttls smtp -tls1_2
② 如果上述命令成功但实际发信失败 → 可能是证书链问题（中间证书缺失）。检查：openssl s_client -showcerts -connect ...
③ 检查双方支持的密码套件：openssl s_client -cipher 'ECDHE+AESGCM' -connect ...
④ 查看邮件日志中的具体 TLS 错误——grep "TLS" /var/log/mail.log | tail -20。

修复方案：
(1) 升级 OpenSSL 到 ≥1.1.1（支持 TLS 1.3），并配置 Postfix：

# /etc/postfix/main.cf
smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

(2) 在 Dovecot 中同理设置 ssl_min_protocol = TLSv1.2
(3) 如果是与特定收件域的协商失败且对方确实只支持低版本 TLS，考虑通过邮件中继（邮件系统）转发——但这是临时方案，应推动对方升级。

严重性：开放中继意味着任何人可以通过你的服务器转发邮件——垃圾邮件发送者会滥用你的 IP 和域名发信，导致你的发信信誉迅速恶化，IP 被列入 RBL（实时黑名单），正常邮件被拒收。RFC 5321 Section 3.6 明确要求 SMTP 服务器必须限制中继。

自检方法：
① 在线检测工具——搜索 "Open Relay Test" 使用公开的中继检测服务（如 mxtoolbox.com 的 SMTP 检测），输入你的邮件服务器域名和 IP；
② 手动测试——从外部 IP telnet 你的 25 端口，尝试发一封邮件到外部域：

telnet mail.example.com 25
EHLO test.com
MAIL FROM:<test@test.com>
RCPT TO:<external@gmail.com>
# 如果返回 250 OK 而不是 554 Relay access denied → 你是 Open Relay！

③ 查看日志——grep "Relay access denied" /var/log/mail.log | wc -l 如果为零且从外部可中继，说明配置有问题。

关闭方法（Postfix）：

# 编辑 /etc/postfix/main.cf，确保以下配置存在且正确：
# 1. 定义本地网络（仅允许内部网段不使用认证中继）
mynetworks = 127.0.0.0/8, [::1]/128, 10.0.0.0/8

# 2. 定义本服务器管理的域（仅这些域的邮件可被最终投递，不可被中继出去）
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain

# 3. 明确的中继限制（多重防护）
smtpd_relay_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    defer_unauth_destination

# 4. 重启
systemctl reload postfix

设置后重新执行自检确认 Open Relay 已关闭。如果发现已被列入 RBL，在关闭中继后向对应 RBL 服务申请移除。

端口历史与最佳实践：25 端口是 SMTP 的原始端口（RFC 821, 1982），至今仍在 MTA-MTA 通信中使用。587 端口是 RFC 6409 定义的邮件提交端口（MSA），要求进行 SMTP 认证——这是邮件客户端发信的标准端口。465 端口曾短暂被 IANA 分配给 SMTPS 后又被收回，但在许多邮件客户端中继续使用——RFC 8314 最终重新给予了 465 端口"隐式 TLS 邮件提交"的正式地位。推荐优先使用 587（STARTTLS），兼容性不足时提供 465。

安全建议：(1) 防火墙开放 25/587/993，按需开放 995；(2) 端口 110（POP3 明文）和 143（IMAP 明文）应该封锁或重定向到加密端口，禁止明文传输；(3) 587 端口应强制要求 smtpd_tls_security_level = encrypt（Postfix）和 SMTP 认证。