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

**URL:** https://meta.discourse.org/t/direct-delivery-incoming-mail-letsencrypt-failure-prop-ltcmp-net-key-is-wrong-nondelivery-due-to-this/133525
**Category:** Self-hosting
**Tags:** email
**Created:** [15. November 2019 um 23:01 UTC](https://meta.discourse.org/t/direct-delivery-incoming-mail-letsencrypt-failure-prop-ltcmp-net-key-is-wrong-nondelivery-due-to-this/133525 "2019-11-15T23:01:14Z")
**Posts on this page:** 5
**Page:** 1

<div class="post-metadata">

### Author: ![mreach](https://avatars.discourse-cdn.com/v4/letter/m/9d8465/32.png) [@mreach](https://meta.discourse.org/u/mreach)
#### Post date: [15. November 2019 um 23:01 UTC](https://meta.discourse.org/t/direct-delivery-incoming-mail-letsencrypt-failure-prop-ltcmp-net-key-is-wrong-nondelivery-due-to-this/133525/1 "2019-11-15T23:01:15Z")

</div>

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:

```plaintext
<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:

```plaintext
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?

---

<div class="post-metadata">

### Author: ![mreach](https://avatars.discourse-cdn.com/v4/letter/m/9d8465/32.png) [@mreach](https://meta.discourse.org/u/mreach)
#### Post date: [16. November 2019 um 15:55 UTC](https://meta.discourse.org/t/direct-delivery-incoming-mail-letsencrypt-failure-prop-ltcmp-net-key-is-wrong-nondelivery-due-to-this/133525/2 "2019-11-16T15:55:35Z")

</div>

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

```plaintext
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](https://meta.discourse.org/t/straightforward-direct-delivery-incoming-mail/49487/195?u=mreach) 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! 🙂

---

<div class="post-metadata">

### Author: ![pfaffman](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/pfaffman/32/120154_2.png) [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [16. November 2019 um 18:49 UTC](https://meta.discourse.org/t/direct-delivery-incoming-mail-letsencrypt-failure-prop-ltcmp-net-key-is-wrong-nondelivery-due-to-this/133525/3 "2019-11-16T18:49:36Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![mreach](https://avatars.discourse-cdn.com/v4/letter/m/9d8465/32.png) [@mreach](https://meta.discourse.org/u/mreach)
#### Post date: [16. November 2019 um 19:30 UTC](https://meta.discourse.org/t/direct-delivery-incoming-mail-letsencrypt-failure-prop-ltcmp-net-key-is-wrong-nondelivery-due-to-this/133525/4 "2019-11-16T19:30:00Z")

</div>

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>`

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [16. Dezember 2019 um 19:35 UTC](https://meta.discourse.org/t/direct-delivery-incoming-mail-letsencrypt-failure-prop-ltcmp-net-key-is-wrong-nondelivery-due-to-this/133525/5 "2019-12-16T19:35:48Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
