managua1902

Unable to send an email via my SMTP server via SSL/TLS. But my local email client works well

I have my own SMTP server. It’s behind SSL/TLS - port 465

In my phoenix I use Swoosh to send emails. Since recently I’ve been facing this error:

delivery error:
{:retries_exceeded, {:network_failure, ~c"mail.my_mail_server.com", {:error, {:options, :incompatible, [verify: :verify_peer, cacerts: :undefined]}}}}

My config:

adapter: Swoosh.Adapters.SMTP,
    relay: host,
    username: user,
    password: password,
    port: port,

    ssl: true,
    tls: :always,

    # allowed_tls_versions: [:tlsv1, :"tlsv1.1", :"tlsv1.2", :"tlsv1.3"],
    auth: :always,
    retries: 5,
    no_mx_lookups: true,


    ssl: [
    # ssl_opts: [
    # ssl_options: [

        verify: :verify_none,
      # verify: :verify_peer,

      # cacerts: :public_key.cacerts_get(),
      # versions: [:"tlsv1.2"],
      # versions: [:"tlsv1.3"],
      #   customize_hostname_check: [
      #     match_fun: :public_key.pkix_verify_hostname_match_fun(:https)
      #   ]
    ],

    tls_options: [
        # verify: :verify_peer,
        verify: :verify_none,

        # cacerts: :certifi.cacerts(),
        # cacerts: :public_key.cacerts_get(),
        #   server_name_indication: ~c"#{host}",
    ]

An interesting thing is that all the options that have to do with tls and ssl will be ignored.

Meaning, the error will always contain

<...> { verify: :verify_peer, cacerts: :undefined}...

There’s never been an error with verify: :verify_none and cacerts: <something_else>, even though I’ve set it up.

Why? I’ve set different values in the config. Why will they remain verify: :verify_peer, cacerts: :undefined ?

And it’s unclear wether I should used ssl_opts, ssl or ssl_options – I’ve tried dozens of combinations. The same goes for the tls_options.

What’s the matter?

The emails I’ll send from an email-client from my local computer via the same email server get sent with no issue, and under the same settings: port 465, SSL/TLS, same relay.

P.S.

OTP 26.

I’m aware of this - Erlang/OTP 26 Highlights - Erlang/OTP

But, as I’ve mentioned, it’ll ignore my verify: <...> variables in the first place.

30 comments

/phoenix #ssl #email #tls

30 4776 30

2025-02-24 22:09:54 UTC

Most Liked

_jonas

I was also struggling with this issue for a good while until I used almost the exact configuration mentioned here by @LostKobrakai SSL connection options · Issue #298 · gen-smtp/gen_smtp · GitHub

Here is my config which now (finally) works (using this smtp server)

  config :backend, Backend.Mailer,
    adapter: Swoosh.Adapters.SMTP,
    relay: System.get_env("EMAIL_SMTP_HOST"),
    username: System.get_env("EMAIL_SMTP_USER"),
    password: System.get_env("EMAIL_SMTP_PASSWORD"),
    port: String.to_integer(System.get_env("EMAIL_SMTP_PORT") || "465"),
    ssl: true,
    tls: :never,
    auth: :always,
    retries: 2,
    no_mx_lookups: false,
    sockopts: [
      versions: [:"tlsv1.2", :"tlsv1.3"],
      verify: :verify_peer,
      cacerts: :public_key.cacerts_get(),
      depth: 3,
      customize_hostname_check: [
        match_fun: :public_key.pkix_verify_hostname_match_fun(:https)
      ],
      server_name_indication: 'mail.privateemail.com'
    ]

It was pretty tough to figure this out as someone very new to Elixir, especially since I couldn’t find this sockopts key documented anywhere in Swoosh or the gen_smtp Readme and I still don’t really understand why this is necessary, but maybe it helps someone.
What was also really tripping me up for a bit was the fact that server_name_indication apparently needs to be a charlist (single quoted) and I was trying to set it as a string with System.get_env("EMAIL_SMTP_HOST").

Perhaps someone who understands this better than me could add a note about it to the Swoosh SMTP adapter docs, since without these settings it doesn’t seem to be possible to get it to work?

Post #9

LostKobrakai

I might be able to give some insight around the why here: Erlangs SSL handling is a lot more explicit (and hence complicated) than in many other places. Given nowadays emails usually use SSL over starttls you’re running into that explicitness. That’s most of the reason for the sockopts. More info can be found here: Erlang standard library: ssl | EEF Security WG

server_name_indication is additional required because by default (no_mx_lookup: false) gen_smtp doesn’t connect to the smtp server using the provided hostname, but rather it looks up the IP address for the hostname using the MX dns entry and uses that IP to connect to the server. Usually SSL certificates are supplied for a given hostname though, not an IP address. Therefore one needs to supply the hostname as SNI value, so the certificate can be validated against that hostname instead.

Disabling MX lookup does remove the need for the SNI value.

Post #10

LostKobrakai

The :tls setting is for STARTTLS. If you’re not using starttls you should disable it. You can find a bit more context about that here: SSL connection options · Issue #298 · gen-smtp/gen_smtp · GitHub

Post #6

al2o3cr

What version of OTP are you on? Have you upgraded recently?

