Problema de correo electrónico SMTP Net::Timeout

Hola, he estado intentando solucionar mi problema de SMTP y no se envían los correos electrónicos. Cuando ejecuto el comando ./discourse-doctor, me da un error Net::Timeout.

Gracias de antemano por la ayuda.

Sección smtp de app.yml

DISCOURSE_SMTP_ADDRESS: plesk.oxide.host
DISCOURSE_SMTP_PORT: 465
DISCOURSE_SMTP_USER_NAME: no-reply@kyekillerbot.xyz
DISCOURSE_SMTP_PASSWORD: password
DISCOURSE_SMTP_ENABLE_START_TLS: true # (opcional, por defecto true)
DISCOURSE_SMTP_AUTHENTICATION: login

He probado con telnet y se conecta correctamente al dominio SMTP.

¿Has probado a comentar esta línea? No creo que el puerto 465 admita STARTTLS.

En cuanto al puerto 465, consulta el RFC 8314:

Según este RFC, tanto el puerto 465 como el 587 son puertos válidos para un agente de envío de correo SMTP (MSA).

El puerto 465 requiere la negociación de TLS/SSL al establecer la conexión, mientras que el puerto 587 utiliza STARTTLS si se decide negociar TLS.

El registro de la IANA se ha actualizado para permitir el uso legítimo del puerto 465 para este propósito.

Para un retransmisor de correo SMTP, solo se utiliza el puerto 25, por lo que STARTTLS es la única forma de usar TLS con retransmisión de correo.

@kyekiller, deberías considerar probar esta configuración (establecida en false) si vas a usar el puerto 465:

DISCOURSE_SMTP_ENABLE_START_TLS: false

Comentar esta línea probablemente no ayude mucho, ya que directamente en los archivos de configuración del contenedor de Discourse, el valor predeterminado de esta opción es true; por lo tanto, aunque comentes esta línea, seguirá establecida en true:

#DISCOURSE_SMTP_ENABLE_START_TLS: true    # (opcional, predeterminado true)

Espero que esto ayude (HTH).

Consulta también (del RFC):

Cuando se establece una conexión TCP para el servicio “submissions” (puerto predeterminado 465), el handshake de TLS comienza inmediatamente. Los clientes DEBEN implementar el mecanismo de validación de certificados descrito en [RFC7817]. Una vez establecida la sesión TLS, los datos del protocolo de envío de mensajes [RFC6409] se intercambian como datos de aplicación TLS para el resto de la conexión TCP. (Nota: El nombre del servicio “submissions” se define en la Sección 7.3 de este documento y sigue la convención habitual de que el nombre de un servicio apilado sobre TLS implícito consiste en el nombre del servicio tal como se usa sin TLS, con una “s” añadida al final). El mecanismo STARTTLS en el puerto 587 está relativamente ampliamente implementado debido a la situación con el puerto 465 (discutida en la Sección 7.3). Esto difiere de los servicios IMAP y POP, donde el TLS implícito está más ampliamente implementado en servidores que STARTTLS. Es deseable migrar los protocolos principales utilizados por el software MUA hacia el TLS implícito con el tiempo, tanto por consistencia como por las razones adicionales discutidas en el Apéndice A. Sin embargo, para maximizar el uso del cifrado en el envío, es deseable soportar ambos mecanismos para el envío de mensajes sobre TLS durante un período de transición de varios años. Como resultado, los clientes y servidores DEBERÍAN implementar tanto STARTTLS en el puerto 587 como TLS implícito en el puerto 465 durante este período de transición. Obsérvese que no hay diferencia significativa entre las propiedades de seguridad de STARTTLS en el puerto 587 y el TLS implícito en el puerto 465 si las implementaciones son correctas y si tanto el cliente como el servidor están configurados para exigir una negociación exitosa de TLS antes del envío de mensajes.

Nota: existen dos configuraciones predeterminadas relacionadas con TLS en los valores predeterminados de Discourse:

# mecanismo de autenticación smtp
smtp_authentication = plain

# habilitar cifrado TLS para conexiones smtp
smtp_enable_start_tls = true

# modo para verificar certificados del servidor smtp
# para deshabilitar, establecer en 'none'
smtp_openssl_verify_mode =

# forzar TLS implícito según RFC 8314 3.3
smtp_force_tls = false

Consulta también: