Требуется помощь: застрял на отладке конфигурации почты (Infomaniak/Brevo)

Привет!

Я устанавливаю Discourse для нашей небольшой некоммерческой ассоциации. Я выбрал облачный экземпляр Ubuntu 22.04 в публичном облаке от Infomaniak и настроил отправку транзакционных писем через Brevo, так как у них есть бесплатный тариф с лимитом 300 писем в месяц.

Я последовательно решил несколько проблем при настройке сервера, и документация, а также сообщения здесь, очень помогли мне…

НО
Теперь я зашел в тупик и не знаю, как двигаться дальше.

  1. Мой экземпляр доступен по нашему поддомену forum.aether-labs.fr.

  2. Мой аккаунт в Brevo работает корректно: мне удалось отправить письма с адреса noreply@forum.aether-labs.fr через Thunderbird.

  3. Но я не получаю первое письмо администратора для подтверждения аккаунта.

Поэтому я внимательно прочитал пост Устранение неполадок с почтой при новой установке Discourse (ссылку не могу дать из-за правил для новых пользователей) и попробовал различные решения.

  1. Контейнер приложения, похоже, успешно подключается к SMTP-серверу Brevo (порт открыт).
root@server-1:/var/discourse# 
root@server-1:/var/discourse# ./launcher enter app
x86_64 arch detected.
root@server-1-app:/var/www/discourse# 
root@server-1-app:/var/www/discourse# openssl s_client -connect smtp-relay.sendinblue.com:587 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
---
Certificate chain
 0 s:CN = *.sendinblue.com
   i:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
 1 s:C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
 2 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   i:C = GB, ST = Greater Manchester, L = Salford, O = Comodo CA Limited, CN = AAA Certificate Services
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGODCCBSCgAwIBAgIQf3BN6DJXk+R4MhMClPwXSzANBgkqhkiG9w0BAQsFADCB
jzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEYMBYGA1UEChMPU2VjdGlnbyBMaW1pdGVkMTcwNQYDVQQD
Ey5TZWN0aWdvIFJTQSBEb21haW4gVmFsaWRhdGlvbiBTZWN1cmUgU2VydmVyIENB
MB4XDTIyMTIwMTAwMDAwMFoXDTIzMTIxMzIzNTk1OVowGzEZMBcGA1UEAwwQKi5z
ZW5kaW5ibHVlLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKym
RK7t+EAo9Vtl+7laiPy2QTvaxT7WLrLGNGzSzorOBTKkjpjEOveSaa9SMav+qX/T
n4Q/eVQdjggQqFrUAYAN7aXa83K9zYMrSAzsPzg/k3O5iXl3GC5KT3yF9IzNNso0
oljczFaYDdhLr6iovk03DXQB0hMmfX3RLJyqYmyGEshoJwSAMTfW06Iob25JFVG7
tKngYEQMx/IC/WsFKuJ8t2AKaK7xZyEklQqJ95j9lzbfP27VNIkfcZ3DjMDK3shL
xgkpsys8LiH5P1MUAEq4fmOE9IIkewGYMAuKSRyzH1DdgeDvMW8RYcVwGmAfEjQ4
W/515j9q6f1OLQPK1zUCAwEAAaOCAwEwggL9MB8GA1UdIwQYMBaAFI2MXsRUrYrh
d+mb+ZsF4bgBjWHhMB0GA1UdDgQWBBQt3X5DvoJzqs7qZ1t/7m1fRPcJGTAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIB
FhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEB
BHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdv
UlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEFBQcw
AYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wKwYDVR0RBCQwIoIQKi5zZW5kaW5i
bHVlLmNvbYIOc2VuZGluYmx1ZS5jb20wggF9BgorBgEEAdZ5AgQCBIIBbQSCAWkB
ZwB1AK33vvp8/xDIi509nB4+GGq0Zyldz7EMJMqFhjTr3IKKAAABhM6AGCkAAAQD
AEYwRAIgLXDREGRQg02jNvL1Vvuwmbc8G1OpnwgHOsWKB/Gi5hQCIEmjtO9/O9DQ
nBNawCpH/ppW57f49W90ecV0Ng2qHWs9AHcAejKMVNi3LbYg6jjgUh7phBZwMhOF
TTvSK8E6V6NS61IAAAGEzoAX8gAABAMASDBGAiEAzTTpiWsKzHjVN7czz0Iw+TW8
17jAlGb8/LvgNuyb+yoCIQD4W8vpQd7aoLwFL1ZuuEh3zhrDL/iNa1FbnPTXrCSx
hQB1AOg+0No+9QY1MudXKLyJa8kD08vREWvs62nhd31tBr1uAAABhM6AF8EAAAQD
AEYwRAIgaLYUtDrQms9/CbKsZIsJ0ootg6Swnori9rmkiQlZklwCICerSmuiXVAg
thR3zAcjsEd4o1hXgMjEjM3ct4T1WDLdMA0GCSqGSIb3DQEBCwUAA4IBAQC+X/Us
keEDvt4AG0j9CgcP+QrZliJMsKNz7YR8Mt+NJiXr69Kg/hZNvw5aToCgjgbPlzPj
cs4i/6plivGmBsH94qIcl+PbHm1wJFSodDvahKuP0xZbBcynel9cIeCLRfYLr8nI
qJnB7sqK3Fpda98EY4x5kYbbiKJ2CaMABD8WZBEbJglTY3cmZkpI6m76sEgrlVm+
O+jp2fw7cFda+vzUmBmd8z1i7dZbB7Oj4Wy/SjT0SPbousz7JXXBh2YDiIzLBfvt
8mhjeQmLZMCnvL74zxFfuB44v4X0SIfQPjSgZy8vTYYMrSn40pzLbL1np7t+jpEb
ratD0fgmtozDRDWw
-----END CERTIFICATE-----
subject=CN = *.sendinblue.com

