邮件提交与 587 端口
587 是邮件提交（Message Submission）端口，设计用途是让已认证的客户端把邮件交给自己的邮件服务器，再由服务器负责对外投递。它通常要求先建立连接、用 STARTTLS 升级为加密通道，再完成账号认证。与 465 的隐式 TLS 不同，587 首先以明文问候语开始会话；与 25 的区别在于 587 面向客户端提交，且必须认证后才允许发信。
基本信息
| 服务 | 邮件提交（submission） |
|---|---|
| 协议 | TCP |
| 规范 | RFC 6409；加密建议见 RFC 8314 |
| 加密方式 | STARTTLS（先明文问候后升级） |
| 认证要求 | 必须认证后才允许中继发信 |
| 常见服务端 | Postfix、Exchange、Dovecot 提交服务 |
典型使用场景
- 邮件客户端设置发信服务器，普通办公环境最通用的配置项
- 程序化发信：应用通过认证提交发送告警或业务通知
- 移动办公：在外部网络提交到企业服务器，由服务器统一对外投递
- 多客户端兼容：部分老旧客户端只支持 STARTTLS 模式
- 把客户端提交与服务器间投递分离，便于分别套用安全策略
三个端口的角色
| 端口 | 面向对象 | 加密方式 | 是否需认证 |
|---|---|---|---|
| 25 | 服务器之间投递 | STARTTLS 可选 | 否，靠来源与域策略控制 |
| 587 | 已认证客户端提交 | STARTTLS | 是 |
| 465 | 已认证客户端提交 | 隐式 TLS | 是 |
直连 587 验证 STARTTLS 与认证
直连 587 验证 STARTTLS 与认证
openssl s_client -starttls smtp -connect smtp.example.com:587 -crlf # 应看到 220 问候后升级成功
EHLO client.example.com # 查看服务端能力列表
# 关注返回中的 250-STARTTLS 与 250-AUTH，两者都要出现
QUIT返回码判读
| 返回码 | 含义 | 处置方向 |
|---|---|---|
| 220 | 服务就绪 | 可继续会话 |
| 250-STARTTLS | 支持加密升级 | 缺失说明加密不可用 |
| 250-AUTH | 支持的认证方式 | 缺失说明无法认证发信 |
| 235 | 认证成功 | 可提交邮件 |
| 535 | 认证失败 | 核对账号口令与认证方式 |
| 554 | 拒绝中继 | 来源不在允许提交范围内 |
服务端提交配置（Postfix 要点）
服务端提交配置（Postfix 要点）
# master.cf 中启用 submission 服务并强制 STARTTLS
submission inet n - y - - smtpd
-o smtpd_tls_security_level=encrypt # 要求加密后才继续
-o smtpd_sasl_auth_enable=yes # 提交端口必须认证
-o smtpd_client_restrictions=permit_sasl_authenticated,reject # 未认证直接拒绝
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination提交端口若放宽来源限制又不强制认证，会立刻变成开放中继；强制 STARTTLS 前要确认所有客户端都支持，否则会造成部分用户突然无法发信。
587 与 465 的选择：客户端支持隐式 TLS 时用 465 更直观，只支持 STARTTLS 或需要明文降级兜底时用 587；两者同时开放是常见的兼容做法，但都要启用认证与来源限制。
排查发信失败时先看服务端日志中的具体拒绝原因：认证失败与中继被拒是两类完全不同的问题，前者查账号与认证方式，后者查来源地址是否在允许列表内，不要混在一起试。