Zugriff auf Mail-Relay-Server verweigert

Ich versuche hart, Antworten per E-Mail über den mail-receiver-Container zu aktivieren. Dabei erhalte ich konsequent Fehler:

NOQUEUE: reject: RCPT from ... 454 4.7.1 <...>: Relay access denied

Warum ist das so? Wie kann ich in den mail-receiver-Container gelangen, die Postfix-Konfiguration untersuchen und das Problem debuggen? Ich habe den Postfix-Server auf dem System, auf dem dies ausgeführt wird, deaktiviert, da es einen Konflikt mit Port 25 gab. Ist das falsch?

Ich bin mir ziemlich sicher, dass die DNS-MX-Einträge korrekt sind, und dies tritt bei jedem Server auf, der eingehende E-Mails sendet. Ich verwende Amazon SES für den ausgehenden Verkehr im App-Container, und das funktioniert einwandfrei.

Ich bin ein Discourse-Neuling und weiß nicht, wie man das Ökosystem debuggt. Ich bin ein Postfix-Experte, weiß aber nicht, wie man es in dieser containerisierten Umgebung konfiguriert.

Zuerst einmal: Wenn Sie bereits eine Postfix-Instanz betreiben, benötigen Sie den Mail-Empfänger-Container nicht wirklich.

Sie können Postfix als E-Mail-Empfänger für Antwort-E-Mails konfigurieren und Discourse so einrichten, dass es diese E-Mails abruft.

Dieses howto aus dem Jahr 2014 gibt Ihnen genügend Anhaltspunkte, um zu starten, und ich gehe davon aus, dass Sie Postfix selbstständig einrichten können.

Ich stimme dem überhaupt nicht zu. Der Vorteil des Mail-Empfängers besteht darin, dass E-Mails über die API zugestellt werden, anstatt abgefragt zu werden. Der Unterschied in der Zeit, die E-Mails benötigen, um in Discourse anzukommen, ist erheblich (Minuten gegenüber Sekunden).

Auch bei der Einfachheit der Konfiguration gibt es einen großen Unterschied: Für den Mail-Empfänger müssen nur drei Zeilen in einer YAML-Datei aktualisiert werden, während die OOBE von Postfix … mehr erfordert.

Dieser Fehler deutet darauf hin, dass die E-Mail-Domains nicht übereinstimmen.

Da Sie Teile der Nachricht unkenntlich gemacht haben, können wir das Problem nicht einfach für Sie beheben.

Wenn du irgendeine E-Mail so erhältst, wie du es erwartest, bedeutet dies, dass jemand versucht, deinen Mailserver zu nutzen, um E-Mails an eine andere Domain zu liefern. Wenn beispielsweise jemand seinen MX-Eintrag auf deine IP-Adresse zeigt. Oder, und davon habe ich noch nie gehört :wink: , versucht jemand, deinen Mailserver auf betrügerische Weise zu nutzen, um unerwünschte E-Mails zu versenden.

Stammen alle diese Fehler von derselben IP? Kannst du in den Logs erkennen, für welche Domain die fehlerhaften Nachrichten bestimmt sind?

Das Einfachste ist, es zu ignorieren.

Ich hatte dieses Problem bei einem zuvor funktionierenden mail-receiver, an dem ich einige Änderungen vorgenommen hatte. Ich hatte gedacht, den Container neu zu erstellen, aber offensichtlich war etwas schiefgelaufen, da ich für alle Empfänger mehrere Fehlermeldungen ‘Relay access denied’ erhielt. DNS war korrekt konfiguriert.

Letztendlich hat ein guter alter git pull und launcher rebuild mail-receiver das Problem behoben. Ich poste dies hier, falls es auch für andere hilft.

Habe denselben Fehler mit Mail-Empfangsberichten: Relay access denied (in reply to RCPT TO command).

Der E-Mail-Empfang funktioniert bei einer Neuinstallation nicht, aber ich habe dies schon einmal zum Laufen gebracht. Ich glaube, alle Einstellungen sind korrekt, aber vielleicht habe ich etwas übersehen.

