Spacemail 在 Discourse 上持续出现 SMTP 超时问题（VPS，Docker）

[errorexee (Error.EXE)]

您好，Discourse 支持/社区，

几天来，我一直在努力解决我的 Discourse 实例发件问题。我在 Spaceship VPS（凤凰城，美国）上使用 Docker 容器运行 Discourse。我的邮件提供商是 Spacemail (SMTP)。

问题：

• Discourse 无法发送电子邮件。每次尝试发送测试邮件都会导致超时错误：
  • Net::ReadTimeout with #<TCPSocket:(closed)>
  • 或者：execution expired
• 无论我使用 mail.spacemail.com 还是 smtp.spacemail.com 作为 SMTP 服务器，问题都依然存在。

我已尝试的操作：

• 与 Spaceship/Spacemail 支持人员一起验证了所有 SMTP 设置（地址、端口 465 用于 SSL、完整的电子邮件作为用户名、正确的密码）。
• 多次重置并重新输入了 SMTP 密码。
• 已与 Spacemail 支持人员确认，他们那边没有任何限制或阻止。
• 从 VPS 到 mail.spacemail.com 的 465 端口的 Telnet 连接成功（连接打开，没有防火墙问题）。
• 按照 Discourse 论坛的建议，将 Docker 网络 MTU 更改为 1400，并重新启动了 Docker 和 Discourse 容器。
• 尝试了 Discourse 应用的 destroy/start 和完整的 rebuild。
• 确认容器内的 Redis、PostgreSQL 和所有其他服务都在正常运行。
• 验证了所有 DNS 记录（MX、SPF、DKIM）都已设置并已传播。
• 尝试从多个浏览器和设备发送，以排除客户端问题。
• 使用相同的 Spacemail 帐户在 Gmail 中成功发送和接收了电子邮件（SMTP 在 Discourse 之外正常工作）。

环境：

• Discourse 在 Ubuntu 22.04 VPS（Spaceship，凤凰城，美国）上通过 Docker 运行
• SMTP 提供商：Spacemail
• SMTP 设置：SSL，端口 465，mail.spacemail.com（也尝试过 smtp.spacemail.com）
• 所有 DNS 记录都正确且已传播

日志：

• Discourse 日志中除了发送邮件时的超时外，没有其他错误。
• Redis 和其他服务运行正常，没有冲突。
• Unicorn 工作进程超时与电子邮件发送尝试同时发生。

其他背景信息： 今天，我花了大约 7 个小时通过实时聊天与 Spacemail 支持人员一起排查此问题。尽管他们付出了努力并确认他们那边一切设置正确，但问题依然存在。

我需要：

• 关于还需要检查或尝试什么的任何建议？
• 是否有办法从 Discourse 获取更详细的 SMTP 调试日志？
• 是否有人遇到过与 Spacemail 或其他提供商类似的问​​题？

非常感谢您的时间和支持！

[tobiaseigen]

您能确认您是否遵循了官方安装指南吗？

[errorexee (Error.EXE)]

是的，我遵循了官方的 Discourse Docker 安装指南。如果需要，我可以提供我的设置详情或为我的 VPS 环境所做的任何调整。

[errorexee (Error.EXE)]

错误日志详情：

当我尝试从 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 通信或身份验证。

如果您需要完整的堆栈跟踪或更多详细信息，我可以提供。

[tobiaseigen]

我完全不熟悉那个vps。如果你刚开始设置，可以尝试从新服务器开始，而不是继续碰壁。如果仍然不行，可以试试别的提供商。

[errorexee (Error.EXE)]

我试过：

1. Zap-Hosting
2. Ultra-Host
3. 现在是 spaceship，我所有的 DNS 记录、域名、邮箱都在这里。

[tobiaseigen]

您试过 Troubleshoot email on a new Discourse install?
抱歉给您带来了这么多麻烦。本不该如此困难！

[errorexee (Error.EXE)]

是的，我做到了……然后我通过 SSH 命令创建了管理员账户。之后，我看到了错误：“Job exception: Net::ReadTimeout”

[errorexee (Error.EXE)]

故障排除步骤摘要：

• 使用官方 Docker 安装指南，在 Spaceship VPS（凤凰城，美国）上安装 Discourse。

• 通过 SSH 命令创建管理员帐户。

• 使用 Spacemail（mail.spacemail.com，端口 465，SSL，完整电子邮件作为用户名，正确密码）配置 SMTP。

• 多次重置并重新输入 SMTP 密码。

• 尝试使用 mail.spacemail.com 和 smtp.spacemail.com 作为 SMTP 服务器。

• 与 Spacemail 支持确认，他们那边没有任何限制或阻止。

• 确认所有 DNS 记录（MX、SPF、DKIM）均正确且已传播。

