Problema persistente di timeout SMTP con Spacemail su Discourse (VPS, Docker)

Supporto
1

Ciao Supporto/Community di Discourse,

Da diversi giorni sto lottando per risolvere un problema con le email in uscita dalla mia istanza di Discourse. Sto eseguendo Discourse in un container Docker su un VPS Spaceship (Phoenix, USA). Il mio provider di posta è Spacemail (SMTP).

Problema:

  • Discourse non riesce a inviare email. Ogni tentativo di inviare un’email di prova risulta in un errore di timeout:

    • Net::ReadTimeout with #<TCPSocket:(closed)>

    • Oppure: execution expired

  • Il problema persiste indipendentemente dal fatto che utilizzi mail.spacemail.com o smtp.spacemail.com come server SMTP.

Cosa ho provato:

  • Verificato tutte le impostazioni SMTP (indirizzo, porta 465 per SSL, email completa come nome utente, password corretta) con il supporto di Spaceship/Spacemail.

  • Reimpostato e reinserito la password SMTP più volte.

  • Confermato con il supporto Spacemail che non ci sono restrizioni o blocchi da parte loro.

  • Telnet dal VPS a mail.spacemail.com sulla porta 465 ha successo (la connessione si apre, nessun problema di firewall).

  • Modificato l’MTU della rete Docker a 1400 come suggerito nei forum di Discourse e riavviato Docker e il container Discourse.

  • Provato sia destroy/start che un rebuild completo dell’app Discourse.

  • Verificato che Redis, PostgreSQL e tutti gli altri servizi siano in esecuzione correttamente nel container.

  • Verificato che tutti i record DNS (MX, SPF, DKIM) siano configurati e propagati.

  • Testato da più browser e dispositivi per escludere problemi lato client.

  • Inviato e ricevuto correttamente email utilizzando lo stesso account Spacemail in Gmail (SMTP funziona al di fuori di Discourse).

Ambiente:

  • Discourse in esecuzione in Docker su VPS Ubuntu 22.04 (Spaceship, Phoenix, USA)

  • Provider SMTP: Spacemail

  • Impostazioni SMTP: SSL, porta 465, mail.spacemail.com (provato anche smtp.spacemail.com)

  • Tutti i record DNS sono corretti e propagati

Log:

  • Nessun errore nei log di Discourse tranne il timeout nell’invio delle email.

  • Redis e altri servizi sono in esecuzione senza conflitti.

  • I timeout dei worker di Unicorn coincidono con i tentativi di invio email.

Contesto aggiuntivo: Solo oggi, ho dedicato circa 7 ore alla risoluzione di questo problema con il supporto Spacemail tramite chat live. Nonostante i loro sforzi e la conferma che tutto è configurato correttamente da parte loro, il problema persiste.

Cosa mi serve:

  • Qualsiasi consiglio su cos’altro controllare o provare?

  • Esiste un modo per ottenere log di debug SMTP più dettagliati da Discourse?

  • Qualcuno ha riscontrato un problema simile con Spacemail o un altro provider?

Grazie mille per il vostro tempo e supporto!

2

Puoi confermare di aver seguito l’installazione ufficiale?

3

Sì, ho seguito la guida ufficiale all’installazione di Discourse per Docker. Se necessario, posso fornire dettagli sulla mia configurazione o su eventuali aggiustamenti che ho dovuto apportare per il mio ambiente VPS.

4

Dettagli del registro errori:

Quando si tenta di inviare email da Discourse, ricevo costantemente un errore di timeout nei log dei job:

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'
... (stacktrace completo disponibile su richiesta)

Descrizione: Questo errore si verifica ogni volta che Discourse tenta di inviare un’email. Il Net::ReadTimeout indica che Discourse sta aspettando una risposta dal server SMTP (Spacemail), ma non la riceve in tempo. Tutti i test di rete e TLS (openssl, telnet) hanno successo e SMTP funziona nei client esterni, quindi il problema sembra essere specifico della comunicazione o dell’autenticazione SMTP di Discourse.

Se necessiti dello stacktrace completo o di maggiori dettagli, posso fornirli.

5

Non ho alcuna familiarità con quel vps. Se sei proprio all’inizio della configurazione, puoi provare a ricominciare con un nuovo server invece di continuare a sbattere la testa contro il muro. Magari prova un provider diverso se anche questo non dovesse funzionare.

6

Ho provato:

  1. Zap-Hosting
  2. Ultra-Host
  3. E ora spaceship, dove ho tutti i record DNS, il dominio, la casella di posta.
7

Hai provato Troubleshoot email on a new Discourse install?

Mi dispiace che sia stata una lotta per te. Non dovrebbe essere così difficile!

8

Sì, l’ho fatto… Poi ho creato l’account amministratore tramite comando SSH. Dopo di che, ho visto l’errore: ‘Job exception: Net::ReadTimeout’

9

