Постоянная ошибка тайм-аута SMTP с Spacemail в Discourse (VPS, Docker)

Поддержка
1

Здравствуйте, поддержка и сообщество Discourse,

Я уже несколько дней пытаюсь решить проблему с исходящей почтой на моем экземпляре Discourse. Я запускаю Discourse в контейнере Docker на VPS Spaceship (Феникс, США). Мой почтовый провайдер — Spacemail (SMTP).

Проблема:

  • Discourse не может отправлять письма. Каждая попытка отправить тестовое письмо завершается ошибкой тайм-аута:

    • Net::ReadTimeout с #<TCPSocket:(закрыт)>

    • Или: execution expired

  • Проблема сохраняется независимо от того, использую ли я mail.spacemail.com или smtp.spacemail.com в качестве SMTP-сервера.

Что я уже пробовал:

  • Проверил все настройки SMTP (адрес, порт 465 для SSL, полное имя пользователя как email, правильный пароль) вместе с поддержкой Spaceship/Spacemail.

  • Многократно сбрасывал и заново вводил пароль SMTP.

  • Убедился с поддержкой Spacemail, что с их стороны нет ограничений или блокировок.

  • Telnet с VPS на mail.spacemail.com через порт 465 проходит успешно (соединение устанавливается, проблем с фаерволом нет).

  • Изменил MTU сети Docker на 1400, как рекомендовано на форумах Discourse, и перезапустил Docker и контейнер Discourse.

  • Пробовал как destroy/start, так и полную rebuild приложения Discourse.

  • Проверил, что Redis, PostgreSQL и все остальные службы работают корректно внутри контейнера.

  • Убедился, что все DNS-записи (MX, SPF, DKIM) настроены и распространены.

  • Протестировал с нескольких браузеров и устройств, чтобы исключить проблемы на стороне клиента.

  • Успешно отправлял и получал письма с той же учетной записью Spacemail в Gmail (SMTP работает вне Discourse).

Окружение:

  • Discourse запущен в Docker на VPS с Ubuntu 22.04 (Spaceship, Феникс, США)

  • SMTP-провайдер: Spacemail

  • Настройки SMTP: SSL, порт 465, mail.spacemail.com (также пробовал smtp.spacemail.com)

  • Все DNS-записи корректны и распространены

Логи:

  • В логах Discourse нет ошибок, кроме тайм-аута при отправке писем.

  • Redis и другие службы работают без конфликтов.

  • Тайм-ауты воркеров Unicorn совпадают с попытками отправки писем.

Дополнительный контекст: Только сегодня я потратил около 7 часов на работу с поддержкой Spacemail через чат в реальном времени для устранения этой проблемы. Несмотря на их усилия и подтверждение, что всё настроено правильно с их стороны, проблема сохраняется.

Что мне нужно:

  • Любые советы, что ещё можно проверить или попробовать?

  • Есть ли способ получить более подробные отладочные логи SMTP из Discourse?

  • Сталкивался ли кто-нибудь с подобной проблемой при использовании Spacemail или другого провайдера?

Огромное спасибо за ваше время и поддержку!

2

Можете подтвердить, что вы следовали официальной инструкции по установке?

3

Да, я следовал официальному руководству по установке Discourse для Docker. Если нужно, я могу предоставить детали моей настройки или любые изменения, которые мне пришлось внести для среды моего VPS.

4

Детали журнала ошибок:

При попытке отправки писем из Discourse я постоянно получаю ошибку тайм-аута в логах заданий:

Исключение в задании: 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 работает во внешних клиентах, поэтому проблема, по-видимому, специфична для SMTP-коммуникации или аутентификации в Discourse.

Если вам нужен полный стек трассировки или дополнительные детали, я могу их предоставить.

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

Краткое описание выполненных шагов по устранению неполадок:

  • Установлен Discourse на VPS Spaceship (Феникс, США) с использованием официального руководства по установке Docker.

  • Создана учетная запись администратора через команду SSH.

  • Настроен SMTP с использованием Spacemail (mail.spacemail.com, порт 465, SSL, полное имя электронной почты в качестве имени пользователя, правильный пароль).

  • Пароль SMTP сбрасывался и вводился заново несколько раз.

  • Пробовались оба сервера: mail.spacemail.com и smtp.spacemail.com.

  • В службе поддержки Spacemail подтвердили отсутствие ограничений или блокировок с их стороны.

  • Подтверждено, что все DNS-записи (MX, SPF, DKIM) верны и распространены.

  • Успешная отправка и получение писем с использованием той же учетной записи Spacemail в Gmail (SMTP работает вне Discourse).

  • Протестировано соединение SMTP с VPS с помощью telnet и openssl (рукопожатие TLS и баннер SMTP получены успешно).

  • Изменен MTU сети Docker на 1400, после чего перезапущены Docker и контейнер Discourse.

  • Проверено, что Redis, PostgreSQL и все остальные службы корректно работают внутри контейнера.

  • После каждого изменения пробовались варианты: уничтожение и запуск приложения, а также полная пересборка Discourse.

  • Проверены логи: при отправке писем наблюдаются только ошибки Net::ReadTimeout, других ошибок нет.

  • Убедился, что в интерфейсе администратора Discourse включена опция «Включить SMTP».

  • Потратил несколько дней и около 7 часов на живом чате с поддержкой Spaceship/Spacemail для устранения этой проблемы.

