Erweiterung des SMTP-Timeouts

Installation
1

Gibt es eine Möglichkeit, das Timeout-Intervall zu verlängern, wenn Discourse auf die Bestätigung des SMTP-Servers wartet, dass eine E-Mail-Nachricht übermittelt wurde? Gibt es alternativ eine Möglichkeit, Discourse so zu konfigurieren, dass diese Bestätigung nicht erforderlich ist?

Ich habe ein Problem, bei dem meine Discourse-Instanz doppelte E-Mails generiert. Discourse erhält einen Net::Timeout-Fehler beim Übermitteln von E-Mails zur Zustellung. Mein E-Mail-Anbieter liefert die E-Mails tatsächlich aus, aber Discourse weiß dies nicht und sendet die E-Mails erneut. Dies wiederholt sich endlos.

2

Wir haben kürzlich die SMTP-Timeout-Anpassung hinzugefügt, aber das betrifft die eigentliche SMTP-Verbindung:

Es klingt, als ob Ihr Problem nach dem Aufbau der Verbindung auftritt und das Problem beim Timeout der Sende-Transaktion liegt?

2 „Gefällt mir“
3

Ja, soweit ich das beurteilen kann. Die Verbindung wird hergestellt, die E-Mail-Nachricht wird übermittelt, aber danach wird ein Net::Timeout-Fehler gemeldet.

Mit dem Discourse_Doctor-Skript sehe ich die Nachrichten-ID, die bei erfolgreicher Übertragung zurückgegeben wird, und den Net::Timeout-Fehler, wenn sie fehlschlägt.

Dieses Problem trat nach dem Update auf Discourse 2.9.0.beta5 auf. Ich vermute, dass Discourse mit diesem Update weniger tolerant gegenüber diesem Fehler geworden ist.

4

Ich konnte keine verwandten Änderungen in den Ruby-Gems Mail und Net/SMTP finden. Funktioniert Ihr SMTP-Server möglicherweise nicht richtig? Wäre es möglich, zu einem anderen zu wechseln?

1 „Gefällt mir“
5

Danke für die Überprüfung. Ich stimme zu, mein E-Mail-Anbieter scheint die Ursache des Problems zu sein, da er nach dem Absenden einer E-Mail nicht schnell genug reagiert. Ich kann nur vermuten, dass das Problem irgendwie mit der Auslastung zusammenhängt, da ich das Problem an manchen Tagen nicht habe.

Der Wechsel des E-Mail-Anbieters ist aus einer Reihe von Gründen eine erhebliche Herausforderung. Einen Weg zu finden, Discourse so zu konfigurieren, dass er dies umgeht, ist die attraktivste Lösung.

6

Ein Wechsel zu einem neuen Mail-Provider scheint die einzige Lösung für dieses Problem zu sein, aber das erfordert, dass ich den Mail-Provider für meine gesamte Domain neu konfiguriere, was eine Aufgabe ist, die ich vermeiden möchte.

Gibt es eine Änderung, die ich am Discourse-Code vornehmen kann, der ausgehende E-Mails verarbeitet, damit er E-Mail-Übermittlungsfehler ignoriert, wie er es in der Vergangenheit getan hat? Ich bin kein Rails-Entwickler, daher bin ich mir nicht sicher, wo ich überhaupt anfangen soll. Ich möchte meine Fähigkeit, zukünftige Discourse-Updates zu erhalten, nicht beeinträchtigen.

7

Worauf stützt du die obige Aussage? Du kannst E-Mails pro Domain/Subdomain wirklich nur gegen einen Satz von Infrastruktur empfangen, aber mehrere Dienste können E-Mails in deinem Namen weiterleiten.

Alternativ könntest du auch eine neue Subdomain speziell für deine Instanz einrichten, was nicht einmal einen Neuaufbau zur Konfiguration erfordert.

8

Ich habe dies in der Vergangenheit einmal versucht und die Dinge falsch konfiguriert, weshalb ich sie nicht herausfinden konnte, daher meine Zurückhaltung, etwas zu ändern. Ich würde es auch vorziehen, wenn die Discourse-E-Mails von meiner Unternehmensdomäne stammen würden, aber da das nicht mehr funktionieren wird, werde ich erneut versuchen, wie Sie vorschlagen, und eine Subdomäne für ausgehende E-Mails verwenden.

9

Ich habe eine E-Mail-Subdomain mit RackSpace Cloud erstellt und bestätigt, dass ich von meinem Mac aus E-Mails über diese Domain mit Apple Mail und curl senden kann. Ich habe auch bestätigt, dass ich E-Mails von meinem Server mit curl senden kann. Allerdings erhalte ich diesen Fehler von discourse-doctor:

Testing sending to support@latenightsw.com using secure.emailsrvr.com:465, username:username with plain auth.
======================================== ERROR ========================================
                                    UNEXPECTED ERROR

Net::ReadTimeout

====================================== SOLUTION =======================================
This is not a common error. No recommended solution exists!

Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)

Meine app.yml-Datei enthält diese Einstellungen:

  DISCOURSE_SMTP_ADDRESS: secure.emailsrvr.com         # (mandatory)
  DISCOURSE_SMTP_PORT: 465                             # (optional)
  DISCOURSE_SMTP_USER_NAME: username      # (optional)
  DISCOURSE_SMTP_PASSWORD: password               # (optional, WARNING the char '#' in pw can cause problems!)

  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

Dies entspricht der hier dokumentierten Konfiguration: https://docs.rackspace.com/support/how-to/rackspace-email-and-hosted-exchange-settings.

Ich habe versucht, DISCOURSE_SMTP_ENABLE_START_TLS auf false zu setzen. Andere Beiträge zum Fehler Net::ReadTimeout schlagen vor, diese Einstellungen auszuprobieren, aber dies machte keinen Unterschied:

  DISCOURSE_SMTP_AUTHENTICATION: "login"
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

Wie kann ich dieses Problem diagnostizieren?

10

@Falco, wie kann ich diese Änderung an meiner Discourse-Konfiguration vornehmen? Ich kann keine Dokumentation für eine Einstellung finden, die ich zu meiner app.yml-Datei hinzufügen kann.