Ich habe diesen Fehler gemacht und discourse.example.com in der Datei mail-receiver.yml belassen.
Ich habe dies nun behoben, aber mail-receiver scheint die neuen Details nicht zu „erhalten“.
Wie kann ich mail-receiver „zurücksetzen“ (z. B. was ist der entsprechende Befehl zu ./launcher rebuild app?).
Bearbeiten: Ich habe den vorherigen Beitrag nicht genau genug gelesen, der Befehl lautet ./launcher rebuild mail_receiver.
Ich habe jetzt ein weiteres Problem, bei dem mail-receiver keine E-Mails an Discourse zustellt – ich habe versucht, Hilfe zu suchen, aber ohne Erfolg.
Protokolle:
Starting Postfix
14. Dez. 03:12:32 forum-mail-receiver postfix/master[1]: daemon gestartet -- Version 3.5.6, Konfiguration /etc/postfix
14. Dez. 03:15:47 forum-mail-receiver postfix/smtpd[113]: Verbindung von mail-pl1-f169.google.com[209.85.214.169]
14. Dez. 03:15:47 forum-mail-receiver postfix/smtpd[113]: 821CB37A659: client=mail-pl1-f169.google.com[209.85.214.169]
14. Dez. 03:15:47 forum-mail-receiver postfix/cleanup[120]: 821CB37A659: message-id=<602f2194be912e92b969eacf5eac26e2@frontapp.com>
14. Dez. 03:15:47 forum-mail-receiver postfix/qmgr[98]: 821CB37A659: from=<[meine persönliche E-Mail-Adresse]>, size=4086, nrcpt=1 (Warteschlange aktiv)
<23>14. Dez. 03:15:47 receive-mail[122]: Empfänger: nobody@[meine Forum-URL]
14. Dez. 03:16:20 forum-mail-receiver postfix/smtpd[113]: Trennung von mail-pl1-f169.google.com[209.85.214.169] ehlo=1 mail=1 rcpt=1 bdat=1 quit=1 commands=5
<19>14. Dez. 03:16:47 receive-mail[122]: Konnte die E-Mail nicht an [meine Forum-URL]/admin/email/handle_mail POSTen: execution expired (Net::OpenTimeout)
<19>14. Dez. 03:16:47 receive-mail[122]: /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
/usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
/usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
/usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
/usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
/usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
/usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
/usr/local/bin/receive-mail:13:in `<main>'
14. Dez. 03:16:47 forum-mail-receiver postfix/pipe[121]: 821CB37A659: to=<nobody@[meine Forum-URL]>, relay=discourse, delay=60, delays=0.17/0.01/0/60, dsn=4.3.0, status=deferred (vorübergehender Fehler)
14. Dez. 03:17:32 forum-mail-receiver postfix/qmgr[98]: 7C67437A663: from=<[meine persönliche E-Mail-Adresse]>, size=4093, nrcpt=1 (Warteschlange aktiv)
Irgendeine Idee, was das verursachen könnte?
Die Datei mail-receiver.yml ist gültig, und ich habe auf Tippfehler geprüft:
Das ist der Gültigkeitsbereich meines API-Schlüssels:
Die E-Mail gelangt in mail-receiver, aber sie verbleibt in der Mail-Warteschlange:
Alternativ, gibt es eine Möglichkeit, den Mail-Receiver-Container vollständig zu löschen und von vorne zu beginnen?
Das Problem könnte sein, dass Sie den API-Schlüssel nicht festgelegt haben.
Danke für die Antwort @pfaffman… es ist definitiv in meiner mail-receiver.yml-Konfiguration festgelegt. Sollte es in Anführungszeichen stehen?
(Net::OpenTimeout)
Das ist Ihr Problem. Der E-Mail-Empfänger kann nicht auf Ihre Forum-URL zugreifen. Entweder haben Sie irgendwie die falsche URL oder es gibt ein Netzwerkproblem in Docker zwischen dem E-Mail-Empfänger und Ihrem Forum, glaube ich.
Wie kann ich weitere Fehlerbehebungen durchführen?
ping forum.[mydomain].co.nz
zeigt von innerhalb von mailq:
64 Bytes von [ip].vultrusercontent.com ([ip]): icmp_seq=1 ttl=64 Zeit=0.113 ms
64 Bytes von [ip].vultrusercontent.com ([ip]): icmp_seq=2 ttl=64 Zeit=0.074 ms
64 Bytes von [ip].vultrusercontent.com ([ip]): icmp_seq=3 ttl=64 Zeit=0.069 ms
und so weiter, was zeigt, dass eine Verbindung erfolgreich ist.
forum.[mydomain].co.nz ist der Ort, an dem das Forum gehostet wird, und dieselbe URL wird in MAIL_DOMAIN und DISCOURSE_MAIL_ENDPOINT verwendet.
Wenn ich mir die mail-receiver.yml-Einstellungen genauer ansehe, fehlen mir Anführungszeichen oder https:// irgendwo, wo sie sein sollten?
## Dies ist die Vorlage für den eingehenden E-Mail-Empfänger-Container
##
## Nach Änderungen an dieser Datei MÜSSEN Sie neu erstellen
## /var/discourse/launcher rebuild mail-receiver
##
## SEIEN SIE *SEHR* VORSICHTIG BEIM BEARBEITEN!
## YAML-DATEIEN SIND SUPER SUPER EMPFINDLICH GEGEN FEHLER BEI LEERZEICHEN ODER AUSRICHTUNG!
## Besuchen Sie http://www.yamllint.com/, um diese Datei bei Bedarf zu validieren.
base_image: discourse/mail-receiver:release
update_pups: false
expose:
- "25:25" # SMTP
env:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
## Wohin E-Mails an Ihr Forum gesendet werden sollen. Im Allgemeinen ist es vollkommen in Ordnung,
## hier dieselbe Domain wie das Forum selbst zu verwenden.
MAIL_DOMAIN: forum.[domain].co.nz
# kommentieren Sie diese (und das Volume unten!) aus, um TLS zu unterstützen
# POSTCONF_smtpd_tls_key_file: /letsencrypt/discourse.example.com/discourse.example.com.key
# POSTCONF_smtpd_tls_cert_file: /letsencrypt/discourse.example.com/fullchain.cer
# POSTCONF_smtpd_tls_security_level: may
## Die URL des Mail-Processing-Endpunkts Ihres Discourse-Forums.
## Dies ist einfach die Basis-URL Ihres Forums mit angehängtem `/admin/email/handle_mail`.
## Seien Sie vorsichtig, wenn Sie eine Unterordner-Einrichtung verwenden – in diesem Fall
## muss die URL den Unterordner enthalten!
DISCOURSE_MAIL_ENDPOINT: 'https://forum.[domain].co.nz/admin/email/handle_mail'
## Der Master-API-Schlüssel Ihres Discourse-Forums. Sie können diesen aus dem
## "API"-Tab Ihres Admin-Panels erhalten.
DISCOURSE_API_KEY: 639[rest of API key]884ef
## Der Benutzername, der für die Verarbeitung eingehender E-Mails verwendet werden soll. Sofern Sie
## den `system`-Benutzer nicht umbenannt haben, sollten Sie diesen unverändert lassen.
DISCOURSE_API_USERNAME: system
volumes:
- volume:
host: /var/discourse/shared/mail-receiver/postfix-spool
guest: /var/spool/postfix
# auskommentieren, um TLS zu unterstützen
# - volume:
# host: /var/discourse/shared/standalone/letsencrypt
# guest: /letsencrypt
Führen Sie den Ping innerhalb des Containers aus, d. h. nachdem Sie zuerst ./launcher enter mail-receiver ausgeführt haben?
Es ist auch erwähnenswert, dass Ping (typischerweise ICMP) sich von der Verbindung zu http/https (TCP) unterscheidet und je nach vielen Faktoren in der Netzwerkkonfiguration unterschiedlich funktionieren kann.
Ich würde versuchen, curl nach dem Betreten des Containers zu verwenden, um zu sehen, ob es eine Verbindung zu Ihrem Forum über https herstellen kann, z. B.
cd /var/discourse
./launcher enter mail-receiver
curl -v https://forum.[domain].co.nz
Wenn es funktioniert, wird eine Menge HTML ausgegeben. Wenn nicht, wird ein Fehler angezeigt und -v gibt unterwegs viele Informationen aus, die helfen können, den Grund für das Scheitern aufzudecken.
Wenn es fehlschlägt, lohnt es sich auch, denselben Curl-Befehl außerhalb des Containers auszuführen, um festzustellen, ob er spezifisch für den Container oder für das Hostsystem im Allgemeinen ist.
Vielen Dank, @Simon_Manning, deine Hilfe wird sehr geschätzt! Ich wusste nicht, dass Verbindungen über ping nicht unbedingt die gleichen sind wie Verbindungen über curl.
Ich habe ping innerhalb des Containers ausgeführt, und es hat funktioniert.
Ich habe deine Anweisungen befolgt und curl innerhalb des Containers ausgeführt, und es ist fehlgeschlagen:
root@forum:/var/discourse# ./launcher enter mail-receiver
x86_64 arch detected.
WARNING: containers/mail-receiver.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/mail-receiver.yml
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
root@forum-mail-receiver:/# curl -v https://forum.[domain].co.nz
* Trying [IPv4 address]:443...
* Trying [IPv6 address]:443...
* Immediate connect fail for [IPv6 address]: Cannot assign requested address
* connect to [IPv4 address] port 443 failed: Connection timed out
* Failed to connect to forum.[domain].co.nz port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to forum.[domain].co.nz port 443: Connection timed out
Dann habe ich exit und dann erneut curl ausgeführt und Folgendes erhalten:
root@forum:/var/discourse# curl -v https://forum.[domain].co.nz
* Trying 127.0.1.1:443...
* Connected to forum.[domain].co.nz (127.0.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...und so weiter.
Es scheint, dass es spezifisch für den Container und nicht für das Host-System ist – irgendwelche Ideen?
Ich habe auch ein Support-Ticket bei Vultr (VPS-Anbieter für diese Instanz) eröffnet, um zu sehen, ob es ein Problem auf deren Seite ist!
Docker erstellt virtuelle Netzwerke für die Container und wenn keines angegeben wird, verwenden die Container das Standardnetzwerk. Dieses Standardnetzwerk erlaubt keine Kommunikation zwischen Containern.
Normalerweise ist das für mail-receiver in Ordnung, da Ihr Discourse-Container Port 443 außerhalb dieses Netzwerks verfügbar macht und wenn mail-receiver versucht, eine Verbindung zu 1.2.3.4 herzustellen, verlässt es das Docker-Netzwerk. Das Host-System (oder ein Netzwerk weiter außen) erkennt, dass es wieder hereinkommen muss, und landet dann von außen im Discourse-Container.
Zwei Möglichkeiten fallen mir ein. Eine ist, dass mail-receiver bei der Auflösung des Domainnamens irgendwie die IP-Adresse des Discourse-Containers kennt und daher eine Verbindung innerhalb des Containers blockiert wird. Ich halte das für unwahrscheinlich.
Die andere ist, dass eine Firewall auf dem Host-System Verbindungen blockiert, die einen Container verlassen und einen anderen betreten. Vultr verwendet möglicherweise Standard-Firewall-Regeln, die dies verursachen, oder ich erinnere mich auch vage daran, dass Docker standardmäßig einige Regeln in UFW installiert, sodass dies relevant sein könnte, wenn dies verwendet wird.
Sie können https nicht verwenden, da Sie diese nicht auskommentiert haben:
Das gilt nur für die TLS-Unterstützung auf der Serverseite, d. h. damit andere Mailserver E-Mails über TLS an mail-receiver liefern können.
Es lohnt sich, dies zu tun, da der Discourse-Container offensichtlich ein Zertifikat hat, aber es sollte keinen Einfluss darauf haben, dass mail-receiver eine Verbindung zu Discourse herstellt. Möglicherweise könnte der Rebuild dies jedoch tun, wenn er zufällig etwas am Netzwerk des Containers korrigiert.
Vielen Dank, ich habe diese Zeilen auskommentiert und die Zeile für das Volume.
Meine Datei mail-receiver.yml sieht jetzt so aus:
root@forum:/var/discourse# cat containers/mail-receiver.yml
## dies ist die Container-Vorlage für den eingehenden E-Mail-Empfänger
##
## Nach Änderungen an dieser Datei MÜSSEN Sie neu erstellen
## /var/discourse/launcher rebuild mail-receiver
##
## SEIEN SIE *SEHR* VORSICHTIG BEIM BEARBEITEN!
## YAML-DATEIEN SIND EXTREM EMPFINDLICH GEGEN FEHLER BEI LEERRÄUMEN ODER AUSRICHTUNG!
## Besuchen Sie http://www.yamllint.com/, um diese Datei bei Bedarf zu validieren
base_image: discourse/mail-receiver:release
update_pups: false
expose:
- "25:25" # SMTP
env:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
## Wohin E-Mails an Ihr Forum gesendet werden sollen. Im Allgemeinen ist es völlig in Ordnung,
## dieselbe Domain wie das Forum selbst hier zu verwenden.
MAIL_DOMAIN: forum.[domain].co.nz
# diese auskommentieren (und das Volume unten!) zur Unterstützung von TLS
POSTCONF_smtpd_tls_key_file: /letsencrypt/forum.[domain].co.nz/forum.[domain].co.nz.key
POSTCONF_smtpd_tls_cert_file: /letsencrypt/forum.[domain].co.nz/fullchain.cer
POSTCONF_smtpd_tls_security_level: may
## Die URL des E-Mail-Verarbeitungsendpunkts Ihres Discourse-Forums.
## Dies ist einfach die Basis-URL Ihres Forums mit angehängtem
## `/admin/email/handle_mail`. Seien Sie vorsichtig, wenn Sie eine Unterordner-Einrichtung ausführen – in diesem Fall
## muss die URL den Unterordner enthalten!
DISCOURSE_MAIL_ENDPOINT: 'https://forum.[domain].co.nz/admin/email/handle_mail'
## Der Master-API-Schlüssel Ihres Discourse-Forums. Sie können diesen aus
## dem Reiter "API" in Ihrem Admin-Panel abrufen.
DISCOURSE_API_KEY: '074[rest of API key - yes I generated a new one limited to the system user]d98'
## Der Benutzername, der für die Verarbeitung eingehender E-Mails verwendet werden soll. Sofern Sie
## den Benutzer `system` nicht umbenannt haben, sollten Sie dies so belassen.
DISCOURSE_API_USERNAME: system
volumes:
- volume:
host: /var/discourse/shared/mail-receiver/postfix-spool
guest: /var/spool/postfix
# auskommentieren zur Unterstützung von TLS
- volume:
host: /var/discourse/shared/standalone/letsencrypt
guest: /letsencrypt
Wenn ich eine neue E-Mail sende und ./launcher logs mail-receiver ausführe, sehe ich Folgendes:
Dec 21 22:41:21 forum-mail-receiver postfix/smtpd[132]: connect from mail-pj1-f54.google.com[209.85.216.54]
Dec 21 22:41:23 forum-mail-receiver postfix/smtpd[132]: 16DAC379E42: client=mail-pj1-f54.google.com[209.85.216.54]
Dec 21 22:41:23 forum-mail-receiver postfix/cleanup[139]: 16DAC379E42: message-id=<94fc2bef18b410ae8b121c6af2da2df4@frontapp.com>
Dec 21 22:41:23 forum-mail-receiver postfix/qmgr[100]: 16DAC379E42: from=<[my email address]>, size=5585, nrcpt=1 (queue active)
<23>Dec 21 22:41:23 receive-mail[141]: Recipient: nobody@forum.[domain].co.nzDec 21 22:41:50 forum-mail-receiver postfix/smtpd[143]: connect from mail-oa1-f50.google.com[209.85.160.50]
Dec 21 22:41:52 forum-mail-receiver postfix/smtpd[143]: 2E445379E48: client=mail-oa1-f50.google.com[209.85.160.50]
Dec 21 22:41:52 forum-mail-receiver postfix/cleanup[139]: 2E445379E48: message-id=<6b2f9d646dc46f4fec4af006de01d3ae@frontapp.com>
Dec 21 22:41:52 forum-mail-receiver postfix/qmgr[100]: 2E445379E48: from=<[my email address]>, size=4100, nrcpt=1 (queue active)
<23>Dec 21 22:41:52 receive-mail[147]: Recipient: nobody@forum.[domain].co.nzDec 21 22:41:53 forum-mail-receiver postfix/smtpd[132]: disconnect from mail-pj1-f54.google.com[209.85.216.54] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
Dec 21 22:41:58 forum-mail-receiver postfix/qmgr[100]: 1194937A670: from=<double-bounce@forum-mail-receiver.localdomain>, size=942, nrcpt=1 (queue active)
Dec 21 22:41:58 forum-mail-receiver postfix/smtp[149]: fatal: unknown service: smtp/tcp
Dec 21 22:41:59 forum-mail-receiver postfix/qmgr[100]: warning: private/smtp socket: malformed response
Dec 21 22:41:59 forum-mail-receiver postfix/qmgr[100]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Dec 21 22:41:59 forum-mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 149 exit status 1
Dec 21 22:41:59 forum-mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Dec 21 22:41:59 forum-mail-receiver postfix/error[150]: 1194937A670: to=<postmaster@forum-mail-receiver.localdomain>, orig_to=<postmaster>, relay=none, delay=1192, delays=1191/1/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error)
<19>Dec 21 22:42:23 receive-mail[141]: Failed to POST the e-mail to https://forum.sobercheck.co.nz/admin/email/handle_mail: execution expired (Net::OpenTimeout)<19>Dec 21 22:42:23 receive-mail[141]: /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
/usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
/usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
/usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
/usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
/usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
/usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
/usr/local/bin/receive-mail:13:in `<main>'Dec 21 22:42:23 forum-mail-receiver postfix/pipe[140]: 16DAC379E42: to=<nobody@forum.[domain].co.nz>, relay=discourse, delay=60, delays=0.23/0.01/0/60, dsn=4.3.0, status=deferred (temporary failure)
Dec 21 22:42:25 forum-mail-receiver postfix/smtpd[143]: disconnect from mail-oa1-f50.google.com[209.85.160.50] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
<19>Dec 21 22:42:52 receive-mail[147]: Failed to POST the e-mail to https://forum.[domain].co.nz/admin/email/handle_mail: execution expired (Net::OpenTimeout)<19>Dec 21 22:42:52 receive-mail[147]: /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
/usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
/usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
/usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
/usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
/usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
/usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
/usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
/usr/local/bin/receive-mail:13:in `<main>'Dec 21 22:42:52 forum-mail-receiver postfix/pipe[146]: 2E445379E48: to=<nobody@forum.[domain].co.nz>, relay=discourse, delay=60, delays=0.15/0.01/0/60, dsn=4.3.0, status=deferred (temporary failure)
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max connection rate 1/60s for (smtp:209.85.216.54) at Dec 21 22:41:21
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max connection count 1 for (smtp:209.85.216.54) at Dec 21 22:41:21
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max cache size 2 at Dec 21 22:41:50
Ich stecke jetzt wirklich fest, hat jemand eine Idee, was das verursachen könnte? 
Doh! Ja. Ich habe TLS und HTTPS verwechselt.
Das funktioniert immer noch überhaupt nicht, es werden keine E-Mails von mail-receiver an Discourse weitergeleitet.
Kann ich mail-receiver auf den Anfang zurücksetzen (vollständig zurücksetzen) und neu beginnen, in der Hoffnung, dass es funktioniert?
Wie kann ich das tun?
Sie können einfach die Datei bearbeiten und den Mail-Container neu erstellen.
Vielen Dank für den Tipp bezüglich der Firewall! Ich hatte auch ähnliche Probleme wie @MathiasFoster, wobei der mail-receiver-Container die Forum-Seite im app-Container nicht erreichen konnte. Zuerst etwas verwirrend, da Container problemlos auf die Außenwelt zugreifen dürfen.
Ich verwende ebenfalls Vultr als meinen VPS-Anbieter mit deren Ubuntu-Betriebssystem-Image. Eine gewisse Kombination aus den Standardeinstellungen des Betriebssystem-Images und Docker scheint die Kommunikation zwischen Containern tatsächlich zu blockieren.
Wie auch immer, in meinem Fall reichte es aus, HTTPS auf dem Host zuzulassen:
$ ufw allow https
Danach konnte der mail-receiver E-Mails wie erwartet zustellen.