Cuando utilizo la configuración de recepción de correo electrónico de entrega directa según lo indicado, termino con los siguientes errores en los registros, que incluyen tanto un fallo con LetsEncrypt como una prueba entrante a “nobody@discourse.domain.tld” desde una cuenta de 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
Mi configuración es tal que tengo otro servidor de correo en mail.domain.tld, pero Discourse se ejecuta directamente en domain.tld. discourse.domain.tld también es el nombre de host del servidor Docker que está ejecutando tanto los contenedores de Discourse como los de mail-receiver.
One thing I noticed, obviously, was that /letsencrypt/domain.tld/prop.ltcmp.net.key was missing from the contents of the folder:
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 ..
It’s interesting since this goes back to this question here by @surety that seems to have not received a direct answer.
The thread there seems to continue to discuss this point, but there’s so much chatter in that thread now that things can become confusing and thus why I’ve created a topic here (to achieve greater clarity for future users with such trouble).
It appears as though the mail-receiver.yml config’s entry POSTCONF_smtpd_tls_key_file’s value of /letsencrypt/domain.tld/prop.ltcmp.net.key must be replaced with /letsencrypt/domain.tld/domain.tld.key.
So the answer to @surety’s #1 question is “YES” this is correct to replace this entry’s contents with the one that you see. #2 also seems correct to leave as default.
I believe that perhaps either @pfaffman or @mpalmer probably should retool the container creation script to have the correct .key file instead of this (apparent wrong) prop.ltcmp.net.key entry…
At this point I am now fortunately able to move on from and past @mpalmer’s step:
You can also now try sending an e-mail to nobody@forum.example.com . While Discourse won’t do anything useful with it yet, the e-mail you sent should show up in your admin panel under “Emails”, “Rejected” in a matter of seconds. If that happens, you’re definitely ready to proceed.
Since now my test email is showing up in the Discourse /admin/email/rejected list!
I thought it was obvious that prop.ltcmp.net was a place-holder just like domain.tld.
Between the move to Debian and the new mail receiver, there could be some other changes needed. I’ll try to have a look in the next few days, as my install scripts may have been broken by these updates.
Interesting, why do you think this is obviously seen as just a placeholder? Should the acronyms be self-evident? If so, then perhaps let’s make it even more self evident with something more like: <REPLACE_THIS_WITH_LETSENCRYPT_DOT.KEY_FILE_PATH.key>