Riepilogo dei passaggi di risoluzione dei problemi eseguiti:

  • Installato Discourse su un VPS Spaceship (Phoenix, USA) utilizzando la guida ufficiale all’installazione di Docker.

  • Creato l’account amministratore tramite comando SSH.

  • Configurato SMTP con Spacemail (mail.spacemail.com, porta 465, SSL, email completa come nome utente, password corretta).

  • Ripristinata e reinserita la password SMTP più volte.

  • Provato sia mail.spacemail.com che smtp.spacemail.com come server SMTP.

  • Verificato con il supporto Spacemail che non ci siano restrizioni o blocchi da parte loro.

  • Confermati tutti i record DNS (MX, SPF, DKIM) corretti e propagati.

  • Inviate e ricevute email con successo utilizzando lo stesso account Spacemail in Gmail (SMTP funziona al di fuori di Discourse).

  • Testata la connessione SMTP dal VPS utilizzando telnet e openssl (handshake TLS e banner SMTP ricevuti con successo).

  • Modificato l’MTU della rete Docker a 1400 e riavviati Docker e il container Discourse.

  • Verificato che Redis, PostgreSQL e tutti gli altri servizi siano in esecuzione correttamente nel container.

  • Provato sia destroy/start che rebuild completo dell’app Discourse dopo ogni modifica.

  • Controllato i log: solo errori Net::ReadTimeout durante l’invio di email, nessun altro errore.

  • Assicurato che “Abilita SMTP” sia abilitato nell’interfaccia di amministrazione di Discourse.

  • Dedicati diversi giorni e circa 7 ore in chat live con il supporto Spaceship/Spacemail per risolvere questo problema.

Nonostante tutti questi passaggi, Discourse non riesce ancora a inviare email e restituisce sempre un errore Net::ReadTimeout.

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet mail.spacemail.com 465Tentativo di connessione a 198.177.121.32…Connesso a mail.spacemail.com.Carattere di escape è ‘^\]’.

(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: “” –> sto usando caratteri speciali
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:1depth=1 C = GB, O = Sectigo Limited, CN = Sectigo Public Server Authentication CA DV R36
verify return:1depth=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
1 Mi Piace
10

Prova le porte 587 o 2525 (prova prima la 587), funzionano? 587 è la porta menzionata nella guida all’installazione.

1 Mi Piace
11

Grazie per il tuo suggerimento. Il mio provider di posta elettronica (Spacemail) supporta ufficialmente solo la porta 465 con SSL per SMTP. Tuttavia, ho anche testato la porta 587 con STARTTLS come parte della risoluzione dei problemi (insieme al supporto), ma il problema del timeout persiste ancora.

12

Ho eseguito l’installazione standard due volte la scorsa settimana con 2 diversi provider di posta elettronica e so che funziona. Sospetto che spacemail non sia adatto per l’invio di email transazionali.

anche se non ho idea se questo funzioni

4 Mi Piace
13

Nessun blocco da parte di Spaceship o Spacemail. Ho passato sette ore a discuterne con il loro supporto ieri, e mi hanno confermato che tutte le porte necessarie sono aperte e che SMTP funziona dalla loro parte. Mi hanno mandato qui per ulteriori verifiche. Inoltre, la porta 2525 non è supportata da Spacemail, quindi non posso usarla come alternativa.

14

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

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 Mi Piace
15

Non sono sicuro che aiuti dato che hai già verificato l’accesso alla porta tramite telnet, ma potresti provare a inviare un’email con Swaks (dovrebbe essere disponibile un pacchetto Ubuntu per esso). Lo trovo piuttosto utile per il debug dei problemi di posta elettronica.

16

Forse prova un servizio di email transazionali come Brevo o Mailgun? Se funziona, potresti volerlo usare invece. Per quanto posso vedere, come ha detto Lilly, non vedo alcuna indicazione che si tratti di un servizio di email transazionali.

Ho appena chiesto al loro supporto e mi hanno detto:

Sebbene Spacemail non supporti direttamente le email transazionali, puoi utilizzare il protocollo SMTP per collegare la tua casella di posta Spacemail al tuo modulo di contatto o a qualsiasi strumento che invii email automaticamente.

1 Mi Piace
17

Il problema sarà dal lato della spaceship. Perché ho provato GOOGLE SMTP, e funziona e ho ricevuto un’email di prova.
Oggi, ho inoltrato questo ai tecnici della spaceship tramite il supporto della spaceship. Ti farò sapere se sono necessari ulteriori dettagli direttamente da te.

2 Mi Piace
18

Questo è (secondo me) un approccio errato da parte loro a causa del caos assoluto attorno alla porta 465.

La porta 465 (SMTPS) è MOLTO frequentemente bloccata negli ambienti VPS come misura antispam poiché è la porta storica utilizzata per la comunicazione TLS da MTA a MTA. Al giorno d’oggi è stata riassegnata a SUBMISSIONS (SUBMISSION + TLS implicito), ma non prevedo che i provider VPS la sbloccheranno mai a causa del fatto che ci saranno sempre MTA in ascolto per il traffico da MTA a MTA su questa porta.

La porta 587 (SUBMISSION) è esplicitamente la porta di invio della posta da MUA a MTA ed è ciò che dovrebbe essere utilizzato per l’invio di posta autenticata in combinazione con STARTTLS.

Ciononostante, la porta 587 è ancora a volte bloccata da provider VPS poco informati.

Nonostante il mio sfogo a riguardo, vedo che puoi connetterti a quella porta, quindi cosa succede se invii manualmente la posta dal VPS e dal container tramite la porta 465?

2 Mi Piace
19

@errorexee sei riuscito a risolvere il tuo problema?

1 Mi Piace
20

Questo argomento è stato chiuso automaticamente 14 giorni dopo l’ultima risposta. Non sono più ammesse nuove risposte.