Apple iCloud 邮箱发信 465 超时：仅支持 587 STARTTLS 的协议陷阱
刺破宁静的自动化告警
在运行于 Windows 管理宿主机的后台邮件健康巡检任务中，监控频道突然弹出了告警通知：
Cronjob Response: himalaya account health (job_id: 2f09440986e4)
-------------
📧 himalaya 账号健康检查 — 存在异常
❌ icloud (smtp)
smtp: FAIL (connect smtp.mail.me.com:465: A connection attempt failed
because the connected party did not properly respond after a period of time,
or established connection failed because connected host has failed to respond. (os error 10060 / WSAETIMEDOUT))经过测试，使用跨平台 CLI 客户端通过 IMAP 协议（imap.mail.me.com:993）拉取收件箱邮件毫秒级响应，App-Specific Password（应用专用密码）也已反复确认有效。但只要尝试通过 SMTP 发送测试信件，底层套接字就会死等 30 秒，最终抛出 Windows Winsock 体系特有的超时异常（os error 10060 / WSAETIMEDOUT，对应 Linux 系统的 ETIMEDOUT 110）。
隐式 TLS 与 STARTTLS 的协议分水岭
排查的突破点在于发信端口规范的细微差别。在客户端配置（~/.config/himalaya/config.toml）中，此前参考了 Gmail 与通用自建企业邮的习惯进行填写：
# 初始有问题的配置
[accounts.icloud]
email = "[email protected]"
backend = "imap"
imap.server = "imap.mail.me.com"
imap.port = 993
imap.encryption = "tls"
message.send.backend = "smtp"
smtp.server = "smtps://smtp.mail.me.com:465"465 端口历史上被用于 SMTPS（隐式 TLS 直连，即 TCP 建立后直接开始 TLS 握手）。虽然许多主流邮件服务商为了向下兼容同时开放 465 与 587 端口，但 Apple 的发信基础设施（smtp.mail.me.com）严格执行传统 RFC 6409 / RFC 3207 邮件提交规范，而未开放 RFC 8314 所推荐的 465 隐式 TLS 端口：
- 465 端口在 Apple 边缘防火墙上被直接静默丢包。发往 465 端口的 SYN 报文收不到任何回应，因而客户端表现为漫长的
WSAETIMEDOUT，而不是快速返回拒绝（ECONNREFUSED）。 - Apple 的邮件网关仅在 587 端口提供发信提交服务，并且要求客户端以明文建立 TCP 连接后，立即发起
STARTTLS扩展指令升级为加密通道。
使用 smtps:// 直连 465 端口，无异于在一个根本没有服务监听的端口上等待 TLS Client Hello 应答。
修复：切换为 587 端口并启用 STARTTLS
在配置文件中调整协议 Scheme 与端口定义：
🔍 config.toml — 规范后的 iCloud 账户配置（11 行）
[accounts.icloud]
email = "[email protected]"
backend = "imap"
imap.server = "imap.mail.me.com"
imap.port = 993
imap.encryption = "tls"
message.send.backend = "smtp"
smtp.server = "smtp://smtp.mail.me.com:587"
smtp.starttls = true重点是将连接前缀从 smtps:// 改回标准的 smtp://，同时声明 smtp.starttls = true。
结果
配置保存后，使用 CLI 单独测试 iCloud 账户连通性：
$ himalaya account check --account icloud
Account: icloud
imap: OK
smtp: OK随后重新触发全量巡检脚本，全站配置的 6 个邮箱账号全部以绿色 OK 顺利通过，脚本正常以退出码 0 结束，巡检监控重新回归无异常推送的静默健康状态。
有高价值项目开发需求，或正在寻找硬核全栈工程师？
从前端交互到边缘网关，从业务系统到自托管基础设施。欢迎与我探讨商业系统外包或全职/远程工程岗位。
