Überarbeitung der E-Mails: Test-Rake-Task-Ausgabe

Entwickler
1

Ich habe kürzlich die E-Mails: Aufgabe und den zugehörigen Code durchgesehen, um jeden der Fehlerpfade zu testen und den Fehlertext zu überarbeiten.

Ich habe auch festgestellt, dass die Auswirkungen des Setzens von DISCOURSE_SMTP_ENABLE_STARTTLS=false (größtenteils) null sind. Das Setzen hat STARTTLS nicht tatsächlich deaktiviert und tatsächlich kann es problemlos mit TLS zur Verbindungszeit koexistieren (DISCOURSE_SMTP_FORCE_TLS=true).

Daher habe ich:

Bevor ich dies jedoch zusammenführe, halte ich eine Admin-Warnung im Dashboard für geeignet, wenn DISCOURSE_SMTP_ENABLE_STARTTLS=false gesetzt wird. Ich stelle mir vor, dass es mindestens einen Self-Host-Betreiber gibt, der dies gesetzt hat, es aber nicht benötigt und tatsächlich auf STARTTLS angewiesen ist.

4 „Gefällt mir“
SSL/TLS for port 465 (Net::ReadTimeout) - undocumented solution
2

Das klingt nach guter Arbeit! Eine Sache, die mir (glaube ich) aufgefallen ist, ist, dass die Rake-Aufgabe nicht denselben Code wie der eigentliche Versand verwendet (wie von der Testseite /admin/email). Ich bin mir ziemlich sicher, dass ich einen Fall hatte, in dem es im UX funktionierte, aber nicht in der Rake-Aufgabe (oder war es vielleicht umgekehrt?)

Solange es Ihnen noch frisch im Gedächtnis ist, wäre es großartig, wenn Sie sicherstellen könnten, dass es beim tatsächlichen Versand denselben Code verwendet, den Discourse verwendet.

2 „Gefällt mir“
3

Wir arbeiten auch daran und daran, das Logging zu verbessern, wenn ein E-Mail-Job in der Warteschlange fehlschlägt. :+1:

4 „Gefällt mir“
4

Muss ich auf dem von Ihnen gehosteten Forum etwas tun?

Screenshot_20251105_151945_Firefox
Screenshot_20251105_151945_Firefox1847×588 152 KB

4 „Gefällt mir“
5

Nein, diese Benachrichtigung sollte nicht auf unserem Hosting angezeigt werden. Wir werden das beheben, danke wie immer für den Bericht.

5 „Gefällt mir“
6

@supermathie, ist es das wert, jeden Admin auf jeder Website, auf der diese Variable gesetzt ist, per PM zu kontaktieren? Unser aktuelles System zur Überprüfung von Problemen wird das tun, und ich bin mir nicht sicher, ob es hier gerechtfertigt ist, da dies größtenteils eine nil-Wirkung hat. Idealerweise möchte ich dies nur im Dashboard anzeigen, ohne Admin-Benutzer zu benachrichtigen. Ich bin mir nicht sicher, ob unsere aktuelle Struktur zur Überprüfung von Problemen diesen Anwendungsfall unterstützt.

7

Ich denke schon – ich halte es für extrem wahrscheinlich, dass angesichts der Verwirrung vieler Administratoren bei der E-Mail-Einrichtung jemand diese Variable gesetzt hat, obwohl er tatsächlich von starttls abhängig ist.

Wahrscheinlich sollte niemand sie gesetzt haben.

Ich hätte lieber eine irreführende Warnung als eine stillschweigend unterbrochene E-Mail-Einrichtung.

Die Alternative ist, die Prüfung zu entfernen und die Variable so zu neutralisieren, dass sie überhaupt nichts tut.

1 „Gefällt mir“
8

Es wäre schön, wenn die Warnung nicht angezeigt würde, wenn der ausgehende SMTP-Server localhost ist (d. h. mit dem Discourse-Domänennamen übereinstimmt), da TLS zwischen dem Docker-Container und dem Host nicht benötigt wird, da es sich um dieselbe Maschine handelt.

1 „Gefällt mir“
9

In diesem Fall können Sie die Variable aus der Umgebung entfernen.

Es wird nur STARTTLS verwendet, wenn es angeboten wird.

1 „Gefällt mir“
10

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.

11

