You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Operating system (if you're unsure: cat /etc/os-release ): any
Database + version: any
Elasticsearch version: any
Browser + version: any
Actual behaviour
SMTP connection form does not allow to pick secure connection parameters.. There's SSL Verification flag, but it does not affect wether SSL or STARTTLS is used.
Hidden ssl and start_tls flags exist, but they don't work as expected.
Hidden start_tls flag is defaults to true, but it enables opportunistic enable_starttls_auto option. Which allows to attempt STARTTLS connection. But does not stop if such attempt fails.
When hidden SSL flag is not present, it is detected using the port number. SMTPs using custom ports won't get SSL auto-enabled.
Expected behaviour
SMTP connection form has SSL dropdown which allows to choose off/ssl/starttls.
With starttls selected, it fails if STARTTLS connection cannot be established.
ssl may be enabled for any port.
Steps to reproduce the behaviour
Add Email channel,
Try to connect to SMTP servers with various configurations.
Migrationg existing systems
A clear migration path is needed. Is it possible to have a migration for existing systems?
Hidden flags shall be migrated to the new dropdown. Although if somebody has both STARTTLS and SSL enabled, only one of them may be enabled in the future.
Most systems does not have either flag. Existing autodetection could be followed in migration to guess the settings. Another option would be to grandfather the old configuration with a deprecation notice.
The text was updated successfully, but these errors were encountered:
Used Zammad Version
6.3
Environment
cat /etc/os-release
): anyActual behaviour
SMTP connection form does not allow to pick secure connection parameters.. There's SSL Verification flag, but it does not affect wether SSL or STARTTLS is used.
Hidden
ssl
andstart_tls
flags exist, but they don't work as expected.Hidden
start_tls
flag is defaults to true, but it enables opportunisticenable_starttls_auto
option. Which allows to attempt STARTTLS connection. But does not stop if such attempt fails.When hidden SSL flag is not present, it is detected using the port number. SMTPs using custom ports won't get SSL auto-enabled.
Expected behaviour
SMTP connection form has SSL dropdown which allows to choose
off/ssl/starttls
.With
starttls
selected, it fails if STARTTLS connection cannot be established.ssl
may be enabled for any port.Steps to reproduce the behaviour
Migrationg existing systems
A clear migration path is needed. Is it possible to have a migration for existing systems?
Hidden flags shall be migrated to the new dropdown. Although if somebody has both STARTTLS and SSL enabled, only one of them may be enabled in the future.
Most systems does not have either flag. Existing autodetection could be followed in migration to guess the settings. Another option would be to grandfather the old configuration with a deprecation notice.
The text was updated successfully, but these errors were encountered: