Ich betreibe ein Test-Setup (derzeit 2.4.0.beta4) zu Hause auf einem lokalen Mini-PC mit Ubuntu 16.04 LTS. Die Installation erfolgte mithilfe des hervorragenden 30-Minuten-Installationsleitfadens. Es verfügt über einen vollständigen Domainnamen (FQDN). Das Versenden von E-Mails über ein Postfach meines ISP mit SMTP auf Port 587 und einfacher Authentifizierung funktioniert seit über einem Jahr einwandfrei.
Mir ist gerade aufgefallen, dass ich seit einiger Zeit keine E-Mail-Benachrichtigungen mehr erhalten habe, wie zum Beispiel „neue Version verfügbar“. Bei der Prüfung unter Admin > E-Mails > Übersprungen zeigt sich, dass alle E-Mails folgendes Problem aufweisen:
550-Bad HELO: localhost.localdomain existiert nicht – Bitte sehen Sie RFC 2821
Beim Rückblick auf das Postfach könnte dies mit 2.4.0.beta2 begonnen haben. Es könnte aber auch eine Richtlinieänderung meines ISP um dieselbe Zeit (Ende Juli 2019) gewesen sein. Ich bin mir nicht sicher, wo ich anfangen soll. Woher kommt dieses localhost.localdomain? Während der Installation musste ich nur die app.yml bearbeiten, und diese zeigt meinen FQDN korrekt unter DISCOURSE_HOSTNAME an:
Ich hatte noch nie von Mailgun gehört. Meinen Sie mailgun.com, den „Transactional Email API Service“? Um Ihnen eine Vorstellung von meinem Kenntnisstand zu geben: Ich weiß nur vage, was eine API ist, aber ich würde nicht wissen, wie man sie verwendet. Ich könnte jedoch versuchen, über SMTP auf ein anderes Postfach bei einem anderen ISP zuzugreifen. Ich werde morgen hier Bericht erstatten.
Mailgun stellt Ihnen SMTP-Zugangsdaten zur Verfügung, sobald Sie sich registrieren. Ich bin sicher, dass Sie es allein durch Befolgen der Anweisungen während der Registrierung herausfinden können.
@itsbhanusharma, @jtbayly Danke! Ich habe es gerade geschafft, eine Testnachricht über Mailgun zu senden. Das Problem lag also an einer neuen Richtlinie auf dem SMTP-Server meines ISP. Ich werde Mailgun wahrscheinlich weiter verwenden.
Ich habe weitere Recherchen angestellt, da ich Mailgun für unser Produktionsforum nicht verwenden kann.
Im Header der über Mailgun eingehenden E-Mails sehe ich immer noch:
Received: from localhost.localdomain
HELO ist der erste Befehl im SMTP-Dialog (Quelle).
Es sollte etwa so aussehen:
HELO discourse.mydomain.tld
Einige SMTP-Server, wie Postfix, bieten eine Option, dies gegen die IP-Adresse des Clients zu prüfen. localhost.localdomain löst sich in die IP-Adresse des SMTP-Servers auf, die wahrscheinlich in seiner Hosts-Datei eingetragen ist. Es scheint, dass ISPs dies in ihrem Kampf gegen Spammer aktivieren.
Es funktioniert mit Mailgun, weil Mailgun diese Prüfung nicht durchführt. Dennoch ist es ein „schlechtes HELO“.
Zum Vergleich: Ich habe eine E-Mail mit einem E-Mail-Client (Sylpheed) auf demselben System versendet. Das funktioniert, sogar mit dem Postfach meines ISPs, und es scheint so zu sein:
HELO HL80L
HL80L ist mein lokaler Netzwerkname. Das ist immer noch kein FQDN, aber es erscheint zumindest nicht als offensichtliche Fälschung für den Server meines ISPs.
Vielleicht muss das also verbessert werden. Disclaimer: Ich bin kein SMTP-Experte.
Übrigens, es funktioniert wieder über das Postfach meines Internetdienstanbieters, indem ich einen MTA als Relay dazwischengeschaltet habe. Es handelt sich um eine auf Postfix basierende Anwendung auf meinem NAS. Dabei wird HELO mydomain.tld verwendet.
Ich werde prüfen, ob wir beim Wechsel zu Debian 10 oder beim Upgrade auf Rails 6 etwas beschädigt haben. In der Zwischenzeit sollte das Setzen von DISCOURSE_SMTP_DOMAIN in app.yml funktionieren. Ich denke, wir sollten standardmäßig den Wert von DISCOURSE_HOSTNAME verwenden, wenn die SMTP-Domäne nicht explizit festgelegt ist.
Danke, @gerhard! DISCOURSE_SMTP_DOMAIN war in meiner app.yml nicht vorhanden, aber ich habe tief durchgeatmet, es hinzugefügt, und ja, das hat funktioniert. Ich kann wieder mein Postfach meines ISP nutzen. Auf der Empfangsseite finde ich im Header:
Received: from XXXXXXX.cable.dynamic.v4.ziggo.nl ([XX.XX.XX.X] helo=mydomain.tld)
by smtp7.mnd.mail.iss.as9143.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
In der Zwischenzeit habe ich gelernt, dass sowohl RFC 2821 als auch der Nachfolger RFC 5321, Abschnitt 4.1.4 festlegen:
Ein SMTP-Server DARF überprüfen, ob der Domänenname-Argument in der EHLO-Befehl tatsächlich der IP-Adresse des Clients entspricht. Wenn die Überprüfung jedoch fehlschlägt, DARF der Server eine Nachricht aus diesem Grund NICHT ablehnen. Die bei dem Überprüfungsversuch erfassten Informationen dienen ausschließlich Protokollierungs- und Nachverfolgungszwecken. Beachten Sie, dass dieses Verbot nur auf die Übereinstimmung des Parameters mit seiner IP-Adresse anwendbar ist; siehe Abschnitt 7.9 für eine ausführlichere Diskussion über die Ablehnung eingehender Verbindungen oder E-Mail-Nachrichten.
Dennoch scheinen viele MTAs wie Postfix und Exim eine optionale Einstellung dafür zu haben. Möglicherweise aktivieren Administratoren dies im Rahmen des anhaltenden Spam-Kampfes.
