AkkomaGang/akkoma

Fork 118

[bug] [on stable] "Use SSL" shows "off", while elsewhere it gets defaulted to "on" #953

New issue

Closed

opened 2025-07-26 13:12:01 +00:00 by shadowjonathan · 3 comments

shadowjonathan commented

2025-07-26 13:12:01 +00:00

Contributor

Your setup

From source

Extra details

Debian 12

Version

No response

PostgreSQL version

No response

What were you trying to do?

Use a STARTTLS-only mail setup, which has SSL disabled

I leave the "use SSL" to "off" in the settings, which its default in the UI

What did you expect to happen?

For it to not use SSL

What actually happened?

It started complaining about "unsupported TLS message", and when looking through wireshark, it was sending a TLS client hello to a non-TLS submission socket (587), which made the server break the connection

This happens through this bit here:

ssl: true,

which does not reflect the UI

Logs

14:55:34.326 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message
 - {:unsupported_record_type, 50}

14:55:34.354 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message
 - {:unsupported_record_type, 50}

14:55:34.380 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message
 - {:unsupported_record_type, 50}

14:55:34.438 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message
 - {:unsupported_record_type, 50}

14:55:34.460 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message
 - {:unsupported_record_type, 50}

14:55:34.482 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message
 - {:unsupported_record_type, 50}
** (MatchError) no match of right hand side value: {:error, {:retries_exceeded, {:network_failure, ~c"[REDACTED]", {:error, {:tls_alert, {:unexpected_message, ~c"TLS client: In state hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message\n {unsupported_record_type,50}"}}}}}}
    (pleroma 3.15.2) lib/mix/tasks/pleroma/email.ex:24: Mix.Tasks.Pleroma.Email.run/1
    (mix 1.18.2) lib/mix/task.ex:495: anonymous fn/3 in Mix.Task.run_task/5
    (mix 1.18.2) lib/mix/cli.ex:107: Mix.CLI.run_task/2
    /var/lib/akkoma/.asdf/installs/elixir/1.18.2-otp-27/bin/mix:2: (file)

Severity

I cannot use it as easily as I'd like

Have you searched for this issue?

I have double-checked and have not found this issue mentioned anywhere.

### Your setup From source ### Extra details Debian 12 ### Version _No response_ ### PostgreSQL version _No response_ ### What were you trying to do? Use a STARTTLS-only mail setup, which has SSL disabled I leave the "use SSL" to "off" in the settings, which its default in the UI ### What did you expect to happen? For it to not use SSL ### What actually happened? It started complaining about "unsupported TLS message", and when looking through wireshark, it was sending a TLS client hello to a non-TLS submission socket (587), which made the server break the connection This happens through this bit here: https://akkoma.dev/AkkomaGang/akkoma/src/commit/5bceb1d9b9e8cc22b402b7e6c63f892e23b9dbc8/lib/pleroma/emails/mailer.ex#L104 which does not reflect the UI ### Logs ```shell 14:55:34.326 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message - {:unsupported_record_type, 50} 14:55:34.354 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message - {:unsupported_record_type, 50} 14:55:34.380 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message - {:unsupported_record_type, 50} 14:55:34.438 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message - {:unsupported_record_type, 50} 14:55:34.460 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message - {:unsupported_record_type, 50} 14:55:34.482 [notice] TLS :client: In state :hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message - {:unsupported_record_type, 50} ** (MatchError) no match of right hand side value: {:error, {:retries_exceeded, {:network_failure, ~c"[REDACTED]", {:error, {:tls_alert, {:unexpected_message, ~c"TLS client: In state hello at tls_record.erl:532 generated CLIENT ALERT: Fatal - Unexpected Message\n {unsupported_record_type,50}"}}}}}} (pleroma 3.15.2) lib/mix/tasks/pleroma/email.ex:24: Mix.Tasks.Pleroma.Email.run/1 (mix 1.18.2) lib/mix/task.ex:495: anonymous fn/3 in Mix.Task.run_task/5 (mix 1.18.2) lib/mix/cli.ex:107: Mix.CLI.run_task/2 /var/lib/akkoma/.asdf/installs/elixir/1.18.2-otp-27/bin/mix:2: (file) ``` ### Severity I cannot use it as easily as I'd like ### Have you searched for this issue? - [x] I have double-checked and have not found this issue mentioned anywhere.

shadowjonathan added the

bug

label

2025-07-26 13:12:01 +00:00

floatingghost commented

2025-07-26 22:32:26 +00:00

Owner

ah, ok, I know what's going on

this isn't strictly a bug but a UI /defaults issue

if there no value in the database, it'll show as false - but the config resolution will require an explicit false to override the default

try switching SSL on, saving, then off again -i have a hunch that it'll work

ah, ok, I know what's going on this isn't strictly a bug but a UI /defaults issue if there _no_ value in the database, it'll show as false - but the config resolution will require an explicit false to override the default try switching SSL on, saving, then off again -i have a hunch that it'll work

shadowjonathan commented

2025-07-27 08:22:45 +00:00

Author

Contributor

That indeed works, but the bug report is wrt the UI inconsistency

Oneric commented

2025-07-29 19:00:15 +00:00

Owner

Unless there’s a garbage icon next to the setting in admin-fe, the setting is not set at all (in the database). Whatever state the input field assumes is similar to the value in the config file (or its lack therein).
In a similar vein an empty text field with and without garbage icon can also behvave differently: without it may be nil and use some fallback value or skip some logic, with its an explicit empty string.

Afaik there’s no way to tell admin-fe to assume a specific value if a value exists in neither the config file nor db.

We cannot put ssl: true in the default config since this name may not exist for different mailer backends or have a different meaning. Thus the defaults are inserted at runtime.
Not defaulting to ssl: true will be detrimental for most mail setups.

I’ll put a note in the settings description which should give enough of a hint to try setting it explicitly when encountering problems.
If you want a more explicit display for unset values in admin-fe, patches to improve the former (or taking up work on its replacement) are welcome.

Unless there’s a garbage icon next to the setting in admin-fe, the setting is not set at all (in the database). Whatever state the input field assumes is _similar_ to the value in the config file *(or its lack therein)*. In a similar vein an empty text field with and without garbage icon can also behvave differently: without it may be `nil` and use some fallback value or skip some logic, with its an explicit empty string. Afaik there’s no way to tell admin-fe to assume a specific value if a value exists in neither the config file nor db. We cannot put `ssl: true` in the default config since this name may not exist for different mailer backends or have a different meaning. Thus the defaults are inserted at runtime. Not defaulting to `ssl: true` will be detrimental for most mail setups. I’ll put a note in the settings description which should give enough of a hint to try setting it explicitly when encountering problems. If you want a more explicit display for unset values in admin-fe, patches to improve the former *(or taking up work on [its replacement](https://akkoma.dev/AkkomaGang/akkoma/pulls/802))* are welcome.