Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow to configure secure connection for SMTP #5136

Open
mantas opened this issue Apr 19, 2024 · 0 comments
Open

Allow to configure secure connection for SMTP #5136

mantas opened this issue Apr 19, 2024 · 0 comments

Comments

@mantas
Copy link
Collaborator

mantas commented Apr 19, 2024

Used Zammad Version

6.3

Environment

  • Installation method: any
  • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant