Discourse (VPS, Docker) で Spacemail の永続的な SMTP タイムアウト問題

サポート
1

こんにちは、Discourseサポート/コミュニティ様

数日間、Discourseインスタンスからのメール送信に関する問題の解決に苦労しています。DiscourseはSpaceship VPS（フェニックス、米国）上のDockerコンテナで実行しています。メールプロバイダーはSpacemail（SMTP）です。

問題：

  • Discourseはメールを送信できません。テストメールを送信しようとするたびにタイムアウトエラーが発生します。

    • Net::ReadTimeout with #<TCPSocket:(closed)>
    • または：execution expired

  • SMTPサーバーとしてmail.spacemail.comまたはsmtp.spacemail.comのいずれを使用しても、問題は解決しません。

試したこと：

  • Spaceship/Spacemailサポートと協力して、すべてのSMTP設定（アドレス、ポート465（SSL）、ユーザー名としてのフルメールアドレス、正しいパスワード）を確認しました。
  • SMTPパスワードを複数回リセットして再入力しました。
  • Spacemailサポートに、彼らの側で制限やブロックがないことを確認しました。
  • VPSからポート465でmail.spacemail.comへのTelnet接続は成功しました（接続が開かれ、ファイアウォール問題はありません）。
  • Discourseフォーラムで推奨されているように、DockerネットワークMTUを1400に変更し、DockerとDiscourseコンテナを再起動しました。
  • Discourseアプリのdestroy/startと完全なrebuildの両方を試しました。
  • Redis、PostgreSQL、およびその他のすべてのサービスがコンテナ内で正しく実行されていることを確認しました。
  • すべてのDNSレコード（MX、SPF、DKIM）が設定され、伝播されていることを確認しました。
  • クライアント側の問題を排除するために、複数のブラウザとデバイスからテストしました。
  • 同じSpacemailアカウントを使用してGmailでメールを送受信することに成功しました（SMTPはDiscourse外で機能します）。

環境：

  • Ubuntu 22.04 VPS（Spaceship、フェニックス、米国）上のDockerで実行されているDiscourse
  • SMTPプロバイダー：Spacemail
  • SMTP設定：SSL、ポート465、mail.spacemail.com（smtp.spacemail.comも試しました）
  • すべてのDNSレコードは正しく、伝播されています。

ログ：

  • メール送信時のタイムアウトを除き、Discourseのログにエラーはありません。
  • Redisおよびその他のサービスは競合なく実行されています。
  • メール送信の試行とユニコーンワーカーのタイムアウトが一致します。

**追加情報：**本日だけで、Spacemailサポートとライブチャットでこの問題のトラブルシューティングに約7時間費やしました。彼らの努力と、すべてが正しく設定されているという確認にもかかわらず、問題は解決していません。

必要なこと：

  • 他に確認または試すべきことはありますか？
  • Discourseからより詳細なSMTPデバッグログを取得する方法はありますか？
  • Spacemailまたは他のプロバイダーで同様の問題に遭遇した人はいますか？

お時間とサポートをいただき、誠にありがとうございます！

2

公式のインストール手順に従ったか確認していただけますか？

3

はい、Docker の公式 Discourse インストール ガイドに従いました。必要であれば、私のセットアップの詳細や、VPS 環境のために行った調整について提供できます。

4

エラーログの詳細:

Discourse からメールを送信しようとすると、ジョブログに常にタイムアウトエラーが表示されます。

Job exception: Net::ReadTimeout
net-protocol-0.2.2/lib/net/protocol.rb:229:in `rbuf_fill'
net-protocol-0.2.2/lib/net/protocol.rb:199:in `readuntil'
net-protocol-0.2.2/lib/net/protocol.rb:209:in `readline'
net-smtp-0.5.1/lib/net/smtp.rb:1017:in `recv_response'
net-smtp-0.5.1/lib/net/smtp.rb:676:in `block in do_start'
net-smtp-0.5.1/lib/net/smtp.rb:1027:in `critical'
net-smtp-0.5.1/lib/net/smtp.rb:676:in `do_start'
net-smtp-0.5.1/lib/net/smtp.rb:642:in `start'
mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.8.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.8.1/lib/mail/message.rb:269:in `deliver!'
/usr/local/lib/ruby/3.3.0/delegate.rb:87:in `method_missing'
/var/www/discourse/lib/email/sender.rb:296:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:79:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:39:in `execute'
/var/www/discourse/app/jobs/base.rb:318:in `block (2 levels) in perform'
... (完全なスタックトレースはリクエストに応じて提供可能です)

説明: このエラーは、Discourse がメールを送信しようとするたびに発生します。Net::ReadTimeout は、Discourse が SMTP サーバー (Spacemail) からの応答を待っているが、時間内に受信していないことを示しています。すべてのネットワークおよび TLS テスト (openssl, telnet) は成功しており、外部クライアントでは SMTP は機能しているため、問題は Discourse の SMTP 通信または認証に固有のものであるようです。

完全なスタックトレースやその他の詳細が必要な場合は、提供できます。

5

そのVPSには全く馴染みがありません。もしセットアップの初期段階であれば、壁にぶつかり続けるよりも、新しいサーバーでやり直すことを試してみてはいかがでしょうか。それでもうまくいかない場合は、別のプロバイダーを試してみるのも良いかもしれません。

6

試したのは以下の通りです。

  1. Zap-Hosting
  2. Ultra-Host
  3. そして今回 spaceship です。DNSレコード、ドメイン、メールボックスはすべてここにあります。
7

Troubleshoot email on a new Discourse install は試されましたか？

このような苦労をさせてしまい申し訳ありません。こんなに難しいはずではありません！

8

はい、そうしました…その後、SSHコマンドで管理者アカウントを作成しました。その後、「Job exception: Net::ReadTimeout」というエラーが表示されました。

9

実施されたトラブルシューティング手順の概要:

  • 公式Dockerインストールガイドを使用して、DiscourseをSpaceship VPS（フェニックス、米国）にインストールしました。

  • SSHコマンドで管理者アカウントを作成しました。

  • SMTPをSpacemail（mail.spacemail.com、ポート465、SSL、ユーザー名としてフルメールアドレス、正しいパスワード）で設定しました。

  • SMTPパスワードを複数回リセットして再入力しました。

  • SMTPサーバーとしてmail.spacemail.comとsmtp.spacemail.comの両方を試しました。

  • Spacemailサポートに確認したところ、彼らの側で制限やブロックはないとのことです。

  • すべてのDNSレコード（MX、SPF、DKIM）が正しく、伝播していることを確認しました。

  • Gmailで同じSpacemailアカウントを使用してメールの送受信に成功しました（Discourse外ではSMTPが機能しています）。

  • VPSからtelnetとopensslを使用してSMTP接続をテストしました（TLSハンドシェイクとSMTPバナーが正常に受信されました）。

  • DockerネットワークMTUを1400に変更し、DockerとDiscourseコンテナを再起動しました。

  • コンテナ内でRedis、PostgreSQL、およびその他のすべてのサービスが正しく実行されていることを確認しました。

  • 変更ごとにDiscourseアプリのdestroy/startとフルリビルドの両方を試しました。

  • ログを確認しました。メール送信時にNet::ReadTimeoutエラーのみが発生し、その他のエラーはありませんでした。

  • Discourse管理インターフェースで「SMTPを有効にする」が有効になっていることを確認しました。

  • Spaceship/Spacemailサポートと7時間ほどライブチャットでこの問題のトラブルシューティングを行いました。

これらの手順をすべて実行したにもかかわらず、Discourseはまだメールを送信できず、常にNet::ReadTimeoutエラーが返されます。

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet ``mail.spacemail.com`` 465
Trying 198.177.121.32… Connected to ``mail.spacemail.com``.
Escape character is ‘^]’.

(app.yml) ENV:
env:LC_ALL: en_US.UTF-8LANG: en_US.UTF-8LANGUAGE: en_US.UTF-8

DISCOURSE_DEFAULT_LOCALE: en

UNICORN_WORKERS: 4

DISCOURSE_HOSTNAME: citygaming.icu

DISCOURSE_DEVELOPER_EMAILS: ‘info@citygaming.icu’

DISCOURSE_SMTP_ADDRESS: mail.spacemail.com
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: info@citygaming.icu
DISCOURSE_SMTP_PASSWORD: “” –> Im using special characters
DISCOURSE_SMTP_ENABLE_START_TLS: false
DISCOURSE_SMTP_SSL: true
DISCOURSE_SMTP_DOMAIN: citygaming.icu
DISCOURSE_NOTIFICATION_EMAIL: forum@citygaming.icu

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# openssl s_client -connect mail.spacemail.com:465
CONNECTED(00000003)
depth=2 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
verify return:1
depth=1 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
verify return:1
depth=0 CN = *.spacemail.com
verify return:1
---
Certificate chain
 0 s:CN = *.spacemail.com
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA384
   v:NotBefore: Jun 11 00:00:00 2025 GMT; NotAfter: Jun 27 23:59:59 2026 GMT
 1 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
   i:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
   a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Mar 21 23:59:59 2036 GMT
 2 s:C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication Root R46
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Mar 22 00:00:00 2021 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
 3 s:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   i:C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
   v:NotBefore: Feb  1 00:00:00 2010 GMT; NotAfter: Jan 18 23:59:59 2038 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGhzCCBO+gAwIBAgIRALFmOQOqKiGafcbqHk5JTvcwDQYJKoZIhvcNAQEMBQAw