issuer=C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA

---
No client certificate CA names sent
Peer signing digest: SHA512
Peer signature type: RSA
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5482 bytes and written 476 bytes
Verification: OK
---
New, TLSv1.2, Cipher is ECDHE-RSA-AES128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES128-GCM-SHA256
    Session-ID: FF96A2562FFDC00C5948FE7E6123CE9CD4CFB4939A4546728F60584ED2EC12EB
    Session-ID-ctx: 
    Master-Key: 287A2ECAB44E3F1EB919B4AD0EF98981A05F866381485781BB46AFEA2F361E987C31E57DA1098B01F69B75679E07E430
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 300 (seconds)
    TLS session ticket:
    0000 - 6d 30 ab bf 0a 44 79 06-0a 1a 67 1a 25 b5 f8 05   m0...Dy...g.%...
    0010 - 8e 33 6c 9a db 35 cd 9e-64 d6 a3 44 59 36 d4 e1   .3l..5..d..DY6..
    0020 - 69 b2 46 6a d5 7a 22 25-c2 36 bd bc ef ca d8 bf   i.Fj.z"%.6......
    0030 - 1c e2 b5 31 4e ab 43 cf-ea a0 1a b8 39 69 cd 5c   ...1N.C.....9i.\
    0040 - 15 b5 94 17 9c 70 d0 9d-ff 7c 7f e9 3f c8 87 a2   .....p...|..?...
    0050 - d0 12 5d a2 2b 6c e3 54-aa 33 10 fa b5 08 57 9f   ..].+l.T.3....W.
    0060 - 64 ce cc 08 53 24 f1 5c-4f 6b 4c 19 f1 f8 83 be   d...S$.\OkL.....
    0070 - 97 11 17 3f 83 5f 9f 9c-16 73 86 98 c8 d6 72 a8   ...?._...s....r.
    0080 - 44 7a bd 43 e3 40 44 a5-f4 6d 7f 36 19 e4 f3 84   Dz.C.@D..m.6....
    0090 - ec 3f 0b 65 0c 53 ef 73-ef 43 19 8c 34 27 87 40   .?.e.S.s.C..4'.@
    00a0 - 7e 52 5f 6f 7a 2d e6 08-a6 fc 6f 77 a9 47 f3 fa   ~R_oz-....ow.G..
    00b0 - eb 56 ac 1d f0 42 de 45-37 22 ec 5e 13 48 09 41   .V...B.E7".^.H.A

    Start Time: 1700936536
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---
250 STARTTLS
^C
root@server-1-app:/var/www/discourse# 
root@server-1-app:/var/www/discourse# 

