Livraison directe : échec de la réception du courrier LetsEncrypt (prop.ltcmp.net.key est incorrect) et non-livraison due à cela ?

Soutien Installation
1

Lorsque j’utilise la configuration de réception d’e-mails en livraison directe comme indiqué ici, je rencontre les erreurs suivantes dans les journaux, qui incluent à la fois un échec avec LetsEncrypt et un test entrant vers “nobody@discourse.domain.tld” depuis un compte Gmail :

<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

Ma configuration est telle que j’ai un autre serveur de messagerie sur mail.domain.tld, mais Discourse s’exécute directement sur domain.tld. discourse.domain.tld est également le nom d’hôte du serveur Docker qui exécute à la fois Discourse et les conteneurs mail-receiver.

J’ai également les enregistrements MX suivants :

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

Quel pourrait être le problème ici ?

2

Une chose que j’ai remarquée, évidemment, était que /letsencrypt/domain.tld/prop.ltcmp.net.key manquait dans le contenu du dossier :

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

C’est intéressant car cela remonte à cette question ici posée par @surety, qui semble n’avoir reçu aucune réponse directe.

Le fil de discussion continue d’aborder ce point, mais il y a tellement de bavardages à présent que les choses peuvent devenir confuses. C’est pourquoi j’ai créé ce sujet ici (pour offrir plus de clarté aux futurs utilisateurs rencontrant ce problème).

Il semble que la valeur de l’entrée POSTCONF_smtpd_tls_key_file dans le fichier de configuration mail-receiver.yml, à savoir /letsencrypt/domain.tld/prop.ltcmp.net.key, doive être remplacée par /letsencrypt/domain.tld/domain.tld.key.

Ainsi, la réponse à la question n°1 de @surety est « OUI », il est correct de remplacer le contenu de cette entrée par celui que vous voyez. La question n°2 semble également correcte à laisser par défaut.

Je pense que @pfaffman ou @mpalmer devraient peut-être retravailler le script de création du conteneur pour utiliser le bon fichier .key au lieu de cette entrée (apparemment erronée) prop.ltcmp.net.key…

À ce stade, je suis désormais heureusement en mesure de passer à l’étape suivante de @mpalmer :

Vous pouvez également essayer d’envoyer un e-mail à nobody@forum.example.com. Bien que Discourse ne fasse rien d’utile avec pour l’instant, l’e-mail que vous avez envoyé devrait apparaître dans votre panneau d’administration sous « Emails », « Rejetés » en quelques secondes. Si cela se produit, vous êtes définitivement prêt à continuer.

Mon e-mail de test apparaît maintenant dans la liste /admin/email/rejected de Discourse ! :slight_smile:

3

Je pensais qu’il était évident que prop.ltcmp.net était un simple espace réservé, tout comme domain.tld.

Entre la migration vers Debian et le nouveau récepteur de courriel, d’autres modifications pourraient être nécessaires. Je vais essayer de jeter un coup d’œil dans les prochains jours, car mes scripts d’installation ont peut-être été perturbés par ces mises à jour.

4

Intéressant, pourquoi pensez-vous que cela soit considéré comme évidemment un simple espace réservé ? Les acronymes devraient-ils être évidents par eux-mêmes ? Si tel est le cas, alors rendons-le peut-être encore plus explicite avec quelque chose comme : <REPLACE_THIS_WITH_LETSENCRYPT_DOT.KEY_FILE_PATH.key>