排查邮件发送问题时，端口和加密模式往往是第一道分水岭。端口25作为SMTP默认端口，历史上承担服务器之间的邮件中继，并不强制要求客户端认证和加密，因此在多数云服务器、家庭宽带和托管网络中被上游运营商拦截或限制。客户端如果仍然指向25端口，即使账号密码正确，也可能出现连接超时、发送失败或邮件被拒的情况。真正适合最终用户提交邮件的端口是465和587，二者本身都支持加密，但实现方式并不相同。
接下来先把几个加密端口区分清楚：465对应隐式TLS，587对应STARTTLS，993用于IMAP加密，995用于POP3加密。很多邮件客户端把它们统称为SSL或TLS，但底层握手时机不同。配置错误时，日志通常表现为证书初始化失败、命令被拒绝或连接被立即重置。
一、端口速览：465、587、993、995分别代表什么
邮件协议中，SMTP负责发送，IMAP和POP3负责接收。传统明文端口分别是25、143和110。随着加密需求增加，每种协议都出现了对应的加密端口，但其实现方式并不完全一致。465端口最初为SMTPS预留，在IETF相关规范中一度被废弃，后来又因事实使用而恢复注册。它采用隐式TLS，也就是客户端连接后立即开始TLS握手，中间没有明文阶段。587端口则是邮件提交端口，专门用于客户端向邮件服务器提交邮件，默认要求身份认证，并支持STARTTLS扩展，先建立明文连接，再升级为加密。
993端口是为IMAP over SSL/TLS设计的隐式加密端口，995则用于POP3 over SSL/TLS。接收端选择错误同样会导致客户端无法收取邮件。简单来说，如果客户端加密类型选择SSL或TLS，通常对应465、993、995这类隐式加密端口；如果选择STARTTLS，则对应587、143、110这类先明文后升级的端口。部分客户端提供自动模式，会先尝试安全连接，但这并不代表可以随意填写端口。
| 协议 | 明文端口 | 隐式加密端口 | STARTTLS端口 |
|---|---|---|---|
| SMTP发送 | 25 | 465 | 587 |
| IMAP接收 | 143 | 993 | 143 |
| POP3接收 | 110 | 995 | 110 |
二、SMTP加密的两种模式：隐式TLS与STARTTLS
隐式TLS和STARTTLS的核心区别在于TLS握手发生的时间点。隐式TLS在TCP三次握手完成后立刻协商TLS，双方先建立加密会话，再发送SMTP命令。STARTTLS则先进行SMTP问候和EHLO命令，客户端在收到服务器返回的250-STARTTLS能力后，发出STARTTLS命令，双方从当前连接升级到TLS。可以用下面这段SMTP对话观察STARTTLS的升级过程。
220 mail.ipipp.com ESMTP Postfix EHLO client.ipipp.com 250-mail.ipipp.com 250-PIPELINING 250-SIZE 10240000 250-VRFY 250-ETRN 250-STARTTLS 250-ENHANCEDSTATUSCODES 250-8BITMIME 250-DSN 250-SMTPUTF8 250 CHUNKING STARTTLS 220 2.0.0 Ready to start TLS
可以看到，服务器在EHLO响应中公布STARTTLS能力，客户端主动发起升级。若服务器不支持STARTTLS，或者中间网络设备篡改了响应，升级会失败。相比之下，465端口不会出现这种明文阶段，因此被部分监管严格的网络环境视为更直接的安全通道。但从标准演进看，587加STARTTLS才是邮件提交的推荐组合，465更多是作为传统兼容方案保留。
实际配置时需要记住一个原则：同一端口不能同时作为隐式TLS和STARTTLS端口使用。如果防火墙把465转发到只支持STARTTLS的587服务，或者反过来，客户端会表现为TLS握手失败。判断服务器当前模式可以用openssl命令分别探测465和587。
# 检测465端口隐式TLS openssl s_client -connect mail.ipipp.com:465 -crlf # 检测587端口STARTTLS openssl s_client -connect mail.ipipp.com:587 -starttls smtp -crlf
如果465命令能直接显示证书信息，说明服务端确实在监听隐式TLS；如果587命令先显示MAIL、EHLO再由STARTTLS切换到证书，说明STARTTLS配置正确。
三、Postfix配置示例：同时开放587与465
Postfix是Linux邮件服务器常见选择。要让客户端既能通过587提交，又能兼容465旧客户端，需要在main.cf中开启TLS，并在master.cf中启用submission和smtps两个服务。main.cf的关键参数包括证书路径、协议版本、加密套件和认证策略。
# /etc/postfix/main.cf smtpd_tls_security_level = may smtpd_tls_auth_only = yes smtpd_tls_cert_file = /etc/letsencrypt/live/mail.ipipp.com/fullchain.pem smtpd_tls_key_file = /etc/letsencrypt/live/mail.ipipp.com/privkey.pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600s smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_ciphers = medium smtpd_tls_mandatory_ciphers = medium smtpd_tls_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, SRP
这里把smtpd_tls_security_level设为may，表示服务器接受明文连接，也允许STARTTLS升级，便于兼容旧环境。smtpd_tls_auth_only设为yes则强制只有TLS建立后才允许SMTP认证，避免账号密码在明文阶段传输。证书路径使用Let's Encrypt签发的完整证书链，避免客户端出现证书链不完整告警。协议版本排除了SSLv3和TLS1.0、TLS1.1，只保留TLS1.2以上，能提高整体安全性。
接下来需要在master.cf中定义submission和smtps两个入口。submission对应587，smtps对应465，二者监听端口不同，TLS行为也不同。
# /etc/postfix/master.cf submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_tls_auth_only=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - n - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
submission入口将smtpd_tls_security_level设为encrypt，表示该端口不接受明文提交，客户端必须先STARTTLS才能继续。smtps入口则通过smtpd_tls_wrappermode=yes启用隐式TLS，这正是465端口与587最关键的配置差异。两个入口都开启了SASL认证，并通过relay_restrictions限制只有认证用户才能转发邮件，防止服务器变成开放中继。
修改配置后需要执行postfix reload或systemctl reload postfix使配置生效。观察日志时，如果看到lost connection after STARTTLS或SSL_accept error，通常说明证书、端口模式或协议版本出现问题，而不是认证本身。
四、客户端与网络侧配置：防火墙、证书和加密类型
服务端配置正确后，客户端仍可能因为端口被封、证书不匹配或加密类型选错而无法发信。防火墙需要放行对应端口：如果只开放25和110，客户端提交会被拦截。云服务器安全组、iptables或firewalld都要单独放行465、587、993、995。测试连通性可以使用nc或telnet，但要注意25端口在许多云厂商默认处于禁用状态，不应作为最终用户提交通道。
证书方面，客户端会校验证书与服务器主机名是否一致。使用自签名证书时，手机和桌面客户端通常会出现不受信任提示，部分客户端允许手动信任，但多设备环境维护成本高。更稳妥的做法是使用正规CA签发的证书，并确保客户端填写的服务器地址与证书SAN中的域名完全一致。IP地址访问时，即使证书有效，也可能因为缺少对应的SAN项而报错。
客户端设置中常见的加密类型包括无、SSL、TLS、STARTTLS和自动。不同软件对SSL与TLS的定义不完全相同，部分客户端把SSL默认识别为465端口，把TLS识别为587端口，也有的将TLS表示隐式加密。遇到无法判断的情况，可以通过服务器日志中的握手失败或协议错误反推客户端模式。一般建议优先选择587加STARTTLS，只有当客户端明确要求SSL或旧设备无法使用STARTTLS时，才切换到465。
五、常见问题与注意事项
问题一：端口25连接超时。这通常不是服务器本身故障，而是网络上游对25端口做了限制。解决方法是改用587或465提交，并确认服务器已开放这两个端口。问题二：465能连通但无法认证。先确认服务器是否配置了smtpd_tls_wrappermode=yes，以及SASL认证是否开启。可以使用openssl s_client -connect mail.ipipp.com:465 -crlf检查证书链，再通过EHLO后的AUTH PLAIN测试认证。
问题三：587连接后STARTTLS命令失败。常见原因是中间防火墙或代理只放行了TCP，没有放行TLS升级后的数据，或者服务器没有加载TLS证书。可以通过EHLO响应中是否包含250-STARTTLS判断能力。若响应中缺少STARTTLS，说明服务端没有正确启用TLS。问题四：客户端提示证书过期或域名不匹配。需要检查证书有效期、完整链和SAN名称，不要把证书签发给mail.ipipp.com却让用户填写ipipp.com。
问题五：内外网使用不同地址。很多企业内网使用主机名访问，外网使用域名访问，但证书只覆盖外网域名，导致内网客户端报错。可以考虑在内网也使用相同域名解析，或部署受内网信任的CA。问题六：旧客户端只支持TLS1.0。出于安全考虑，现代邮件服务器通常已经禁用TLS1.0和TLS1.1，这时应升级客户端，而不是降低服务器安全级别。
最后还需要注意，开启加密并不能解决账号被暴力破解的问题。建议结合SASL认证失败限速、防火墙限制来源IP、关闭不必要的明文端口，并定期检查日志中的认证失败记录。加密解决的是传输过程中的窃听和篡改，不等于账号安全和反垃圾邮件策略可以放松。
