Прямая доставка: сбой входящей почты LetsEncrypt (неверный prop.ltcmp.net.key) и невозможность доставки из-за этого?

Поддержка Самостоятельное хостинг
1

Когда я использую настройку получения почты с прямой доставкой, как описано здесь, в логах появляются следующие ошибки, включающие как проблему с Let’s Encrypt, так и входящий тестовый запрос от аккаунта Gmail на адрес “nobody@discourse.domain.tld”:

<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

Моя конфигурация такова, что у меня есть другой почтовый сервер на mail.domain.tld, но Discourse работает напрямую на domain.tld. discourse.domain.tld также является именем хоста Docker-сервера, на котором запущены контейнеры Discourse и mail-receiver.

Также у меня есть следующие MX-записи:

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

Что может быть не так в данном случае?

2

Одно, что я, очевидно, заметил, — это отсутствие файла /letsencrypt/domain.tld/prop.ltcmp.net.key в содержимом папки:

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

Это интересно, поскольку это возвращает нас к этому вопросу здесь от @surety, на который, похоже, так и не был дан прямой ответ.

Обсуждение в той теме, кажется, продолжается, но там сейчас так много шума, что всё может запутаться, поэтому я создал эту тему (чтобы обеспечить большую ясность для будущих пользователей, столкнувшихся с подобной проблемой).

Похоже, что значение POSTCONF_smtpd_tls_key_file в конфигурации mail-receiver.yml, равное /letsencrypt/domain.tld/prop.ltcmp.net.key, должно быть заменено на /letsencrypt/domain.tld/domain.tld.key.

Таким образом, ответ на первый вопрос @surety: «ДА», правильно заменить содержимое этой записи на то, которое вы видите. Второй вопрос также, кажется, верно оставить по умолчанию.

Полагаю, что, возможно, @pfaffman или @mpalmer должны доработать скрипт создания контейнера, чтобы использовать правильный файл .key вместо этой (явно ошибочной) записи prop.ltcmp.net.key.

На данный момент я, к счастью, могу перейти дальше шага @mpalmer:

Теперь вы также можете попробовать отправить электронное письмо на nobody@forum.example.com. Хотя Discourse пока ничего полезного с ним не сделает, отправленное вами письмо должно появиться в панели администратора в разделе «Электронная почта» → «Отклонённые» в течение нескольких секунд. Если это произошло, вы точно готовы продолжить.

Поскольку теперь мой тестовый email отображается в списке /admin/email/rejected в Discourse! :slight_smile:

3

Мне казалось, что очевидно: prop.ltcmp.net — это просто место-заполнитель, как и domain.tld.

В связи с переходом на Debian и внедрением нового почтового получателя могут потребоваться дополнительные изменения. Я постараюсь посмотреть на это в ближайшие дни, так как мои скрипты установки могли быть нарушены этими обновлениями.

4

Интересно, почему вы считаете, что это явно воспринимается лишь как заполнитель? Должны ли аббревиатуры быть очевидными? Если да, то, возможно, стоит сделать их ещё более понятными, используя что-то вроде: <REPLACE_THIS_WITH_LETSENCRYPT_DOT.KEY_FILE_PATH.key>.