Wie wird dies gemacht, um eine neue Containerdefinition in diesem Verzeichnis zu erstellen!?
Durch Ausführen der Befehle, die unmittelbar nach diesem Text angezeigt werden. Genau genommen erstellen Sie die Datei nicht in diesem Verzeichnis, sondern im Unterverzeichnis containers, genau wie app.yml.
Danke, zuerst schienen diese nicht zu funktionieren, aber jetzt bin ich mit Folgendem zum Texteditor gelangt:
Es scheint ein Problem damit zu geben. Wenn ich ./launcher logs mail-receiver ausführe, wird discourse_base_url=https://discourse.example.com gemeldet, anstatt der im Texteditor angegebenen Domain.
Ich habe versucht, den Bootstrap von mail-receiver neu zu erstellen/neu zu starten, aber die Domain hat sich nicht geändert.
Ich habe ein kleines Problem, ich könnte ein paar Ratschläge gebrauchen!
root@JEN /var/discourse # ./launcher start mail-receiver
x86_64 arch detected.
starting up existing container
+ /usr/bin/docker start mail-receiver
Error response from daemon: driver failed programming external connectivity on endpoint mail-receiver (721279d807e22a80580f2357fae40cc): Error starting userland proxy: listen tcp4 0.0.0.0:25: bind: address already in use
Error: failed to start containers: mail-receiver
dann…
root@JEN /var/discourse # sudo lsof -i tcp:25
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
master 4400 root 13u IPv4 24419 0t0 TCP *:smtp (LISTEN)
master 4400 root 14u IPv6 24420 0t0 TCP *:smtp (LISTEN)
Ich habe auch versucht…
root@JEN /var/discourse # netstat -nlp | grep 25
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 4400/master
tcp6 0 0 :::25 :::* LISTEN 4400/master
und…
root@JEN /var/discourse # ps j 4400
PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND
1 4400 4400 4400 ? -1 Ss 0 0:02 /usr/lib/postfix/sbin/master -w
Ich finde Anleitungen online, um den Container zu stoppen und den Prozess zu beenden (Prozess 4400?).
Ist das sicher und wird es das Problem beheben?
Muss ich (oder sollte ich, oder sollte ich nicht) Port 25 in der Datei mail-receiver.yml auf einen anderen Port ändern?
Vielleicht haben Sie Postfix installiert und müssen es entfernen?
Sie können den Port nicht ändern. Sie müssen alles stoppen, was ihn verwendet. Einfaches Beenden funktioniert nicht, denn wenn Sie neu starten, wird es ein Wettlauf sein, welcher Prozess zuerst startet.
Das habe ich mir auch gedacht. Ich kann mir nicht vorstellen, wie es dorthin gekommen ist, aber ich werde versuchen, es zu entfernen. Ansonsten kann ich einfach Gmail verwenden, das anscheinend einwandfrei funktioniert.
Ich habe mein Forum gerade in eine neue Umgebung verschoben und als Ergebnis den Mail-Empfänger neu installiert. Es sieht so aus, als ob es sich um eine neuere Version handelt als die, die ich zuvor installiert hatte. Die YML-Konfiguration hat sich mit DISCOURSE_BASE_URL, das DISCOURSE_MAIL_ENDPOINT ersetzt, geringfügig geändert. Der Inhalt der YML-Datei spiegelt die Änderung wider, aber die Anweisungen am Anfang dieses Threads müssen aktualisiert werden.
Außerdem erhalte ich beim Empfang einer E-Mail, die zurückgewiesen/abgelehnt wird, die folgenden Fehler…
Jun 08 11:50:42 mail-receiver postfix/smtp[117]: fatal: unknown service: smtp/tcp
Jun 08 11:50:42 mail-receiver postfix/smtp[118]: fatal: unknown service: smtp/tcp
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 117 exit status 1
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: private/smtp socket: malformed response
Jun 08 11:50:43 mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 118 exit status 1
Jun 08 11:50:43 mail-receiver postfix/qmgr[101]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Gültige Nachrichten scheinen korrekt verarbeitet zu werden. Die vorherige Version des Mail-Empfängers gab diese Fehler, soweit ich das aus den letzten Logdateien sehen konnte, nicht aus. Ich habe ein wenig recherchiert und bin auf - https://blog.badgerops.net/smtp-socket-malformed-response-on-a-fips140-2-sytstem/ gestoßen.
Das Hinzufügen des Folgenden zur Datei mail-receiver.yml scheint das Problem für mich zu beheben:
## Fix smtp errors
POSTCONF_smtp_tls_fingerprint_digest: sha256
POSTCONF_smtpd_tls_fingerprint_digest: sha256
Hier wird ein Beitrag hinterlassen, um darauf hinzuweisen, dass wir DMARC-Unterstützung für den Mail-Empfänger über ein Image discourse/mail-receiver:with-dmarc hinzugefügt haben. Weitere Details finden Sie unter Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver im OP.
2 Beiträge wurden in ein bestehendes Thema zusammengeführt: Mail-receiver relay access denied
Ich wollte etwas für den Abschnitt zur Fehlerbehebung hinzufügen.
Mail-Empfänger (direkte Zustellung) funktionierte für mehrere Domains, empfing aber keine Nachrichten von Gmail-Benutzern. Ich konnte nicht herausfinden, warum. Es gab nichts in den Protokollen außer einer Verbindung/Trennung von Google. Alles sah gut aus und die Online-Tools bestätigten, dass DNS in Ordnung war.
Schließlich erstellte ich einen SMTP TLS-Berichtseintrag in DNS, z. B.
_smtp._tls.discourse.mydomain.com TXT v=TLSRPTv1;rua=mailto:me@wherever.com
Ein paar Stunden später sandte Google (Gmail) einen Bericht, der zeigte, dass es eine MTA-STS-Richtlinie zwischengespeichert hatte, die nicht den aktuellen MX-Einträgen entsprach. Ich war besorgt, dass Google diese zwischengespeicherte Richtlinie eine Woche lang beibehalten würde, da sie meinen aktualisierten _mta-sts DNS-Eintrag ignoriert zu haben schien, der eine Aktualisierung hätte auslösen sollen.
Und kurz darauf flossen alle meine gesicherten Gmails in Discourse ein, ohne dass ich etwas tun musste. Der Bericht half mir, Googles Perspektive auf das Problem zu verstehen und ersparte mir, mir den Kopf zu zerbrechen, als die Nachrichten dann doch zu fließen begannen.
SMTP TLS-Berichte werden nur selten ausgestellt, also haben Sie Geduld.
Da die Anleitung nichts über die Konfiguration von MTA STS aussagt, würde das Hinzufügen von Diagnoseschritten dafür nicht die 99,999 %+ der Benutzer verwirren, die es nicht konfigurieren?
In meinem Fall reichte die Hinzufügung eines einzigen DNS-Eintrags aus, um mein Problem zu beleuchten. Da die Anleitung bereits die Erstellung von DNS-Einträgen für die Installation von Mail-Receiver vorschreibt, scheint ein zusätzlicher Eintrag im Abschnitt Fehlerbehebung als letztes Mittel keine Überdehnung zu sein. Allerdings sehe ich, dass Ihr Beitrag zwei „Likes“ hat und meiner keinen, das könnte also das Ende der Fahnenstange sein.
Das sind gute Nachrichten. Das scheinen gute Informationen zu sein, die dem Leitfaden hinzugefügt werden sollten, insbesondere da Gmail ein häufiger Absender ist.
Die Anleitung schreibt die Erstellung von DNS-Einträgen vor, damit Mail-Receiver funktioniert, nicht zur Konfiguration von MTA STS. Ein Benutzer, der der Anleitung folgt, wird niemals das Problem haben, das Sie hatten. Daher besteht keine Notwendigkeit, die Anleitung mit zusätzlichen, unnötigen Schritten zu verkomplizieren.
Kann der Mail-Empfänger im Allgemeinen von Gmail gesendete E-Mails an neue Themen verarbeiten?
Das scheint ein großes Problem zu sein, aber nicht, wenn die Ursache ein Einzelfall ist.
Ich bin zu dem Schluss gekommen, dass Matt Recht hat. Meine Installation musste sich speziell mit MTA-STS auseinandersetzen, da die reguläre E-Mail ihrer Domain von Mail In a Box https://mailinabox.email/ gehandhabt wird, das auf eine strikte MTA-STS-Richtlinie besteht und Gmail diese Richtlinie durchsetzt. Standardmäßig kann die Richtlinie mit der Konfiguration für Mail-Receiver in Konflikt geraten. Die meisten Domains haben keine Richtlinie. Wenn eine Domain eine Richtlinie hat, ist diese unter
https://mydomain.com/.well-known/mta-sts.txt
sichtbar.
Meine funktionierende Richtlinie sieht wie folgt aus…
version: STSv1
mode: none
mx: mail.mydomain.com
mx: discourse.mydomain.com
max_age: 86400
Ich hoffe, „mode: none“ nach etwas mehr Arbeit auf „mode: enforce“ aufzurüsten.
Könnte mich bitte jemand daran erinnern – wenn wir Discourse über die Befehlszeile neu erstellen, wird dann automatisch der Mail-Receiver-Container neu erstellt, oder müssen wir das separat tun? Danke.
Nein, er wird nur neu gebaut, wenn Sie ihn dazu auffordern. Sie müssen den Mail-Empfänger nicht oft neu bauen.
Es hat mir definitiv geholfen:)