Ich habe das auch bemerkt. Nach dem Update von Discourse am 28. November begannen bei mir Zustellfehler für E-Mails mit der Fehlermeldung 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 <class:Config>'
/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'

Genau wie Johann Christoph hatte ich zuvor DISCOURSE_SMTP_ENABLE_START_TLS auskommentiert und DISCOURSE_SMTP_FORCE_TLS auf true für implizites TLS gesetzt, was einwandfrei funktionierte. Aber jetzt muss ich DISCOURSE_SMTP_ENABLE_START_TLS explizit auf false setzen, damit der E-Mail-Versand funktioniert, was natürlich die oben genannte Meldung im Admin-Dashboard auslöst.

1 „Gefällt mir“
12

Es ist force_tls, das das Senden von E-Mails verhindert – dies erzwingt TLS beim Verbindungsaufbau und ist wahrscheinlich nur für Port 465 geeignet.

Ein Einhorn!

Welche SMTP-Parameter verwenden Sie (abzüglich Benutzername/Passwort)?

13

Port 465 mit ENABLE_START_TLS=false, FORCE_TLS=true und OPEN_TIMEOUT=10. Letzteres ist auf seltsame Timeout-Fehler zurückzuführen, die ich vor etwa drei Jahren nach einem Systemupdate beobachtet habe, aber ich esse meinen Hut, wenn das mit dem oben beschriebenen Problem zusammenhängt.

In der Zwischenzeit habe ich mir den Commit-Verlauf angesehen und festgestellt, dass das Mail-Gem auf Version 2.9.0 aktualisiert wurde, nur drei Tage vor dem Update, das das Problem auf meiner Seite eingeführt hat (#36254). In den Versionshinweisen dazu gibt es einen Eintrag, der besagt: „SMTP: refactor and accept starttls :always and :auto by @eval in #1536“. Ich weiß nicht viel über Ruby, aber diese Änderung in der referenzierten PR sieht für mich irgendwie verdächtig aus:

image
image1168×279 32.5 KB

In Anbetracht dessen, dass DISCOURSE_SMTP_ENABLE_START_TLS standardmäßig auf true gesetzt ist (d. h. wenn auskommentiert), ist es möglich, dass dies die Ursache des Problems ist?

14

Wie ich schrieb - habe ich force_TLS gesetzt:

`DISCOURSE_SMTP_FORCE_TLS = true`

und ENABLE_START_TLS explizit auf false… dann funktioniert der Mailversand - sofern der Mailserver auf 465 läuft.

Bei Mailservern die auf 567 laufen - muss es genau anders herum sein.

Seither habe ich zwar einen Hinweis auf dem Dashboard im Backend… aber der Mailversand arbeitet ohne Probleme.

15

Um DISCOURSE_SMTP_ENABLE_START_TLS auf false setzen zu können, muss man es auskommentieren - da es ansonsten per default auf true steht. Genau das, hatte bei mir das Problem verursacht. Allerdings auch erst, mit dem neuesten Build ( 2025.12.0-latest ).

16

Wow, das war eine schlechte Änderung.

enable_starttls wird die Verwendung von starttls ERFORDERN, aber enable_starttls_auto ist opportunistisch – es wird TLS nur aushandeln, wenn es angeboten wird.

Und wenn der Mailserver über initiales TLS verbunden wurde, wird er kein starttls anbieten:

○ → openssl s_client -connect localhost:5587 -starttls smtp
250 CHUNKING
EHLO localhost
250-testmailrelay
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 CHUNKING

Warum um alles in der Welt haben sie das getan? :facepalm:
Die Schwierigkeit hierbei ist, dass wir diese Konfiguration von vornherein hätten nicht anbieten dürfen, es hätte etwas sein sollen wie:

DISCOURSE_SMTP_TLS_MODE = starttls_auto # [ none | starttls | starttls_auto (default) | tls ]
17

Im Interesse daran, dass die Leute weniger Konfiguration vornehmen, nicht mehr, halte ich diesen Ansatz für den besten:

1 „Gefällt mir“
18

Dies ist nun zusammengeführt, man muss STARTTLS nicht mehr explizit deaktivieren, Discourse kümmert sich automatisch darum, wenn TLS aktiviert ist.

19

Ja, funktioniert wieder einwandfrei. Danke!