Последняя строка лога — 250 STARTTLS вместо 250 DSN, указанной в предыдущем посте, но для меня, как для неспециалиста, это выглядит нормально.

  1. Однако утилита discourse-doctor не может отправить письмо и сообщает, что порт закрыт (я пробовал порты 587, 2525 и 465 без STARTTLS).
==================== MAIL TEST ====================
Для надежного теста получите адрес на http://www.mail-tester.com/
Или просто отправьте тестовое сообщение себе.
Email адрес для теста почты? ('n' чтобы пропустить) [contact@aether-labs.fr]: test-f2ps9wb2f@srv1.mail-tester.com
Отправка письма на test-f2ps9wb2f@srv1.mail-tester.com. . . 
Тестирование отправки на test-f2ps9wb2f@srv1.mail-tester.com через smtp-relay.sendinblue.com:587, имя пользователя: forum@aether-labs.fr с простой аутентификацией.
======================================== ОШИБКА ========================================
Соединение с портом 587 не удалось.
====================================== РЕШЕНИЕ =======================================
Наиболее вероятная проблема — исходящий SMTP-трафик заблокирован на вашем сервере.
Если вы используете сервис вроде Mailgun или Sendgrid, попробуйте порт 2525.
=======================================================================================

Поскольку согласно пункту (4) исходящий SMTP-трафик, похоже, не заблокирован, я не знаю, как продолжить и какие конфигурационные изменения внести, чтобы правильно настроить транзакционную почту.

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

Спасибо, @pfaffman!
Я только что отправил им письмо.

Но тот факт, что

openssl s_client -connect smtp-relay.sendinblue.com:587 -starttls smtp

работает, странно. Если я указываю smtp-relay.sendinblue.com:586, результата нет. Значит, я предполагаю, что трафик не заблокирован, верно? То есть пакеты действительно доходят до smtp-relay.sendinblue.com:587, если есть ответы…

Итак, поддержка сообщила мне, что с конфигурацией всё в порядке, а исходящие порты не заблокированы.

Тогда я попробовал отправить письмо полностью через openssl, и да, мне удалось отправить письмо изнутри Docker-контейнера.

root@server-1-app:/var/www/discourse#  openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587

EHLO jai
AUTH PLAIN
AGZvcnVtQGFldGhlci1sYWJ... # удалено ради безопасности
mail from: noreply@forum.aether-labs.fr
rcpt to: test-j0erqjxm2@srv1.mail-tester.com
data
subject: test smtp from inside


ok
.

… но команда discourse-doctor по-прежнему сообщает, что подключение к smtp-relay.sendinblue.com:587 не удалось.

Поэтому я изучил скрипт discourse-doctor и увидел, что проверка связана с задачей Rake под названием emails:test, которую я нашёл в файле lib/tasks/emails.rake. Там выяснилось, что такое сообщение появляется, когда истекает время выполнения.

Есть ли возможность изменить значение таймаута, прежде чем выполнение считается истёкшим?

Редактирование: хорошо, если я отредактирую файл app/services/email_settings_validator.rb и вручную установлю таймаут на 30 секунд, то подключение будет успешным, но отправка письма всё равно не удастся (это связано с TestMailer, я полагаю, что увеличивать этот параметр нельзя…)