Das bedeutet normalerweise, dass die E-Mail an eine Domain zugestellt wird, die nicht diejenige ist, die der Empfänger zu akzeptieren konfiguriert hat.

Ich habe es auf dieselbe Subdomäne wie die Discourse-Site eingestellt.

Für den MX-Eintragswert ist „subdomain.domain“ und der Host soll nur „subdomain“ oder @ sein?

Weiß jemand, was die Fehlermeldung „Relay access denied“ verursacht?

Dies geschieht, wenn die Empfängerdomäne nicht mit der in mail-receiver.yml konfigurierten Domäne übereinstimmt.

Ist das die Adresse, an die du die E-Mail sendest?

Gleiche Adresse, funktioniert jetzt nach dem Neuerstellen des Mail-Receivers.
Ich glaube, ich hatte das schon einmal neu erstellt, aber es funktionierte nicht. Gut, dass es jetzt funktioniert.

Muss ich Port 25 zusätzlich für mail-receiver zulassen, damit dieser ordnungsgemäß funktioniert?

In diesem Fall bedeutet “ordnungsgemäß funktionieren”, dass eingehende E-Mails, die in .\launcher logs mail-receiver angezeigt werden, die Discourse Admin-Oberfläche erreichen.

Ja, Sie müssen Port 25 öffnen. Dies könnte als optionale Regel zu dieser Anleitung hinzugefügt werden.

Nun, ich habe keine 25 offen. Also, nein.

Aber ufw status ist nicht so interessant. Stattdessen ist nft list ruleset interessant.

Update: ufw deny 25 wurde angewendet und mail-reciver funktioniert einwandfrei (07.02.2025)

Kann bestätigen, dass dies korrekt ist, obwohl ich einen weiteren Fehler gemacht hatte. Dies betrifft mein zweites Forum zur Implementierung von mail-receiver, und auf dem ersten hatte ich den MX-Eintrag der Domain, die die E-Mails empfängt, als Value für die DISCOURSE_BASE_URL eingetragen.

Ich bekomme nun die E-Mails über meine (zweite) Forum-Benutzeroberfläche, anstatt nur über meine erste :tada:

Hinweis: Dieser Glaube an die Korrektheit könnte darauf zurückzuführen sein, dass ich ./launcher rebuild mail-receiver nach der Änderung der yml (06.02.2015) nicht ausgeführt habe.

Ich stelle mir vor, Sie müssen Port 25 nicht auf einer Firewall eines Azure- oder VPS-Panels zulassen – also vor Ubuntu

da der MX-Eintragswert auf die Website und nicht auf die E-Mail-Domain zeigen sollte, interessant

Der offizielle Leitfaden erwähnt, dass Port 25 geöffnet sein muss:

Ich selbst hatte ein Problem mit dem Mail-Empfänger, weil ich vergessen hatte, Port 25 in meiner Firewall zu öffnen. Das Hinzufügen der Regel löste das Problem.

Eine bessere Lösung wäre es jedoch, nur die relevante IP-Adresse zuzulassen?

Lass uns das meinem Mail-Empfänger nicht erzählen :wink:

Der ausgehende Versand erfolgt über Amazon SES. Eingehende E-Mails kommen per MX zum Forum-Domain und jetzt kommt Docker ins Spiel.

Der Grund dafür ist Docker und seine interne Arbeitsweise. Es kümmert sich einfach nicht um ufw. Wenn du eine genaue detaillierte Erklärung möchtest, warte einen Moment – ich habe einmal gefragt, warum Discourse meine Firewall ignoriert, und der Grund war der Paketverkehr. Aber tiefgehend zu verstehen, was vor sich geht, ist nicht mein Ding. Für mich reicht es, dass die Dinge funktionieren. Und vertrau mir: ufw hat nur die Ports 22, 80 und 443 geöffnet.

Ich vermute, du hast eine Situation zitiert, in der der Mail-Empfänger auch den E-Mail-Versand mit Postfix übernimmt.