I recently went through the emails:task and related code with the aim of testing each of the failure codepaths and touching up the error text. I also discovered that the effects of setting DISCOURSE_SMTP_ENABLE_START_TLS=false are (mostly) nil. Setting this didn’t actually disable STARTTLS and in fact, it can coexist just fine with tls at connect time (DISCOURSE_SMTP_FORCE_TLS=true). So I’ve: removed the code that prevents both from being set: https://github.com/discourse/discourse/pull/35634/commits/0793898fad60871f942c3baa752172268d1360ec fixed the code to actually disable STARTTLS when requested: https://github.com/discourse/discourse/pull/35634/commits/e4f8b1f9efdb6f7ef9f5087be14f599ad8746230 redone the code that looks for failures and updated the text: https://github.com/discourse/discourse/pull/35634/commits/00430529459ef0b189d7576678aeeed32f1a24ee Before I merge this though, I think an admin warning in the dashboard for when DISCOURSE_SMTP_ENABLE_STARTTLS=false is being set is suitable. I imagine there’s at least one self-hoster out there who has set this but doesn’t need it and is actually relying on STARTTLS.

That sounds like good work! One thing that I (think I’ve) noticed is that the rake task doesn’t actually use the same code as the actual sending does (like from the /admin/email test page). I’m pretty sure that I’ve had a case where it worked in the UX but not the rake task (or maybe it was the opposite?) While it’s fresh on your mind, it you could see that at least when it actually sends it does so using the same code that Discourse does, that would be great.

We’re also working on that, and on improving the logging when a queued email job fails. :+1:

Is there anything I need to do on the forum you host? [Screenshot_20251105_151945_Firefox]

[image] supermathie: Before I merge this though, I think an admin warning in the dashboard for when DISCOURSE_SMTP_ENABLE_STARTTLS=false is being set is suitable. @supermathie is this worth PMing every admin on every site that has this variable set? Our current problem checks system will do that, and I’m not sure it is warranted here, given that for the most part, this has a nil effect. ideally, I’d want to only show this on the dashboard without pinging admin users, not sure our current problem checks structure supports that use case.

I think it is - I find it extremely likely that given how confused many admins are around email setup, someone has this variable set when they actually depend on starttls. Nobody should have it set, probably. Is rather have a spurious warning than silently break someone’s email setup. The alternative is removing the check and neutering the variable so it does nothing at all.

It would be nice if the warning didn’t show up when the outgoing SMTP server is the localhost (ie matches the Discourse domain name) as TLS between the Docker container and the host isn’t needed as they are the same machine.

In this case you should remove the variable from the environment. Discourse will only use STARTTLS if it’s offered.

Ich hatte in der aktuellen Version den Fall - das die auskommentierte Zeile (default ist true) zusammen mit force_tls den eMail Versand unterbunden hat. Ich habe sie also einkommentiert und sie auf false gesetzt. EMail Versand funktioniert nun - aber ich habe diese Meldung im Backend… Es hängt ein wenig davon ab - auf welchem Port eurer Mailprovider läuft… beides geht nicht - und hat definitiv Auswirkungen.

I also noticed this. After updating Discourse on 28 November, I started seeing mail delivery failures with the error message Job exception: :enable_starttls and :tls are mutually exclusive. Set :tls if you're on an SMTPS connection. Set :enable_starttls if you're on an SMTP connection and using STARTTLS for secure TLS upgrade. Backtrace /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.9.0/lib/mail/network/delivery_methods/smtp.rb:159:in `build_smtp_session' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.9.0/lib/mail/network/delivery_methods/smtp.rb:154:in `start_smtp_session' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.9.0/lib/mail/network/delivery_methods/smtp.rb:108:in `deliver!' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/mail-2.9.0/lib/mail/message.rb:269:in `deliver!' /usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing' /var/www/discourse/lib/email/sender.rb:296:in `send' /var/www/discourse/app/jobs/regular/user_email.rb:80:in `send_user_email' /var/www/discourse/app/jobs/regular/user_email.rb:40:in `execute' /var/www/discourse/app/jobs/base.rb:318:in `block (2 levels) in perform' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-7.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in `with_connection' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rails_multisite-7.0.0/lib/rails_multisite/connection_management.rb:17:in `with_connection' /var/www/discourse/app/jobs/base.rb:305:in `block in perform' /var/www/discourse/app/jobs/base.rb:301:in `each' /var/www/discourse/app/jobs/base.rb:301:in `perform' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:220:in `execute_job' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:185:in `block (4 levels) in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:180:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse' /var/www/discourse/lib/sidekiq/suppress_user_email_errors.rb:6:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse' /var/www/discourse/lib/sidekiq/discourse_event.rb:6:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse' /var/www/discourse/lib/sidekiq/pausable.rb:131:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job/interrupt_handler.rb:9:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:183:in `block in traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:26:in `track' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/metrics/tracking.rb:134:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:182:in `traverse' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/middleware/chain.rb:173:in `invoke' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:184:in `block (3 levels) in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:145:in `block (6 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_retry.rb:118:in `local' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:144:in `block (5 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/config.rb:39:in `block in ' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:139:in `block (4 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:281:in `stats' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:134:in `block (3 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_logger.rb:15:in `call' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:133:in `block (2 levels) in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_retry.rb:85:in `global' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:132:in `block in dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/job_logger.rb:40:in `prepare' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:131:in `dispatch' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:183:in `block (2 levels) in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `handle_interrupt' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:182:in `block in process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `handle_interrupt' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:181:in `process' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:86:in `process_one' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/processor.rb:76:in `run' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:10:in `watchdog' /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/sidekiq-7.3.9/lib/sidekiq/component.rb:19:in `block in safe_thread' Just like Johann Christoph, I previously had DISCOURSE_SMTP_ENABLE_START_TLS commented out and DISCOURSE_SMTP_FORCE_TLS set to true for implicit TLS and it worked like a charm. But now I have to explicitly set DISCOURSE_SMTP_ENABLE_START_TLS to false for email delivery to work, which of course triggers the aforementioned message in the admin dashboard.

Reworking the emails:test rake task output

Development

pmusaraj (Penar Musaraj) November 5, 2025, 5:11pm 5

No, this alert shouldn’t show up on our hosting. We’ll fix it, thanks for the report as always.

Topic		Replies	Views
SSL/TLS for port 465 (Net::ReadTimeout) - undocumented solution Self-hosting email	2	841	November 11, 2025
SMTP error: Must issue a STARTTLS command first Self-hosting	9	3638	November 23, 2021
Email not working (SSL_connect returned=1) Self-hosting	15	2908	June 15, 2022
Can't send email with certificate issue Self-hosting	2	1676	April 2, 2019
Discourse with other websites, SMTP issue: End of file reached Self-hosting	7	2576	September 22, 2020

Reworking the emails:test rake task output

Related topics