Direktzustellung: Eingehende E-Mails, LetsEncrypt-Fehler (prop.ltcmp.net.key ist falsch) & Nichtzustellung aufgrund davon?

Unterstützung Installation
1

Wenn ich die Einrichtung für den direkten E-Mail-Empfang gemäß dieser Anleitung verwende, erhalte ich folgende Fehler in den Logs, die sowohl ein Versagen von LetsEncrypt als auch einen eingehenden Test von einem Gmail-Konto an „nobody@discourse.domain.tld" umfassen:

<22> postfix/master[1]: daemon started -- version 3.1.1, configuration /etc/postfix
<20> postfix/smtpd[97]: warning: cannot get RSA private key from file "/letsencrypt/domain.tld/prop.ltcmp.net.key": disabling TLS support
<20> postfix/smtpd[97]: warning: TLS library problem: error:02001002:system library:fopen:No such file or directory:bss_file.c:402:fopen('/letsencrypt/domain.tld/prop.ltcmp.net.key','r'):
<20> postfix/smtpd[97]: warning: TLS library problem: error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:404:
<20> postfix/smtpd[97]: warning: TLS library problem: error:140B0002:SSL routines:SSL_CTX_use_PrivateKey_file:system lib:ssl_rsa.c:633:
<22> postfix/smtpd[97]: connect from mail-qk1-f180.google.com[209.85.222.180]
<22> postfix/smtpd[97]: lost connection after STARTTLS from mail-qk1-f180.google.com[209.85.222.180]
<22> postfix/cleanup[101]: 20A0CBCE22: message-id=<20191115221116.20A0CBCE22@discourse-mail-receiver.localdomain>
<22> postfix/qmgr[83]: 20A0CBCE22: from=<double-bounce@discourse-mail-receiver.localdomain>, size=900, nrcpt=1 (queue active)
<22> postfix/smtpd[97]: disconnect from mail-qk1-f180.google.com[209.85.222.180] ehlo=1 starttls=0/1 commands=1/2
<22> postfix/smtp[103]: 20A0CBCE22: to=<postmaster@discourse-mail-receiver.localdomain>, orig_to=<postmaster>, relay=none, delay=0.01, delays=0.01/0/0/0, dsn=5.4.4, status=bounced (Name service error for name=discourse-mail-receiver.localdomain type=AAAA: Malformed or unexpected name server reply)
<20> postfix/bounce[104]: warning: 20A0CBCE22: undeliverable postmaster notification discarded
<22> postfix/qmgr[83]: 20A0CBCE22: removed

Meine Konfiguration ist so gestaltet, dass ich zwar einen weiteren Mailserver auf mail.domain.tld habe, Discourse jedoch direkt unter domain.tld läuft. discourse.domain.tld ist zudem der Hostname des Docker-Servers, auf dem sowohl die Discourse- als auch die mail-receiver-Container laufen.

Ich habe außerdem folgende MX-Einträge:

domain.tld > mail.domain.tld            priority: 10
d > discourse.domain.tld                priority: 20
domain.tld > discourse.domain.tld       priority: 30

Was könnte hier schiefgehen?

2

Eine Sache, die mir natürlich aufgefallen ist, war, dass /letsencrypt/domain.tld/prop.ltcmp.net.key im Inhalt des Ordners fehlte:

discourse-mail-receiver:/# ls -tlrha letsencrypt/domain.tld
total 40
-rw-r--r--    1 root     root        3.2K Nov 10 05:10 domain.tld.key
-rw-r--r--    1 root     root         208 Nov 10 05:10 domain.tld.csr.conf
-rw-r--r--    1 root     root        1.6K Nov 10 05:10 domain.tld.csr
-rw-r--r--    1 root     root        2.2K Nov 10 05:10 domain.tld.cer
-rw-r--r--    1 root     root        3.8K Nov 10 05:10 fullchain.cer
-rw-r--r--    1 root     root        1.6K Nov 10 05:10 ca.cer
drwxr-xr-x    3 root     root        4.0K Nov 10 05:10 .
-rw-r--r--    1 root     root         799 Nov 11 15:56 domain.tld.conf
drwxr-xr-x    2 root     root        4.0K Nov 11 27 15:56 backup
drwxr-xr-x    8 root     root        4.0K Nov 16 00:49 ..

Das ist interessant, da dies auf diese Frage hier von @surety zurückgeht, die anscheinend keine direkte Antwort erhalten hat.

Der Thread scheint zwar weiterhin diesen Punkt zu diskutieren, aber dort ist mittlerweile so viel Diskussion im Gange, dass es verwirrend werden kann. Daher habe ich hier ein neues Thema erstellt (um zukünftigen Nutzern mit ähnlichen Problemen mehr Klarheit zu verschaffen).

Es scheint, als müsste der Eintrag POSTCONF_smtpd_tls_key_file in der mail-receiver.yml-Konfiguration mit dem Wert /letsencrypt/domain.tld/prop.ltcmp.net.key durch /letsencrypt/domain.tld/domain.tld.key ersetzt werden.

Die Antwort auf @suretys Frage #1 lautet also „JA“, es ist korrekt, den Inhalt dieses Eintrags durch den zu ersetzen, den Sie sehen. Bei #2 scheint es ebenfalls korrekt, den Standardwert beizubehalten.

Ich vermute, dass entweder @pfaffman oder @mpalmer das Skript zur Container-Erstellung entsprechend anpassen sollte, um die korrekte .key-Datei zu verwenden, anstatt diesen (offensichtlich falschen) Eintrag prop.ltcmp.net.key…

An diesem Punkt kann ich mich nun glücklicherweise von @mpalmers Schritt:

Sie können nun auch versuchen, eine E-Mail an nobody@forum.example.com zu senden. Obwohl Discourse damit noch nichts Nützliches anfangen kann, sollte die von Ihnen gesendete E-Mail innerhalb weniger Sekunden unter „E-Mails“ → „Abgelehnt“ in Ihrem Admin-Bereich erscheinen. Wenn das passiert, sind Sie auf jeden Fall bereit, fortzufahren.

hinter mich gebracht, da meine Test-E-Mail nun in der Discourse-Liste /admin/email/rejected erscheint! :slight_smile:

3

Ich dachte, es sei offensichtlich, dass prop.ltcmp.net nur ein Platzhalter ist, genau wie domain.tld.

Durch den Umzug auf Debian und den neuen Mail-Empfänger könnten weitere Änderungen erforderlich sein. Ich werde versuchen, in den nächsten Tagen einen Blick darauf zu werfen, da meine Installations-Skripte durch diese Updates möglicherweise beschädigt wurden.

4

Interessant, warum denkst du, dass dies offensichtlich nur als Platzhalter angesehen wird? Sollten die Akronyme selbsterklärend sein? Wenn ja, dann machen wir es vielleicht noch offensichtlicher, mit etwas wie: <ERSETZE_DIES_DURCH_LETSENCRYPT_DOT.KEY_FILE_PATH.key>