ヘルプが必要です。メール設定のデバッグ（Infomaniak/Brevo）で詰まっています

jaileleu · 2023 年 11 月 25 日午後 7:07

こんにちは！

私たちの小さな非営利団体のためにディスコースをインストールしています。InfomaniakのPublic CloudでUbuntu 22.04のクラウドインスタンスを選択し、トランザクションメールはBrevoを使用することにしました。Brevoは無料プランで月300通のメールが利用できるためです。

サーバーの設定で、一つずついくつかの問題に直面しましたが、ドキュメントやここの投稿が大変役立ちました…。

しかし、
今、どう進めばいいかわからない段階に達しました。

インスタンスは、フォーラムのサブドメイン forum.aether-labs.fr からアクセス可能です。
Brevoのアカウントは正常に機能しており、noreply@forum.aether-labs.fr から Thunderbird でメールを送信することに成功しました。

image1233×872 66 KB
しかし、アカウントを検証するための最初のアドミンメールが届きません。

そこで、投稿「Troubleshoot email on a new Discourse install」（新規ユーザーのルールのためリンクはありません）を詳細に読み、試してみました。

アプリコンテナは、BrevoのSMTPサーバーポートに到達できているようです（？）。

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:1depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Domain Validation Secure Server CA
verify return:1depth=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
HR8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIB
FhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEB
BHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdv
UlNBRG9tYWluVmFsaWRhdGlvblNlY3VyZVNlcnZlckNBLmNydDAjBggrBgEFBQcw
AYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wKwYDVR0RBCQwIoIQKi5zZW5kaW5i
bHVlLmNvbTIOc2VuZGluYmx1ZS5jb20wggF9BgorBgEEAdZ5AgQCBIIBbQSCAWkB
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 DSN の代わりに 250 STARTTLS で、素人の私には問題なさそうです。

しかし、discourse-doctor はメールを送信できず、ポートが閉じていると表示されます（starttlsなしで587、2525、465を試しました）。

==================== MAIL TEST ====================
For a robust test, get an address from http://www.mail-tester.com/
Or just send a test message to yourself.
Email address for mail test? ('n' to skip) [contact@aether-labs.fr]: test-f2ps9wb2f@srv1.mail-tester.com
Sending mail to test-f2ps9wb2f@srv1.mail-tester.com. . .
Testing sending to test-f2ps9wb2f@srv1.mail-tester.com using smtp-relay.sendinblue.com:587, username:forum@aether-labs.fr with plain auth.
======================================== ERROR ========================================
Connection to port 587 failed.
====================================== SOLUTION =======================================
The most likely problem is that your server has outgoing SMTP traffic blocked.
If you are using a service like Mailgun or Sendgrid, try using port 2525.
=======================================================================================

したがって、（4）から、送信SMTPトラフィックはブロックされていないように見えるため、どのように進め、トランザクションメールの正しい設定のためにどの設定を変更すればよいかわかりません。

pfaffman · 2023 年 11 月 26 日午前 2:13

送信ポートがブロックされていないか、VMのプロバイダーに確認することをお勧めします。

jaileleu · 2023 年 11 月 26 日午後 12:22

@pfaffman さん、ありがとうございます！
メールを送りました。

しかし、

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

が機能するのは奇妙です。smtp-relay.sendinblue.com:586 にすると結果が得られないため、トラフィックはブロックされていないと推測できますよね？つまり、応答があるということは、パケットは smtp-relay.sendinblue.com:587 に到達しているということです…

jaileleu · 2023 年 11 月 29 日午後 8:43

サポート担当者からは、設定はすべて問題なく、送信ポートもブロックされていないとのことでした。

そこで、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 スクリプトを読み、テストが lib/tasks/emails.rake にある emails:test という 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]
smtp-relay.sendinblue.com:587、ユーザー名:forum@aether-labs.fr、プレーン認証を使用して test-j0erqjxm2@srv1.mail-tester.com への送信をテストしています。
SMTP サーバー接続成功。
test-j0erqjxm2@srv1.mail-tester.com への送信中。 . .
メール送信失敗。
実行が期限切れ

このインスタンスでは Discourse の最小要件（1 VCPU + 2GB RAM）に本当に近い状態なので、より良いもの（2 VCPU + 4GB RAM など）にアップグレードすることも試してみるかもしれません。

supermathie · 2023 年 11 月 29 日午後 9:17

環境変数に以下を設定していますか？

DISCOURSE_SMTP_ENABLE_START_TLS: true

これはデフォルトなので、通常は必要ありませんが、無効にしていませんか？

jaileleu · 2023 年 11 月 29 日午後 9:19

trueに設定されています。！
（タイムアウトの実験結果を前のメッセージに追記しました…）

supermathie · 2023 年 11 月 29 日午後 9:20

openssl コマンドは、TLS 接続とネゴシエーションにどのくらいの時間がかかりますか？

jaileleu · 2023 年 11 月 29 日午後 10:17

約10秒

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

supermathie · 2023 年 11 月 29 日午後 10:55

すごい、それはとてつもなく長い時間ですね。

ホストシステムからも同じ時間がかかりますか？

jaileleu · 2023 年 11 月 29 日午後 10:56

テストを実行しました。
Dockerからは約10秒
ホストからは1秒未満（間違いなく私がCtrl+Dを押して停止するまでの時間で、本当にほぼ瞬時です）

supermathie · 2023 年 11 月 29 日午後 11:02

これは妥当です。

コンテナのネットワーキングに根本的な問題があるようです…これらの2つのコマンドは同じくらいの時間がかかるはずです。

（ホストから）

○ → 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経由）

○ → 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

jaileleu · 2023 年 11 月 29 日午後 11:04

それは違います

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 を追加したことです。

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

jaileleu · 2023 年 11 月 29 日午後 11:24

OK、動作しました！

/etc/docker/daemon.json を変更し、Google (8.8.8.8) を最後にではなく最初に設定したところ、STARTTLS の応答時間が改善され、discourse-doctor が正常にメールを送信できるようになりました

@supermathie と @pfaffman、お時間をいただきありがとうございました。

Google をリストの最初に置くべきである旨を、他の投稿にも追記します！

supermathie · 2023 年 11 月 29 日午後 11:26

すべての提案がすべてのケースに当てはまるわけではありません。それは、誰かがうまくいったからといって、そのアドバイスをそのまま採用することの危険性でもあります。

あなたのケースでは、ISPが提供するものよりもGoogleのネームサーバーの方が信頼性が高いようですので、それらを使用する必要があります。

system · 2023 年 12 月 29 日午後 11:27

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

トピック		返信	表示
SMTP Mails don't send and connection fails, but openssl works Support	9	321	2024 年 11 月 20 日
Discourse with other websites, SMTP issue: End of file reached Installation	8	2340	2020 年 10 月 22 日
Troubleshoot email on a new Discourse install Self-Hosting email , configuring , how-to	35	179206	2025 年 10 月 16 日
Email not working (SSL_connect returned=1) Installation	16	2507	2022 年 7 月 15 日
Mail test failure in discourse-doctor Support email	18	190	2025 年 3 月 13 日

ヘルプが必要です。メール設定のデバッグ（Infomaniak/Brevo）で詰まっています

関連トピック