• 在 Gmail 中使用相同的 Spacemail 帐户成功发送和接收电子邮件（SMTP 在 Discourse 之外工作）。

• 使用 VPS 通过 telnet 和 openssl 测试 SMTP 连接（成功收到 TLS 握手和 SMTP 标语）。

• 将 Docker 网络 MTU 更改为 1400，并重新启动 Docker 和 Discourse 容器。

• 确认容器中的 Redis、PostgreSQL 和所有其他服务均正常运行。

• 在每次更改后尝试销毁/启动和完全重建 Discourse 应用。

• 检查日志：发送电子邮件时仅出现 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-8
  LANG: en_US.UTF-8
  LANGUAGE: 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
dgAOV5S8866pPjMbLJkHs/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:
    Resumption PSK: F99B4B27314220CB53DEE7B1D852B2AE360D39472E1F020806FAC5D40A72F206636EA0B50545C9F1875BCACB5FD35F07
    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

---

[NateDhaliwal]

尝试端口 587 或 2525（先尝试 587），它们是否可用？587 是安装指南中提到的端口。

[errorexee (Error.EXE)]

感谢您的建议。我的邮箱提供商 (Spacemail) 官方仅支持使用 SSL 的端口 465 进行 SMTP。但是，在故障排除过程中（与技术支持一起），我也测试了使用 STARTTLS 的端口 587，但超时问题仍然存在。

[Lilly (Lillian Louis)]

我上周使用两个不同的电子邮件提供商进行了两次标准安装，我知道它是有效的。我怀疑 spacemail 不适合实际的事务性电子邮件。

Issue with creating admin account for first time

[image] This is my current configuration and I cannot create the first admin account because its not sending the activation email. I have used SMTP with my provider and it works, the issue is with discourse I have tried the same credentials with thunderbird and it worked. I have tried my doctor also as this topic suggests. These are the results [image]

虽然我不知道这是否有效

@errorexee

Spaceship VPS

[errorexee (Error.EXE)]

Spaceship 或 Spacemail 方面没有任何阻碍。我昨天花了七个小时与他们的支持部门讨论这个问题，他们确认所有必要的端口都已打开，并且 SMTP 在他们那边可以正常工作。他们让我来这里进行进一步的故障排除。另外，Spacemail 不支持 2525 端口，所以我不能使用它作为替代。

[errorexee (Error.EXE)]

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# sudo ufw 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#

[schneeland]

不确定这是否有帮助，因为您已经通过 telnet 检查了端口访问，但您可以尝试使用 Swaks 发送邮件（应该有一个可用的 Ubuntu 软件包）。我觉得它在调试电子邮件问题方面很有帮助。

[NateDhaliwal]

也许可以试试像 Brevo 或 Mailgun 这样的事务性电子邮件服务？如果可行，那么您可能想改用它。据我所知，就像 Lilly 所说的那样，我没有看到任何迹象表明它是一个事务性电子邮件服务。

我刚问了他们的客服，他们说：

虽然 Spacemail 不直接支持事务性电子邮件，但您可以使用 SMTP 协议将您的 Spacemail 邮箱连接到您的联系表单或任何自动发送电子邮件的工具。

[errorexee (Error.EXE)]

问题出在 spaceship 端。因为我尝试了 GOOGLE SMTP，它工作正常，并且我收到了测试邮件。
今天，我已通过 spaceship 支持将此问题转交给 spaceship 技术人员。如果需要您提供任何详细信息，我会直接告知您。

[supermathie (Michael Brown)]

@errorexee

我的邮箱提供商 (Spacemail) 官方仅支持使用 SSL 的 465 端口进行 SMTP。不过，为了排查问题（与技术支持一起），我也测试了使用 STARTTLS 的 587 端口，但超时问题仍然存在。

在我看来，这是他们对 465 端口的混乱情况的一种错误认识。

465 端口 (SMTPS) 在 VPS 环境中经常被阻止，作为一种反垃圾邮件措施，因为它曾是 MTA-MTA TLS 通信的历史端口。如今，它已被重新分配给 SUBMISSIONS（SUBMISSION + 隐式 TLS），但我预计 VPS 提供商永远不会解除阻止，因为总会有 MTA 在此端口监听 MTA-MTA 流量。

587 端口 (SUBMISSION) 明确是 MUA-MTA 邮件提交端口，是与 STARTTLS 结合用于身份验证邮件提交的端口。

即便如此，587 端口有时仍会被不明就里的 VPS 提供商阻止。

尽管我对此大发牢骚，但我看到你可以连接到该端口，那么如果你从 VPS 和容器通过 465 端口手动发送邮件，会发生什么？

[tobiaseigen]

@errorexee 您的问题解决了吗？