Bug: MAILER_ENABLE_STARTTLS=false does not actually disable STARTTLS

[castellinosviluppo]

Bug: MAILER_ENABLE_STARTTLS=false does not actually disable STARTTLS

Problem

When MAILER_ENABLE_STARTTLS is set to false, STARTTLS is not actually disabled. The underlying gen_smtp library will attempt STARTTLS anyway if the SMTP server advertises it in the EHLO response.

This happens because in config/runtime.exs, the else branch of the starttls? check simply returns the config unchanged, without explicitly setting :tls to :never:

|> then(fn config ->
  if starttls? do
    config
    |> Keyword.put(:tls, :always)
    ...
  else
    config  # tls option is not set, gen_smtp defaults to attempting STARTTLS if offered
  end
end)

When gen_smtp does not find a :tls option in the config, it falls back to its default behavior, which is to attempt STARTTLS if the server offers it. This causes connection failures when TLS negotiation fails, even though the user explicitly set MAILER_ENABLE_STARTTLS=false.

Fix

Explicitly set :tls to :never in the else branch:

|> then(fn config ->
  if starttls? do
    config
    |> Keyword.put(:tls, :always)
    |> Keyword.put(
      :tls_options,
      :tls_certificate_check.options(host) ++ [versions: [:"tlsv1.2"]]
    )
  else
    config
    |> Keyword.put(:tls, :never)
  end
end)

How to reproduce

1. Set MAILER_ENABLE_STARTTLS=false and MAILER_ENABLE_SSL=false in your environment
2. Use an SMTP server (e.g. Postfix) that advertises STARTTLS in its EHLO response
3. Observe that Keila attempts STARTTLS anyway, resulting in a connection error

Notes

This issue is particularly relevant for self-hosted setups where Keila connects to a local SMTP server for system emails (e.g. Postfix with inet_interfaces = localhost) and TLS is not needed or desired for local connections.

---

If you think my change is okay, I can start a PR.
But I have a question regarding the CLA.
My GitHub account belongs to an organization account, my company.
In the CLA signature, can I use my username as legal name, or would you prefer the businessname of the company I work for?

[wmnnd]

Hey there, thank you for reporting this. Would you say this is a common configuration for a mail server where it's advertising TLS but doesn't actually have a valid certificate?

[castellinosviluppo]

Hi. First of all, many thanks for Keila project, which is truly remarkable, especially for its project-wide multi-tenant architecture.
Great job!

On dedicated servers Linux , it's a common practice to install Postfix as SMTP to send system emails, such as backup results, notifications from services like fail2ban, or raid checks.
On Linux distros like RedHat, Almalinux, or Rocky, the default Postfix installation is a null-client configuration, meaning it only listens on the localhost interface.
The SMTP server is not public and cannot be reached externally.
Postfix's configuration includes self-signed certificates, but as I said, no client can contact it, so they aren't used.
For outgoing emails, they are encrypted if the receiving SMTP supports TLS, since Postfix's default value for smtp_tls_security_level is "may".
In this scenario, configuring certificates, such as with LetsEncrypt, is not necessary.

Since I've turned off subscriptions, I don't think I'll be getting much system email from Keila, so I figured I could use my local Postfix server with the following options:
MAILER_SMTP_HOST=localhost
MAILER_SMTP_PORT=25
MAILER_SMTP_USER=none
MAILER_SMTP_PASSWORD=none
MAILER_SMTP_FROM_NAME=Name
MAILER_SMTP_FROM_EMAIL=noreply@domain.it

However, with this configuration, I run into the problem I mentioned.

Of course, I could try a connection with:

MAILER_SMTP_HOST=localhost
MAILER_SMTP_PORT=587
MAILER_ENABLE_SSL=false
MAILER_ENABLE_STARTTLS=true

Or I could use an AWS SES as SMTP server.

But I thought that in the case of MAILER_ENABLE_STARTTLS=false it was more consistent to set Keyword.put(:tls, :never), exactly as in the case of MAILER_ENABLE_STARTTLS=true Keyword.put(:tls, :always) is set.

One more time thank u for your job