root@server-1-app:/var/www/discourse# rake emails:test[test-j0erqjxm2@srv1.mail-tester.com]
Testing sending to test-j0erqjxm2@srv1.mail-tester.com using smtp-relay.sendinblue.com:587, username:forum@aether-labs.fr with plain auth.
SMTP server connection successful.
Sending to test-j0erqjxm2@srv1.mail-tester.com. . . 
Sending mail failed.
execution expired

Поскольку в данном случае я работаю на минимальных требованиях Discourse (1 виртуальное ядро + 2 ГБ ОЗУ), я также могу попробовать перейти на более мощную конфигурацию (например, 2 виртуальных ядра + 4 ГБ ОЗУ).

Указано ли в переменной окружения:

DISCOURSE_SMTP_ENABLE_START_TLS: true

Это значение по умолчанию, поэтому оно вам, скорее всего, не нужно, но возможно, вы его отключили?

Да, оно установлено в true!
(Я отредактировал своё предыдущее сообщение, добавив результаты эксперимента с тайм-аутами…)

Сколько времени занимает команда openssl для подключения и согласования TLS?

почти 10 секунд

real	0m9.798s
user	0m0.007s
sys	0m0.010s

Вау, это невероятно долгое время.

Занимает ли это столько же времени на хост-системе?

Я только что провёл тест
~10 секунд из Docker
<1 секунда с хоста (безусловно, это время, за которое я нажимаю Ctrl+D, чтобы остановить; это действительно почти мгновенно)

Это разумно.

Похоже, у вас есть фундаментальная проблема с сетевым взаимодействием контейнеров… эти две команды должны выполняться за одинаковое время:

(с хоста):point_down:t3:

○ → time openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587 </dev/null > /dev/null
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
250 STARTTLS
DONE

real	0m0.277s
user	0m0.007s
sys	0m0.011s

(через docker):point_down:t3:

○ → docker run --rm discourse/base:2.0.20231023-1945 bash -c 'time openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587 </dev/null' > /dev/null
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
250 STARTTLS
DONE

real	0m0.239s
user	0m0.006s
sys	0m0.000s

Это не так :sob:

root@server-1:/var/discourse# time openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587 < /dev/null > /dev/null
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
250 STARTTLS
DONE

real	0m0.126s
user	0m0.003s
sys	0m0.007s
root@server-1:/var/discourse# docker run --rm discourse/base:2.0.20231023-1945 bash -c 'time openssl s_client -starttls smtp -connect smtp-relay.sendinblue.com:587 < /dev/null' > /dev/null
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1
depth=0 CN = *.sendinblue.com
verify return:1
250 STARTTLS
DONE

real	0m8.125s
user	0m0.007s
sys	0m0.000s

… мне стоит удалить и переустановить Docker?
Я выполнял только команды apt и использовал настройки по умолчанию от docker-ce, поэтому не понимаю, что может быть не так…

Единственное изменение, которое я внёс, — добавил DNS, как было предложено в другом посте, потому что сначала у меня возникали ошибки «unknown host».

root@server-1:/var/discourse# cat /etc/docker/daemon.json
{
  "dns": ["83.166.143.51", "83.166.143.52", "8.8.8.8"]
}

Отлично, всё работает!

Я изменил свой файл /etc/docker/daemon.json, чтобы Google (8.8.8.8) стоял первым, а не последним, и получил приемлемое время отклика для STARTTLS… и discourse-doctor успешно отправил письма :slight_smile:

Огромное спасибо за ваше время, @supermathie и @pfaffman!

Я добавлю заметку в другой пост, чтобы указать, что Google должен быть первым в списке!

Не все рекомендации подходят для всех случаев. В этом и кроется опасность слепого следования чужим советам только потому, что они сработали у кого-то другого.

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