Java17+SpringBoot3.1中JavaMailSender连接内部SMTP无法正常终止

我基于Java 17、Spring Boot 3.1和Maven 4.0开发了一个入门级邮件发送应用，支持带文本附件的邮件发送。核心使用spring-boot-starter-mail提供的Jakarta Mail（2.1.1）中的JavaMailSender类，已实现EmailSender组件。

• 使用Gmail SMTP服务器时，邮件发送完全正常；
• 切换至内部组织SMTP服务器（smtp.internal-organization-server）后，调用javaMailSender.send(msg)会挂起约2分钟，最终抛出超时错误：

  org.eclipse.angus.mail.smtp.SMTPSendFailedException: 421 4.4.2 internal-server-name Error: timeout exceeded

尝试调整各类SMTP配置参数（如连接超时、读取超时等）均无效，仅在同时添加以下四个依赖时，JUnit测试中调用send方法可正常执行，但应用主方法调用仍会挂起：

• spring-security-oauth2-client
• spring-boot-starter-webflux
• springdoc-openapi-starter-webmvc-ui
• spring-boot-starter-actuator

问题 #

1. 这些看似无关的依赖为何能让内部SMTP连接正常终止，且仅对JUnit测试有效？
2. 为何该问题在Gmail SMTP下不存在，是否与内部SMTP服务器配置有关？

问题1：无关依赖仅让JUnit测试中SMTP连接正常的原因 #

这类依赖的引入会间接改变Spring应用上下文的配置，尤其是线程池、异步处理或网络相关的自动配置，而JUnit测试环境与应用运行环境的上下文初始化逻辑存在本质差异：

1. WebFlux的线程池影响：spring-boot-starter-webflux会引入Reactor框架，默认配置全局HttpClient及相关网络IO线程池。在JUnit测试中，Spring可能复用该线程池处理Jakarta Mail的阻塞式网络请求，而WebFlux的线程池配置（如更合理的超时、调度策略）恰好适配了内部SMTP服务器的要求。
2. Actuator触发的配置联动：spring-boot-starter-actuator会触发健康检查、端点配置等额外逻辑，让JUnit测试的上下文初始化流程更复杂，间接初始化了RestTemplate、WebClient等网络相关Bean，这些Bean的全局网络参数（如连接超时、Socket超时）被Jakarta Mail底层Socket复用。
3. 测试环境的条件加载差异：JUnit测试中，Spring Boot的自动配置会根据依赖存在与否激活特定配置类（如安全、网络相关），这些类可能修改了JVM层面的网络属性（如Socket的SO_TIMEOUT）；但应用主运行时，这些配置类的触发条件不满足（如Actuator端点未启用、WebFlux未作为主Web框架），因此无法生效。
4. OAuth2 Client的SSL/Socket工厂复用：spring-security-oauth2-client会引入安全相关的自定义SSL、Socket工厂配置，Jakarta Mail的SMTP连接可能复用了这些工厂，其超时设置刚好适配内部SMTP服务器。

本质上是这些依赖在JUnit测试环境中无意间修正了Jakarta Mail底层网络请求的配置，但这种修正依赖测试环境的上下文逻辑，因此无法在应用主运行环境中复现。

问题2：Gmail SMTP正常但内部SMTP超时的原因 #

这个问题几乎可以确定和内部SMTP服务器的配置及网络环境差异有关，核心差异点如下：

1. SMTP协议交互流程差异：Gmail SMTP严格遵循标准SMTP交互逻辑，而内部服务器可能存在特殊配置（如额外握手步骤、延迟响应、特定EHLO/HELO参数要求）。Jakarta Mail的默认配置无法适配这种非标准交互节奏，导致在某个步骤（如发送邮件内容、等待服务器响应）超时。
2. 网络环境与防火墙限制：内部SMTP服务器可能部署在受限制的网络环境中，比如需要通过代理、存在严格流量控制；而Gmail SMTP是公网服务，你的应用网络环境可正常与之交互，但内部服务器的双向超时配置（如服务器端对客户端的响应超时更短、网络延迟不稳定）会触发超时。
3. SSL/TLS配置兼容性：Gmail SMTP强制使用标准SSL/TLS，而内部服务器可能使用STARTTLS、自定义SSL协议版本或证书校验规则。Jakarta Mail的默认SSL参数与内部服务器不兼容，导致握手延迟最终超时。
4. 身份验证机制差异：内部SMTP服务器可能需要NTLM、Kerberos等特定身份验证方式，而你当前配置沿用了Gmail适配的简单身份验证（如SMTP PLAIN），导致服务器迟迟不响应验证请求，最终超时。

建议开启Jakarta Mail调试日志（添加spring.mail.properties.mail.debug=true配置），对比与Gmail的SMTP交互日志，即可定位内部服务器的具体差异点。

内容的提问来源于stack exchange，提问作者Anonymous_Footballer_11