Problema persistente de tiempo de espera SMTP con Spacemail en Discourse (VPS, Docker)

Soporte
1

Hola Soporte/Comunidad de Discourse,

He estado luchando durante varios días para resolver un problema con los correos electrónicos salientes de mi instancia de Discourse. Estoy ejecutando Discourse en un contenedor Docker en un VPS Spaceship (Phoenix, EE. UU.). Mi proveedor de correo es Spacemail (SMTP).

Problema:

  • Discourse no puede enviar correos electrónicos. Cada intento de enviar un correo electrónico de prueba resulta en un error de tiempo de espera:

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

    • O: execution expired

  • El problema persiste independientemente de si uso mail.spacemail.com o smtp.spacemail.com como servidor SMTP.

Lo que he intentado:

  • Verifiqué todas las configuraciones SMTP (dirección, puerto 465 para SSL, correo electrónico completo como nombre de usuario, contraseña correcta) con el soporte de Spaceship/Spacemail.

  • Restablecí y volví a ingresar la contraseña SMTP varias veces.

  • Confirmé con el soporte de Spacemail que no hay restricciones ni bloqueos de su lado.

  • Telnet desde el VPS a mail.spacemail.com en el puerto 465 es exitoso (la conexión se abre, no hay problema de firewall).

  • Cambié la MTU de la red Docker a 1400 como se sugirió en los foros de Discourse y reinicié Docker y el contenedor de Discourse.

  • Probé tanto destroy/start como un rebuild completo de la aplicación Discourse.

  • Verifiqué que Redis, PostgreSQL y todos los demás servicios se estén ejecutando correctamente en el contenedor.

  • Verifiqué que todos los registros DNS (MX, SPF, DKIM) estén configurados y propagados.

  • Probé desde múltiples navegadores y dispositivos para descartar problemas del lado del cliente.

  • Envié y recibí correos electrónicos con éxito utilizando la misma cuenta de Spacemail en Gmail (SMTP funciona fuera de Discourse).

Entorno:

  • Discourse ejecutándose en Docker en un VPS Ubuntu 22.04 (Spaceship, Phoenix, EE. UU.)

  • Proveedor SMTP: Spacemail

  • Configuración SMTP: SSL, puerto 465, mail.spacemail.com (también probé smtp.spacemail.com)

  • Todos los registros DNS son correctos y están propagados

Registros:

  • No hay errores en los registros de Discourse, excepto el tiempo de espera en el envío de correos electrónicos.

  • Redis y otros servicios se ejecutan sin conflictos.

  • Los tiempos de espera de los trabajadores de Unicorn coinciden con los intentos de envío de correo electrónico.

Contexto adicional: Solo hoy, he pasado aproximadamente 7 horas trabajando con el soporte de Spacemail a través de chat en vivo para solucionar este problema. A pesar de sus esfuerzos y la confirmación de que todo está configurado correctamente de su lado, el problema persiste.

Lo que necesito:

  • ¿Algún consejo sobre qué más revisar o intentar?

  • ¿Hay alguna forma de obtener registros de depuración SMTP más detallados de Discourse?

  • ¿Alguien se ha encontrado con un problema similar con Spacemail o con otro proveedor?

¡Muchas gracias por su tiempo y apoyo!

2

¿Puedes confirmar que seguiste la instalación oficial?

3

Sí, seguí la guía oficial de instalación de Discourse para Docker. Si lo necesitas, puedo proporcionar detalles sobre mi configuración o cualquier ajuste que haya tenido que hacer para mi entorno de VPS.

4

Detalles del registro de errores:

Al intentar enviar correos electrónicos desde Discourse, recibo constantemente un error de tiempo de espera agotado en los registros de trabajos:

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'
... (trace completo disponible bajo solicitud)

Descripción: Este error ocurre cada vez que Discourse intenta enviar un correo electrónico. El Net::ReadTimeout indica que Discourse está esperando una respuesta del servidor SMTP (Spacemail), pero no la recibe a tiempo. Todas las pruebas de red y TLS (openssl, telnet) tienen éxito, y SMTP funciona en clientes externos, por lo que el problema parece ser específico de la comunicación o autenticación SMTP de Discourse.

Si necesita el stacktrace completo o más detalles, puedo proporcionarlos.

5

No estoy familiarizado en absoluto con ese vps. Si estás al principio de la configuración, puedes intentar empezar de nuevo con un servidor nuevo en lugar de seguir golpeándote la cabeza contra la pared. Quizás prueba con un proveedor diferente si eso todavía no funciona.

6

Probé:

  1. Zap-Hosting
  2. Ultra-Host
  3. Y ahora spaceship, donde tengo todos los registros DNS, dominio y buzón.
7

¿Has probado Troubleshoot email on a new Discourse install?

Lamento que esto te haya resultado tan difícil. ¡No debería ser tan complicado!

8

Sí, lo hice… Luego creé la cuenta de administrador mediante un comando SSH. Después de eso, vi el error: ‘Excepción de trabajo: Net::ReadTimeout’

9

