Kann keine E-Mail senden - Problem mit Port 465

[schungx (Stephen Chung)]

Ich möchte den SMTP-Anbieter wechseln, aber es scheint nicht zu funktionieren, obwohl ich sicher bin, dass der Server E-Mails senden kann.

Ich habe dies in app.yml:

  DISCOURSE_SMTP_ADDRESS: <<SMTP SERVER>>
  DISCOURSE_SMTP_PORT: 465
  DISCOURSE_SMTP_USER_NAME: <<USER>>
  DISCOURSE_SMTP_PASSWORD: <<PASSWORD>>

Die Verwendung von telnet <<SMTP SERVER>> 465 stellt eine Verbindung her, aber wenn ich versuche, E-Mails zu senden, gibt Discourse Folgendes zurück:

ERROR - Net::ReadTimeout with #<Socket:(closed)>

Hat jemand einen Hinweis, was ich einstellen muss?

Ich habe den Server anhand dieses Themas überprüft: Troubleshoot email on a new Discourse install

Es scheint, dass die Verbindung zum Server hergestellt und eine Test-E-Mail korrekt gesendet wird, wenn ich dies manuell tue:

> sudo ./launcher enter app
root@support-app:/var/www/discourse# openssl s_client -connect mail.xxxxxxxx.com:465
  :
  :
  massive amount of junk
  :
  :
220 xxxxxxx.com Anti-spam GT for Coremail System (mispb-6da2110f-64b0-4d67-acf1-2d302bd594f9-xxxxxxx.com[20220915])
EHLO mail.xxxxxxxxx.com
250-mail
250-PIPELINING
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-coremail 1Uxr2xKj7kG0xkI17xGrUDI0s8FY2U3Uj8Cz28x1UUUUU7Ic2I0Y2UrpDiNKUCa0xDrUUUUj
250-STARTTLS
250-SMTPUTF8
250 8BITMIME
AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
235 Authentication successful
mail from: <xxx@xxxxxx.com>
250 Mail OK
rcpt to: <xxxx@xxxxxxx.com>
250 Mail OK
data
354 End data with <CR><LF>.
content

.
250 Mail OK queued as AQAAfwBXr9nSGHdj3hEgAA--.7073S2

[RGJ (Richard - Communiteq)]

@schungx

Es scheint, dass es sich mit dem Server verbindet und eine Test-E-Mail korrekt sendet, wenn ich das manuell mache:

Wie lange dauert es, bis die Ausgabe erscheint?

SMTP Net::ReadTimeout without relation to net or login problems - SMTP host is just slow

Hello, since view weeks sending mail from my Discourse instance fails. The SMTP settings are unchanged, curl test is still working but notably slow. The smtp server from our hoster (that we need to send mails with) has a consistent send time of 7 seconds. cat testmail | curl -vvv --url 'smtp://smtp.<HOST>:587' --mail-from mail@<DOMAIN> --mail-rcpt <ME> --user "mail@<DOMAIN>:<PW>" -T - % Total % Received % Xferd Average Speed Time Time Time Current …

[schungx (Stephen Chung)]

@Richard – Communiteq

Wie lange dauert es, bis die Ausgabe erscheint?

Ziemlich sofort, nachdem ich einen Befehl gesendet habe.

BEARBEITEN: Gibt es eine Möglichkeit, detailliertere Protokolle zu erhalten, um herauszufinden, welcher Schritt den Fehler verursacht?

[pfaffman (Jay Pfaffman)]

Es ist wahrscheinlich, dass der ausgehende Port von Ihrem Hosting-Anbieter blockiert wird. Wenn Sie einen Dienst wie Mailgun (oder die meisten anderen) verwenden, sollte Port 2525 funktionieren. Wenn es sich um einen Mailserver handelt, den Sie selbst betreiben, können Sie ihn auf einem anderen Port (z. B. 2525) lauschen lassen.

Oder (wahrscheinlich am schwierigsten) Sie können ein Ticket bei Ihrem Server-Hoster eröffnen und ihn bitten, den Port zu öffnen.

[schungx (Stephen Chung)]

Nun, wenn ich bedenke, dass ich ./launcher enter app ausführen und dann openssl verwenden kann, um eine Verbindung zum Mailserver herzustellen, mich per SMTP anzumelden und erfolgreich eine E-Mail aus dem Discourse-Container heraus zu senden, bezweifle ich, dass es am Port liegt, der nicht funktioniert…