Asking because there’s a fix that just landed for TLSv1.3 in OTP 25 + 26:

github.com/erlang/otp

Issue with SSL (tlsv1.3) communication in OTP 25 and OTP 26 compared to OTP 24

opened 08:28AM - 08 Apr 24 UTC

closed 07:12AM - 19 Apr 24 UTC

isavita

team:PS in progress bug

**Describe the bug** I encountered an issue when using the `:ssl` with `tlsv1.3…` module for SSL communication in Erlang/OTP 25 and OTP 26 compared to OTP 24. **To Reproduce** I used the following Erlang code to fetch data using SSL: ```erlang -module(ssl_debug). -export([run/0]). run() -> SslOpts = [ {verify, verify_peer}, {cacertfile, "/path/to/ca.crt"}, {certfile, "/path/to/client.crt"}, {keyfile, "/path/to/client.key"}, {keep_secrets, true}, {versions, ['tlsv1.3']}, {log_level, debug}, {log_alert, true} ], Host = "mywebserver.com", Port = 443, io:format("Attempting SSL connection to ~s:~p~n", [Host, Port]), ssl:start(), case ssl:connect(Host, Port, SslOpts, 5000) of {ok, Socket} -> io:format("SSL connection established~n"), Path = "/myendpoint", Request = "GET " ++ Path ++ " HTTP/1.1\r\nHost: " ++ Host ++ "\r\n\r\n", case ssl:send(Socket, Request) of ok -> io:format("Request sent~n"); {error, SendReason} -> io:format("Error sending request: ~p~n", [SendReason]) end, io:format("Attempting SSL connection to ~s:~p~n", [Host, Port]), case receive_response(Socket, [], 3000) of {ok, Data} -> io:format("Response:~n~s~n", [Data]); {error, ReceiveReason} -> io:format("Error receiving response: ~p~n", [ReceiveReason]) end, ok = ssl:close(Socket); {error, ConnectReason} -> io:format("SSL connection failed1: ~p~n", [ConnectReason]); Everything -> io:format("SSL connection failed2: ~p~n", [Everything]) end. receive_response(Socket, Acc, Timeout) -> receive {ssl, Socket, Data} -> io:format("Received data: ~p~n", [Data]), receive_response(Socket, [Acc, Data], Timeout); {ssl_closed, Socket} -> io:format("Socket closed~n"), {ok, iolist_to_binary(Acc)}; {ssl_error, Socket, Reason} -> io:format("SSL error: ~p~n", [Reason]), {error, Reason}; Everything -> io:format("SSL error: ~p~n", [Everything]), {error, "Error"} after Timeout -> io:format("Receive timeout after ~p milliseconds~n", [Timeout]), {ok, iolist_to_binary(Acc)} end. ``` The code worked perfectly on OTP 24, but it failed on both OTP 25 and OTP 26. **Expected behavior** I would expect to be able to connect to myserver on both OTP 25 and OTP 26. **Affected versions** **Erlang/OTP 26 [erts-14.2.2]** and **Erlang/OTP 25** **Additional context** If I use `:ssl` with `tlsv1.2` everything works on **Erlang/OTP 25** and **Erlang/OTP 25** The problem seems to be with the `ssl_app` version. It changed from `{ssl_app,"10.7.3.5"` in **OTP 24** to `{ssl_app,"11.1.1"}` in OTP 26. I also create this issue in elixir MINT library [here](https://github.com/elixir-mint/mint/issues/427). Could you please investigate this issue and provide guidance on how to resolve it? Is there any workaround or fix available to ensure compatibility with the latest OTP releases?

Post #15

silverdr

FWIW - 26.2.5 images with Elixir 1.16.2 are available now for over a week. My problem was indeed caused by that OTP 25/26 bug but… for “posterity” it was not enough to just replace OTP with 26.2.5!

Once I did built the “runner” image with 26.2.5 it started throwing another error, namely a

- {:bad_cert, :max_path_length_reached}

one, which of course was never a problem before Luckily this one was much easier to find a solution to. Going to Erlang -- ssl and doing search for “path” revealed

https://www.erlang.org/doc/man/ssl#type-allowed_cert_chain_length

which talks about “depth” so searching for “depth” lead me to an option in common_option, which given a nice, round number of 64 cured the setup. Thus my current (working) prod config – if somebody ever needs hints is:

	config :my_app, MyApp.Mailer,
		adapter: Swoosh.Adapters.SMTP,
		relay: System.get_env("SMTP_RELAY", "mail.myapp.com"),
		hostname: System.get_env("SMTP_HOSTNAME", "mail.mysmtpserver.com"),
		username: System.get_env("SMTP_USERNAME", "no-reply@myapp.com"),
		password: System.get_env("SMTP_PASSWORD"),
		auth: :always,
		ssl: false,
		tls: :always,
		tls_options: [
			versions: [:"tlsv1.3"],
			cacerts: :public_key.cacerts_get(),
			server_name_indication: 'mail.mysmtpserver.com', # what your certificate is issued for
			depth: 64, # important or stuff may crash with - {:bad_cert, :max_path_length_reached}
		],
		port: 587,
		retries: 2

hostnames and application name are “dummies” of course.

to @al2o3cr the umpteenth time