Resumen de los pasos de solución de problemas realizados:

  • Instalado Discourse en un VPS de Spaceship (Phoenix, EE. UU.) utilizando la guía oficial de instalación de Docker.

  • Creado la cuenta de administrador a través del comando SSH.

  • Configurado SMTP con Spacemail (mail.spacemail.com, puerto 465, SSL, correo electrónico completo como nombre de usuario, contraseña correcta).

  • Restablecido y reintroducido la contraseña SMTP varias veces.

  • Probado tanto mail.spacemail.com como smtp.spacemail.com como servidores SMTP.

  • Verificado con el soporte de Spacemail que no hay restricciones ni bloqueos por su parte.

  • Confirmado que todos los registros DNS (MX, SPF, DKIM) son correctos y se han propagado.

  • Enviado y recibido correos electrónicos con éxito utilizando la misma cuenta de Spacemail en Gmail (SMTP funciona fuera de Discourse).

  • Probado la conexión SMTP desde el VPS utilizando telnet y openssl (se recibió correctamente el handshake TLS y el banner SMTP).

  • Cambiado la MTU de la red Docker a 1400 y reiniciado Docker y el contenedor de Discourse.

  • Comprobado que Redis, PostgreSQL y todos los demás servicios se ejecutan correctamente en el contenedor.

  • Probado tanto destroy/start como rebuild completo de la aplicación Discourse después de cada cambio.

  • Comprobado los registros: solo errores Net::ReadTimeout al enviar correos electrónicos, sin otros errores.

  • Asegurado que “Enable SMTP” esté habilitado en la interfaz de administración de Discourse.

  • Pasado varios días y aproximadamente 7 horas en chat en vivo con el soporte de Spaceship/Spacemail solucionando este problema.

A pesar de todos estos pasos, Discourse todavía no puede enviar correos electrónicos y siempre devuelve un error Net::ReadTimeout.

root@ubuntu-2vcpu-amd-2gb-us-7yr03:/var/discourse# telnet ``mail.spacemail.com`` 465Intentando 198.177.121.32…Conectado a ``mail.spacemail.com``.El carácter de escape es ‘^\]’.

(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: “” –> Estoy usando caracteres especiales
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)
---
---
New Session Ticket arrived after Handshake:
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 me gusta
10

Prueba los puertos 587 o 2525 (prueba primero el 587), ¿funcionan? 587 es el puerto mencionado en la guía de instalación.

1 me gusta
11

Gracias por tu sugerencia. Mi proveedor de buzón (Spacemail) solo admite oficialmente el puerto 465 con SSL para SMTP. Sin embargo, también he probado el puerto 587 con STARTTLS como parte de la solución de problemas (junto con el soporte), pero el problema de tiempo de espera persiste.

12

Lo hice con una instalación estándar dos veces la semana pasada con 2 proveedores de correo electrónico diferentes, y sé que funciona. Sospecho que spacemail no es adecuado para el correo electrónico transaccional real.

aunque no tengo idea de si esto funciona

4 Me gusta
13

Nada está bloqueado por parte de Spaceship o Spacemail. Pasé siete horas discutiendo esto con su soporte ayer, y confirmaron que todos los puertos necesarios están abiertos y que SMTP funciona por su parte. Me enviaron aquí para solucionar problemas adicionales. Además, Spacemail no admite el puerto 2525, por lo que no puedo usarlo como alternativa.

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 me gusta
15

No estoy seguro de si eso ayuda, ya que ya comprobaste el acceso al puerto a través de telnet, pero podrías intentar enviar un correo electrónico con Swaks (debería haber un paquete de Ubuntu disponible para él). Me resulta bastante útil para depurar problemas de correo electrónico.

16

¿Quizás podrías probar un servicio de correo electrónico transaccional como Brevo o Mailgun? Si funciona, entonces quizás quieras usarlo en su lugar. Por lo que puedo ver, al igual que dijo Lilly, no veo ninguna indicación de que sea un servicio de correo electrónico transaccional.

Acabo de preguntar a su soporte y dijeron:

Si bien Spacemail no admite directamente correos electrónicos transaccionales, puedes usar el protocolo SMTP para conectar tu buzón de Spacemail a tu formulario de contacto o a cualquier herramienta que envíe correos electrónicos automáticamente.

1 me gusta
17

El problema estará del lado de la nave espacial. Porque probé GOOGLE SMTP, y funciona y recibí un correo electrónico de prueba.
Hoy, reenvié esto a los técnicos de la nave espacial a través del soporte de la nave espacial. Le informaré si se necesitan detalles directamente de usted.

2 Me gusta
18

Este es (en mi opinión) un enfoque desinformado por su parte debido al absoluto desastre en torno al puerto 465.

El puerto 465 (SMTPS) es MUY frecuentemente bloqueado en entornos VPS como medida antispam, ya que es el puerto histórico utilizado para la comunicación TLS MTA-MTA. Hoy en día ha sido reasignado a SUBMISSIONS (SUBMISSION + TLS implícito), pero no preveo que los proveedores de VPS lo desbloqueen nunca debido al hecho de que siempre habrá MTAs escuchando tráfico MTA-MTA en este puerto.

El puerto 587 (SUBMISSION) es explícitamente el puerto de envío de correo MUA-MTA y es lo que debería usarse para el envío de correo autenticado en combinación con STARTTLS.

Aun así, el puerto 587 todavía a veces es bloqueado por proveedores de VPS desinformados.

A pesar de mi diatriba sobre esto, veo que puedes conectarte a ese puerto, así que ¿qué sucede si envías correo manualmente desde el VPS y desde el contenedor a través del puerto 465?

2 Me gusta
19

@errorexee ¿pudiste resolver tu problema?

1 me gusta
20

Este tema se cerró automáticamente 14 días después de la última respuesta. Ya no se permiten nuevas respuestas.