[schungx (Stephen Chung)]

Ich habe den Code verfolgt und es scheint, dass EHLO gar nicht erreicht wurde. Der SMTP-Server ist verbunden, aber der SSL-Handshake scheint zu fehlen, sodass der Server abbricht und Discourse keine Antwort erhält, daher der Fehler.

Ich vermutete daher, dass die Unterstützung für Port 465 einen Fehler zu haben scheint (er verwendet standardmäßig SSL, aber ich glaube nicht, dass Discourse das erkennt), sodass wahrscheinlich nie eine SSL-Verbindung aufgebaut wird.

Der Wechsel zu Port 25 scheint zumindest den Fehler zu beseitigen, obwohl ich noch keine gesendeten E-Mails erhalte…

EDIT: Ich kann bestätigen, dass Port 25 ordnungsgemäß funktioniert (ebenso wie 587, aber leider stellt mein SMTP-Server 587 nicht zur Verfügung).

Ich habe vorher keine E-Mails erhalten, da die IP-Adresse des Discourse-Servers aufgrund zu vieler fehlgeschlagener Versuche vorübergehend von dem SMTP-Server auf die schwarze Liste gesetzt wurde.

[RGJ (Richard - Communiteq)]

Ich glaube, Sie haben Recht.

Und es stellt sich heraus, dass Sie nicht der Erste sind… wenn ich nach DISCOURSE_SMTP_PORT 465 suche, finde ich eine ganze Reihe ähnlicher Probleme.

• Not able to send email Net::ReadTimeout - #18 by Stranik
• Email not working but i can access smtp server from container
• DigitalOcean + Siteground Email via port 465 won’t work (2525 will work)
• Problem with SMTP configuration
• Post-install, Curl can send email, but Discourse cannot. Help to fix?
• Mail problem on discourse with reverse proxy
• Can't setup SMTP with SSL/TLS
• SMTP email issue Net::Timeout - #3 by neounix

Der letzte enthält einen Link zur (möglichen?) Lösung.

Mit diesem Patch ist es möglich,
DISCOURSE_SMTP_FORCE_TLS=true zu setzen, um implizites TLS über Port 465 zu verwenden

[JammyDodger]

Ich habe auch ziemlich viele Themen zum Thema „465-Problem“ gesehen. Meine E-Mail-Fehlerbehebung für alles andere als das Offensichtliche ist jedoch nicht gut, daher habe ich die Fehlerbehebungsanleitung zitiert:

@Discourse

E-Mail-SMTP-Port-Auswahl (Verwendung von 465?)

Die Möglichkeit, AUTH mit „telnet“ zu verwenden, ist bei den ersten Schritten der E-Mail-Fehlerbehebung äußerst wichtig.

Port 465 (SMTP über SSL) ist weitgehend zugunsten von STARTTLS über Port 25 veraltet. Möglicherweise müssen Sie alternative Ports wie Port 2525 oder Port 587 (Mail Submission) ausprobieren, wenn die Dinge nicht wie erwartet funktionieren.

Gibt es etwas, das wir dem hinzufügen können, um den Leuten zu helfen?

[RGJ (Richard - Communiteq)]

@JammyDodger

Gibt es etwas, das wir hinzufügen können, um den Leuten zu helfen?

Nun, wenn @schungx bestätigen kann, dass DISCOURSE_SMTP_FORCE_TLS=true tatsächlich eine Lösung ist, können wir dies hinzufügen.

[schungx (Stephen Chung)]

@RGJ

Nun, wenn @schungx bestätigen kann, dass DISCOURSE_SMTP_FORCE_TLS=true tatsächlich eine Lösung ist, können wir das hinzufügen.

Ich werde es sofort versuchen!

EDIT: @RGJ Ich kann bestätigen, dass DISCOURSE_SMTP_FORCE_TLS: true in app.yml das Problem erfolgreich löst!

Ich schlage eine fette Warnung vor: Wenn Sie Port 465 verwenden, setzen Sie DISCOURSE_SMTP_FORCE_TLS: true, oder sollte Discourse nicht intelligent genug sein, dies zu erkennen?