No se puede enviar correo electrónico - problema con el puerto 465

[schungx (Stephen Chung)]

Me gustaría cambiar el proveedor SMTP, pero no parece funcionar aunque estoy seguro de que el servidor puede enviar correos electrónicos.

Tengo esto en app.yml:

  DISCOURSE_SMTP_ADDRESS: <<SMTP SERVER>>
  DISCOURSE_SMTP_PORT: 465
  DISCOURSE_SMTP_USER_NAME: <<USER>>
  DISCOURSE_SMTP_PASSWORD: <<PASSWORD>>

Usando telnet <<SMTP SERVER>> 465 se conecta correctamente, pero cuando intento enviar correos electrónicos, Discourse responde con:

ERROR - Net::ReadTimeout with #<Socket:(closed)>

¿Alguien tiene alguna indicación de lo que necesito configurar?

Revisé el servidor basándome en este tema: Troubleshoot email on a new Discourse install

Parece que se conecta al servidor y envía un correo electrónico de prueba correctamente si lo hago manualmente:

> sudo ./launcher enter app
root@support-app:/var/www/discourse# openssl s_client -connect mail.xxxxxxxx.com:465
  :
  :
  enorme cantidad de basura
  :
  :
220 xxxxxxx.com Anti-spam GT for Coremail System (mispb-6da2110f-64b0-4d67-acf1-2d302bd594f9-xxxxxxx.com[20220915])
EHLO mail.xxxxxxxxx.com
250-mail
250-PIPELINING
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-coremail 1Uxr2xKj7kG0xkI17xGrUDI0s8FY2U3Uj8Cz28x1UUUUU7Ic2I0Y2UrpDiNKUCa0xDrUUUUj
250-STARTTLS
250-SMTPUTF8
250 8BITMIME
AUTH PLAIN xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
235 Authentication successful
mail from: <xxx@xxxxxx.com>
250 Mail OK
rcpt to: <xxxx@xxxxxxx.com>
250 Mail OK
data
354 End data with <CR><LF>
content

.
250 Mail OK queued as AQAAfwBXr9nSGHdj3hEgAA--.7073S2

[RGJ (Richard - Communiteq)]

@schungx

Parece que se conecta al servidor y envía un correo electrónico de prueba correctamente si lo hago manualmente:

¿Cuánto tiempo tarda en aparecer la salida?

SMTP Net::ReadTimeout without relation to net or login problems - SMTP host is just slow

Hello, since view weeks sending mail from my Discourse instance fails. The SMTP settings are unchanged, curl test is still working but notably slow. The smtp server from our hoster (that we need to send mails with) has a consistent send time of 7 seconds. cat testmail | curl -vvv --url 'smtp://smtp.<HOST>:587' --mail-from mail@<DOMAIN> --mail-rcpt <ME> --user "mail@<DOMAIN>:<PW>" -T - % Total % Received % Xferd Average Speed Time Time Time Current …

[schungx (Stephen Chung)]

@RGJ

¿Cuánto tiempo tarda en aparecer la salida?

Casi inmediatamente después de enviar un comando.

EDITAR: ¿Hay alguna forma de obtener un registro más detallado para descubrir qué paso está causando el error?

[pfaffman (Jay Pfaffman)]

Es probable que el proveedor de alojamiento esté bloqueando el puerto de salida. Si utilizas algún servicio como Mailgun (o casi cualquier otro), el puerto 2525 debería funcionar. Si se trata de un servidor de correo que administras, puedes hacer que escuche en otro puerto (como el 2525).

O (probablemente lo más difícil) puedes abrir un ticket con quien aloja tu servidor y pedirle que abra el puerto.

[schungx (Stephen Chung)]

Bueno, considerando que puedo ./launcher enter app y luego openssl conectarme al servidor de correo, iniciar sesión vía SMTP y enviar un correo electrónico con éxito desde dentro del contenedor de Discourse, dudo que sea el puerto el que no funcione…

[schungx (Stephen Chung)]

Rastreé el código y parece que EHLO ni siquiera se alcanzó. El servidor SMTP está conectado, pero parece faltar el handshake SSL, por lo que el servidor se cierra y Discourse no recibe ninguna respuesta, de ahí el error.

Así que sospeché que el soporte del puerto 465 parece tener un error (por defecto es SSL, pero no creo que Discourse lo reconozca), por lo que probablemente la conexión SSL nunca se establece.

Cambiar al puerto 25 parece al menos eliminar el error, aunque todavía no estoy recibiendo ningún correo enviado…

EDITAR: Puedo confirmar que el puerto 25 funciona correctamente (al igual que el 587, pero desafortunadamente mi servidor smtp no expone el 587).

No recibí ningún correo antes debido a que la dirección IP del servidor Discourse fue temporalmente puesta en lista negra por el servidor smtp debido a demasiados intentos fallidos.

[RGJ (Richard - Communiteq)]

Creo que tienes razón.

Y resulta que no eres el primero… al buscar DISCOURSE_SMTP_PORT 465 encontré un montón de problemas similares.

• Not able to send email Net::ReadTimeout - #18 by Stranik
• Email not working but i can access smtp server from container
• DigitalOcean + Siteground Email via port 465 won’t work (2525 will work)
• Problem with SMTP configuration
• Post-install, Curl can send email, but Discourse cannot. Help to fix?
• Mail problem on discourse with reverse proxy
• Can't setup SMTP with SSL/TLS
• SMTP email issue Net::Timeout - #3 by neounix

El último contiene un enlace a la (posible) solución.

Con este parche, es posible configurar
DISCOURSE_SMTP_FORCE_TLS=true para usar TLS implícito en el puerto 465

[JammyDodger]

También he visto bastantes temas sobre el ‘problema 465’. Sin embargo, mi depuración de correo electrónico para cualquier cosa que no sea obvia no es muy buena, así que he estado citando la guía de solución de problemas:

@Discourse

Selección del puerto SMTP de correo electrónico (¿Usando 465?)

La capacidad de poder AUTENTICARSE usando ‘telnet’ es extremadamente importante en los primeros pasos de la solución de problemas de correo electrónico.

El puerto 465 (SMTP sobre SSL) está en gran medida obsoleto en favor de STARTTLS en el puerto 25. Es posible que necesites probar puertos alternativos como el puerto 2525 o el puerto 587 (Envío de correo) cuando las cosas no parezcan funcionar como se esperaba.

¿Hay algo que podamos añadir a eso para ayudar a la gente?

[RGJ (Richard - Communiteq)]

@JammyDodger

¿Hay algo que podamos añadir a eso para ayudar a la gente?

Bueno, si @schungx puede confirmar que DISCOURSE_SMTP_FORCE_TLS=true es realmente una solución, podemos añadirla.

[schungx (Stephen Chung)]

@RGJ

Bueno, si @schungx puede confirmar que DISCOURSE_SMTP_FORCE_TLS=true es realmente una solución, podemos añadirla.

¡Lo intentaré de inmediato!

EDITAR: @RGJ ¡Puedo confirmar que DISCOURSE_SMTP_FORCE_TLS: true en app.yml resuelve el problema con éxito!

Sugiero una advertencia en negrita que diga Si usas el puerto 465, configura DISCOURSE_SMTP_FORCE_TLS: true, ¿o no debería Discourse ser lo suficientemente inteligente como para detectarlo?