Несмотря на все эти шаги, Discourse по-прежнему не может отправлять письма и всегда возвращает ошибку Net::ReadTimeout.

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet ``mail.spacemail.com`` 465Trying 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: “” –> Я использую специальные символы
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
nzi9sR4SQlEzDG0OSThJ7rj+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
dgCWl2S/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
10

Попробуйте порты 587 или 2525 (сначала 587), они работают? Порт 587 указан в руководстве по установке.

11

Спасибо за ваше предложение. Мой почтовый провайдер (Spacemail) официально поддерживает только порт 465 с SSL для SMTP. Однако я также протестировал порт 587 с STARTTLS в рамках устранения неполадок (вместе со службой поддержки), но проблема с тайм-аутом сохраняется.

12

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

хотя я не уверен, сработает ли это

13

Со стороны Spaceship или Spacemail ничего не заблокировано. Вчера я провёл семь часов в обсуждении этого вопроса с их поддержкой, и они подтвердили, что все необходимые порты открыты, а SMTP работает с их стороны. Онинаправили меня сюда для дальнейшего устранения неполадок. Кроме того, порт 2525 не поддерживается Spacemail, поэтому я не могу использовать его в качестве альтернативы.

14

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# sudo ufw status
Статус: активен

К порт Действие Откуда

443/tcp Разрешено Везде
22/tcp Разрешено Везде
80/tcp Разрешено Везде
22022/tcp Разрешено Везде
465/tcp Разрешено Везде
443/tcp (v6) Разрешено Везде (v6)
22/tcp (v6) Разрешено Везде (v6)
80/tcp (v6) Разрешено Везде (v6)
22022/tcp (v6) Разрешено Везде (v6)
465/tcp (v6) Разрешено Везде (v6)

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

15

Не уверен, поможет ли это, раз вы уже проверили доступ к порту через telnet, но вы можете попробовать отправить письмо с помощью Swaks (для Ubuntu, скорее всего, есть доступный пакет). Я считаю его весьма полезным для отладки проблем с электронной почтой.

16

Попробуйте, например, сервис транзакционной рассылки, такой как Brevo или Mailgun. Если это сработает, возможно, стоит использовать его. Судя по тому, что я вижу, как и отметила Лилли, нет никаких указаний на то, что это сервис для транзакционных писем.

Я только что спросил их службу поддержки, и они ответили:

Хотя Spacemail не поддерживает напрямую транзакционные письма, вы можете использовать протокол SMTP, чтобы подключить почтовый ящик Spacemail к вашей форме обратной связи или любому инструменту, автоматически отправляющему письма.

17

Проблема, скорее всего, на стороне spaceship. Я попробовал использовать SMTP от Google, и это сработало — я получил тестовое письмо.
Сегодня я переслал эту информацию техникам spaceship через службу поддержки spaceship. Я сообщу вам, если потребуются какие-либо детали непосредственно от вас.

18

На мой взгляд, это ошибочный подход с их стороны из-за полного хаоса вокруг порта 465.

Порт 465 (SMTPS) очень часто блокируется в средах VPS как мера борьбы со спамом, поскольку исторически это порт, используемый для TLS-связи между MTA. В настоящее время он был переназначен для SUBMISSIONS (SUBMISSION + неявный TLS), но я не ожидаю, что провайдеры VPS когда-либо разблокируют его, так как на этом порту всегда будут работать MTA, ожидающие трафика между MTA.

Порт 587 (SUBMISSION) явно предназначен для отправки почты с MUA на MTA, и именно его следует использовать для аутентифицированной отправки почты в сочетании с STARTTLS.

Тем не менее, порт 587 всё ещё иногда блокируется недостаточно осведомлёнными провайдерами VPS.

Несмотря на мою критику этой ситуации, я вижу, что подключение к этому порту возможно. Что произойдёт, если вы вручную отправите почту с VPS и из контейнера через порт 465?

19

@errorexee удалось ли вам решить вашу проблему?