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).
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.
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.
@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.
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.
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.
