可用TCP代理（如Nginx stream）实现四层SMTP透传网关，仅转发原始连接、不解析协议，适用于端口统一暴露、后端分发与传输层策略控制，但不支持应用层路由、TLS干预或语义级健康检查。

可以用 TCP 代理转发原生 SMTP 流量构建邮件代理网关，但需明确：这不是在“解析或改造 SMTP”，而是做纯四层透传——只转发原始 TCP 连接，不碰命令、不改内容、不终止 TLS。核心目标是实现端口映射、后端分发、连接中继和基础高可用。

确认使用场景是否匹配

适合以下情况：

• 已有多个 SMTP 后端（如多台 Postfix 或 Exchange 服务器），需统一对外暴露 25/465/587 端口
• 需要隐藏真实后端 IP，或做简单负载分发（轮询、IP hash）
• 网络边界需做连接限速、超时控制、访问白名单等传输层策略
• 暂不依赖 TLS 卸载、发信认证、内容过滤、灰名单等应用层能力

不适合：

• 要求基于 MAIL FROM 或 RCPT TO 做路由决策
• 需对 STARTTLS 协商过程干预（如强制升级、证书替换）
• 要记录完整 SMTP 会话日志或做协议合规性检查
• 生产环境要求强健康检查（如检测 5xx 响应码、HELO 拒绝等语义级状态）

选用支持四层透传的代理工具

Nginx（1.9.0+）是最常用选择，前提是启用 stream 模块（非 http 模块），且配置必须置于顶层（不能嵌套在 http {} 内）：

• 监听 25 端口并转发到内网两台 MTA：
  stream {
    upstream smtp_backend {
      server 192.168.10.10:25;
      server 192.168.10.11:25;
    }
    server {
      listen 25;
      proxy_pass smtp_backend;
      proxy_timeout 30s;
    }
  }
• 注意：Nginx stream 不支持 TLS 卸载；若后端用 STARTTLS，客户端与后端直接协商，代理仅透传字节流
• 其他可选工具包括 HAProxy（配置简单、健康检查更灵活）、Envoy（支持 TLS 终止但配置复杂）、或自研轻量 Socket 中继（C/Go 实现）

关键配置与安全注意事项

单纯转发不等于安全可用，以下几点必须处理：

• 端口权限：Linux 下绑定 25 端口需 root 权限，建议用 systemd 以 root 启动后降权，或用 authbind
• 连接跟踪与超时：SMTP 交互可能持续数分钟（尤其大附件或 DNS 查询延迟），需调大 proxy_timeout、tcp_nodelay、keepalive_timeout
• 源 IP 保留：默认情况下后端看到的是代理机器的 IP。如需传递真实客户端 IP，只能靠 PROXY protocol（要求后端 MTA 支持，如 Postfix ≥3.4 + `enable_smtp_utf8` 和 `smtpd_proxy_protocol_timeout`）
• 防火墙与反向 DNS：外网 SMTP 流量常被 ISP 或接收方拒收，若代理出口 IP 缺少 PTR 记录或被列入黑名单，转发后仍会失败——代理不解决发信信誉问题

补充高可用与可观测性

单点代理易成瓶颈，建议组合 Keepalived 实现 VIP 故障转移；同时添加基础监控：

• 用 netstat/ss 统计 ESTABLISHED 连接数，防连接耗尽
• 记录 Nginx stream access_log（仅含时间、客户端 IP、后端地址、连接状态），不记录 SMTP 内容
• 配合 tcpdump 抓包定位 TLS 握手失败、RST 异常等底层问题
• 避免依赖“健康检查返回 220”——stream 模块只能做 TCP 连通性探测，无法判断 MTA 是否真能收信