YDELMAkGA1UEBhMCR0IxGDAWBgNVBAoTD1NlY3RpZ28gTGltaXRlZDE3MDUGA1UE
AxMuU2VjdGlnbyBQdWJsaWMgU2VydmVyIEF1dGhlbnRpY2F0aW9uIENBIERWIFIz
NjAeFw0yNTA2MTEwMDAwMDBaFw0yNjA2MjcyMzU5NTlaMBoxGDAWBgNVBAMMDyou
c3BhY2VtYWlsLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKKh
nnzi9sR4SQlEzDG0OSThJ7rj+zNyhq9KTYZtLLxSPtcI6ggnjOa0AbahjA5UXxjkT
RTWZfStyGucwK/eTL8pjU8aXl64vUFZK/jF0xiKcWFZ0J15+iqrP5zcv+yoHA9LE
OwelNDUE+c2/EDEhLbIqaIeKKxsS5aQ0JiTENfux/JbzcoI7vUsqJUsFiLCk7ane
+wc0viVE5YPTqc96VVhiuJu2IHwVSK6IsUXndbDXRQbkbwxORiX15pY83u3+uiiB
b/ZRfRILOZ29uYPsx3GH7Vqm4yJ7Iev4ueZ6z6Vd+lznH9iv8TZIWkWfxJ0oCDLm
ZMRe+DojBpAk/00+UtcCAwEAAaOCAwAwggL8MB8GA1UdIwQYMBaAFGjAEhYYDq/O
9oemMlejRlFdywcnMB0GA1UdDgQWBBS0oqCQUczn3dZIyiDOM+8KV4WqfTAOBgNV
HQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEFBQcDAQYI
KwYBBQUHAwIwSQYDVR0gBEIwQDA0BgsrBgEEAbIxAQICBzAlMCMGCCsGAQUFBwIB
FhdodHRwczovL3NlY3RpZ28uY29tL0NQUzAIBgZngQwBAgEwgYQGCCsGAQUFBwEB
BHgwdjBPBggrBgEFBQcwAoZDaHR0cDovL2NydC5zZWN0aWdvLmNvbS9TZWN0aWdv
UHVibGljU2VydmVyQXV0aGVudGljYXRpb25DQURWUjM2LmNydDAjBggrBgEFBQcw
AYYXaHR0cDovL29jc3Auc2VjdGlnby5jb20wKQYDVR0RBCIwIIIPKi5zcGFjZW1h
aWwuY29tgg1zcGFjZW1haWwuY29tMIIBfgYKKwYBBAHWeQIEAgSCAW4EggFqAWgA
dvCWl2S/VViXrfdDh2g3CEJ36fA61fak8zZuRqQ/D8qpxgAAAZdghNBMAAAEAwBH
MEUCIFwL6ylPjJme/WFO/xYNOoHIa6Qsod+6aZhCwPI1LODMAiEA+ljJB2bm4c2f
iD3IyuNzzR5cwDrgofUQZJftzXwq7W0AdgAZhtTHKKpv/roDb3gqTQGRqs4tcjEP
rs5dcEEtJUzH1AAAAZdghM+2AAAEAwBHMEUCIQCwY+9LQ8itV7FcOB5tcj9JsbL/
8oVh8ksyJP9uDfevjQIgGN/Nix3skQI2nJm6hOZDptJzt2ZkBv22ebwoFHmoGPgA
dvAOV5S8866pPjMbLJkHs/eQ35vCPXEyJd0hqSWsYcVOIQAAAZdghM9yAAAEAwBH
MEUCIDIR5KyuY2IHnP8pnEUCIKAGNFcSvEjY0Z3NIExZTL9rAiEAoMphPacQ7X1D
KACpJ06ijnzmZ2siXehW9oVOJCsd5K8wDQYJKoZIhvcNAQEMBQADggGBACbbMQWM
wFCA6UdMsFyK/5oU9O5YT7Bpo0MvhOADjGZNe37DsEMfjc4asr0Sx8VaXoPJUlV5
HKoPr13lkpG6HI6TXfFzr/uUbn6aUjMoEqjuAKTWh5leggMwXqxw7fRA8NKEpI/d
VcRiZW/I3JXvYiE2PmJawcum7pU8RuuEFyOq/9i47WkLtPyCvuMk8wkzHbxOU4ie
MYFvTvlbYoaZm9x95xAtkch3xF5MBPK9TLdgawNYrdJ4uXVYBebvx2ZSX7qr/AY8
T6AEdRtiuANfCqC0vXShDqG3hE+yeonza1ntUCKzVHvQVZTlXa12GNaxbczrw3Hd
D0tk6Xkx8K7YTq3dXoYzKYt+Lg2OFTpV13m26O9FYI5cwqI0CasiBdCvd/DpHBv/
iaPWNxLa2iyR/TSQyLkvWZmqStwrgg+dykA/nsD1fUq7X0qCmqxL2iUE9+ZZ3Mi3
JtgSj9qKdUYBSpfCX3h+8bPG5j4pretcVh7Ve81jCu1n2NwY0b9stGWx2A==
-----END CERTIFICATE-----
subject=CN = *.spacemail.com
issuer=C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 7057 bytes and written 400 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 8FACA20AB7071487B74738E7FA28813C1CA106651D80EB46D271486C67E4432B
    Session-ID-ctx:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 23 bd a5 51 88 3e 2e 7f-eb 8d 81 00 95 7a a7 8b   #..Q.>.......z..
    0010 - ce 97 c1 5e 12 02 2a 46-de d9 96 d7 06 f0 b1 47   ...^..*F.......G
    0020 - 1d 79 69 7f 8e 9d f4 4a-6a cb ec 00 42 70 d6 6b   .yi....Jj...Bp.k
    0030 - a1 37 1b 9d 61 47 4a e1-16 13 bc bb e7 ee f8 de   .7..aGJ.........
    0040 - 26 fb c1 00 b0 15 76 f0-80 a3 14 8b 10 f2 c7 ab   &.....v.........
    0050 - 5c 54 cb b3 16 e2 d2 ab-36 97 c9 82 14 1d 45 d4   \T......6.....E.
    0060 - d7 4d c0 fc 9e 77 e3 44-c8 87 16 13 3a 1f c2 02   .M...w.D....:...
    0070 - 65 03 51 14 bf ab d0 0e-51 e5 9e 95 07 ef 33 f5   e.Q.....Q.....3.
    0080 - 48 9c 89 8e d9 8e 1f ea-38 3a 21 2a c1 64 44 a8   H.......8:!*.dD.
    0090 - b2 9a 69 f2 ca fa 9e 57-12 14 36 32 fb 40 b1 06   ..i....W..62.@..
    00a0 - 9e a4 b8 21 19 90 65 f8-6d ce 2d 6f 53 e0 72 23   ...!..e.m.-oS.r#
    00b0 - 5b ca b8 f8 79 bd 07 9e-97 95 d4 d3 d5 f6 25 93   [...y.........%.
    00c0 - 33 02 71 1d 55 be 9c d3-14 32 bb 9b 4e 65 67 78   3.q.U....2..Negx

    Start Time: 1758479949
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK
220 SpaceMail.com Mail Node
「いいね！」 1
10

ポート 587 または 2525 を試してください (まず 587 を試してください)。機能しますか？ 587 は インストール ガイド に記載されているポートです。

「いいね！」 1
11

ご提案ありがとうございます。私のメールプロバイダー（Spacemail）は、SMTP用のポート465（SSL使用）のみを公式にサポートしています。ただし、トラブルシューティングの一環として（サポート担当者と協力して）、ポート587（STARTTLS使用）もテストしましたが、タイムアウトの問題は依然として発生しています。

12

先週、2つの異なるメールプロバイダーで標準インストールを2回行いましたが、機能することはわかっています。spacemailは実際のトランザクションメールには適していないと思われます。

ただし、これが機能するかどうかはわかりません。

「いいね！」 4
13

Spaceship または Spacemail 側の問題でブロックされているものはありません。昨日、サポートと 7 時間話し合った結果、必要なポートはすべて開いており、SMTP は彼らの側で機能していることが確認されました。さらなるトラブルシューティングのためにこちらに送られてきました。また、Spacemail はポート 2525 に対応していないため、代替として使用することはできません。

14

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# sudo ufw status
Status: active

To Action From

---

443/tcp ALLOW Anywhere
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere
22022/tcp ALLOW Anywhere
465/tcp ALLOW Anywhere
443/tcp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
80/tcp (v6) ALLOW Anywhere (v6)
22022/tcp (v6) ALLOW Anywhere (v6)
465/tcp (v6) ALLOW Anywhere (v6)

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse#

「いいね！」 1
15

telnet でポートにアクセスできるかどうかは既に確認済みのため、役に立つか分かりませんが、Swaks を使用してメールを送信してみてください（Ubuntu パッケージが利用可能のはずです）。メールの問題のデバッグに非常に役立つと思います。

16

Brevo や Mailgun のようなトランザクションメールサービスを試してみてはどうでしょうか？もしそれが機能するなら、代わりにそれを使用することを検討してもよいでしょう。Lilly が言ったように、私が見る限り、それがトランザクションメールサービスであるという兆候はありません。

彼らのサポートに問い合わせたところ、次のような回答がありました。

Spacemail はトランザクションメールを直接サポートしていませんが、SMTP プロトコルを使用して Spacemail メールボックスをコンタクトフォームや自動的にメールを送信するツールに接続することができます。

「いいね！」 1
17

問題は宇宙船側にあると思われます。なぜなら、GOOGLES MTPを試したところ、機能し、テストメールを受け取ったからです。
本日、この件を宇宙船の技術者に宇宙船サポート経由で転送しました。詳細が必要な場合は、直接お知らせします。

「いいね！」 2
18

これは（私の意見では）ポート465を取り巻く絶対的な混乱のために、彼らの誤ったアプローチです。

ポート465（SMTPS）は、MTA-MTA TLS通信に使用される歴史的なポートであるため、アンチスパム対策としてVPS環境で非常に頻繁にブロックされています。現在、再割り当てされてSUBMISSIONS（SUBMISSION + 暗黙のTLS）になっていますが、常にこのポートでMTA-MTAトラフィックをリッスンするMTAが存在するため、VPSプロバイダーがブロックを解除することはないと予想しています。

ポート587（SUBMISSION）は、明示的にMUA-MTAメール送信ポートであり、STARTTLSと組み合わせて認証されたメール送信に使用されるべきものです。

それでも、ポート587は情報が不十分なVPSプロバイダーによって、依然としてブロックされることがあります。

このことについての私の愚痴はさておき、あなたがそのポートに接続できることはわかっているので、VPSから、そしてコンテナからポート465経由で手動でメールを送信するとどうなりますか？

「いいね！」 2
19

@errorexee 問題は解決しましたか？

「いいね！」 1
20

このトピックは、最後の返信から14日後に自動的にクローズされました。新しい返信は許可されていません。