Is there an existing issue for this?
Description
In Volo.Abp.MailKit, AbpMailKitOptions defines a nullable property:
public SecureSocketOptions? SecureSocketOption { get; set; }
By design, this property should be null by default. However, when debugging multi-mailbox or dynamic configuration scenarios, SecureSocketOption unexpectedly has a value (even without any explicit global configuration or appsettings setup), which causes GetSecureSocketOption() to bypass the dynamic SmtpConfiguration.GetEnableSslAsync() logic and leads to authentication/connection failures (e.g., when trying to use port 465 with SslOnConnect).
Reproduction Steps
- Set up a system where different email accounts/tenants use different SMTP servers (e.g., some require SslOnConnect for port 465, while others use StartTlsWhenAvailable).
- Trigger an email send and trace
GetSecureSocketOption().
- Observe that even when no explicit global option is set, the method evaluates or hits the global check prematurely, ignoring the dynamic database/tenant configuration (
SmtpConfiguration.GetEnableSslAsync()).
Expected behavior
The global AbpMailKitOptions.SecureSocketOption should only act as a fallback when dynamic settings are absent, or the dynamic SmtpConfiguration should take precedence to properly support per-tenant and per-mailbox configurations.
Actual behavior
No response
Regression?
No response
Known Workarounds
- Explicitly reset or configure
AbpMailKitOptions.SecureSocketOption in the module initialization if possible.
- Override the
GetSecureSocketOption() method in a custom email sender (inheriting from MailKitSmtpEmailSender) to bypass the global options and explicitly rely on dynamic configurations like SmtpConfiguration.GetEnableSslAsync().
Version
10.6.0
User Interface
Common (Default)
Database Provider
EF Core (Default)
Tiered or separate authentication server
None (Default)
Operation System
Windows (Default)
Other information
No response
Is there an existing issue for this?
Description
In
Volo.Abp.MailKit,AbpMailKitOptionsdefines a nullable property:public SecureSocketOptions? SecureSocketOption { get; set; }By design, this property should be null by default. However, when debugging multi-mailbox or dynamic configuration scenarios,
SecureSocketOptionunexpectedly has a value (even without any explicit global configuration or appsettings setup), which causesGetSecureSocketOption()to bypass the dynamicSmtpConfiguration.GetEnableSslAsync()logic and leads to authentication/connection failures (e.g., when trying to use port 465 with SslOnConnect).Reproduction Steps
GetSecureSocketOption().SmtpConfiguration.GetEnableSslAsync()).Expected behavior
The global
AbpMailKitOptions.SecureSocketOptionshould only act as a fallback when dynamic settings are absent, or the dynamicSmtpConfigurationshould take precedence to properly support per-tenant and per-mailbox configurations.Actual behavior
No response
Regression?
No response
Known Workarounds
AbpMailKitOptions.SecureSocketOptionin the module initialization if possible.GetSecureSocketOption()method in a custom email sender (inheriting fromMailKitSmtpEmailSender) to bypass the global options and explicitly rely on dynamic configurations likeSmtpConfiguration.GetEnableSslAsync().Version
10.6.0
User Interface
Common (Default)
Database Provider
EF Core (Default)
Tiered or separate authentication server
None (Default)
Operation System
Windows (Default)
Other information
No response