Ampliando el tiempo de espera de SMTP

¿Hay alguna forma de extender el intervalo de tiempo de espera cuando Discourse espera que el servidor SMTP devuelva el acuse de recibo de que un mensaje de correo electrónico ha sido enviado? Alternativamente, ¿hay alguna forma de configurar Discourse para que no requiera este acuse de recibo?

Estoy experimentando un problema en el que mi instancia de Discourse está generando correos electrónicos duplicados. Discourse está recibiendo un error Net::Timeout al enviar correos electrónicos para su entrega. Mi proveedor de correo electrónico está entregando los correos electrónicos, pero Discourse no lo sabe y procede a reenviar los correos electrónicos. Esto se repite sin fin.

Recientemente agregamos la personalización del tiempo de espera SMTP, pero eso es para establecer la conexión SMTP real:

Parece que tu problema ocurre después de que se establece la conexión y el problema es el tiempo de espera de la transacción de envío.

2 Me gusta

Sí, por lo que puedo decir. La conexión se establece, se envía el mensaje de correo electrónico, pero se informa un error Net::Timeout después de eso.

Usando el script discourse_doctor, veo el ID del mensaje devuelto cuando la transición es exitosa y el error Net::Timeout cuando falla.

Este problema surgió después de actualizar a Discourse 2.9.0.beta5. Supongo que Discourse se volvió menos permisivo con este error con esa actualización.

No pude encontrar ningún cambio relacionado en los gems de ruby mail y net/smtp. ¿Quizás su servidor SMTP se está comportando mal? ¿Sería posible que migrara a otro?

1 me gusta

Gracias por revisar. Estoy de acuerdo, mi proveedor de correo electrónico parece ser la causa del problema, ya que no responde lo suficientemente rápido después de enviar un correo electrónico. Solo puedo suponer que el problema está relacionado de alguna manera con la carga, en el sentido de que algunos días no experimento el problema.

Cambiar de proveedor de correo electrónico es un desafío importante por varias razones. Encontrar una manera de configurar Discourse para solucionar esto es la solución más atractiva.

Moverse a un nuevo proveedor de correo parece ser la única solución a este problema, pero eso requiere que reconfigure el proveedor de correo para todo mi dominio, lo cual es una tarea que me gustaría evitar.

¿Hay algún cambio que pueda hacer en el código de Discourse que maneje el envío de correos para que ignore los fallos en el envío de correo, como lo hacía en el pasado? No soy un desarrollador de Rails, así que no estoy seguro de por dónde empezar. No quiero romper mi capacidad de aceptar futuras actualizaciones de Discourse.

¿En qué basas la declaración anterior? Realmente solo puedes recibir correo contra un conjunto de infraestructura por dominio/subdominio, pero varios servicios pueden reenviar correos electrónicos en su nombre.

Alternativamente, también podrías crear un nuevo subdominio dedicado a tu instancia, lo que ni siquiera requiere una reconstrucción para configurarlo.

En un momento del pasado intenté esto y lo configuré mal y no pude resolverlo, de ahí mi reticencia a cambiar nada. También preferiría que los correos electrónicos de Discourse se originaran en el dominio de mi empresa, pero dado que eso ya no va a funcionar, intentaré de nuevo hacer lo que sugieres y usar un subdominio para los correos salientes.

He creado un subdominio de correo electrónico usando RackSpace Cloud y he confirmado que puedo enviar correos a través de él desde mi Mac usando Apple Mail y curl. También he confirmado que puedo enviar correos desde mi servidor usando curl. Sin embargo, estoy recibiendo este error de discourse-doctor:

Testing sending to support@latenightsw.com using secure.emailsrvr.com:465, username:username with plain auth.
======================================== ERROR ========================================
                                    UNEXPECTED ERROR

Net::ReadTimeout

====================================== SOLUTION =======================================
This is not a common error. No recommended solution exists!

Please report the exact error message above to https://meta.discourse.org/
(And a solution, if you find one!)

Mi archivo app.yml contiene estas configuraciones:

  DISCOURSE_SMTP_ADDRESS: secure.emailsrvr.com         # (mandatory)
  DISCOURSE_SMTP_PORT: 465                             # (optional)
  DISCOURSE_SMTP_USER_NAME: username      # (optional)
  DISCOURSE_SMTP_PASSWORD: password               # (optional, WARNING the char '#' in pw can cause problems!)

  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (optional, default true)

Esto coincide con la configuración documentada aquí.

He intentado establecer DISCOURSE_SMTP_ENABLE_START_TLS en false. Otras publicaciones sobre el error Net::ReadTimeout sugieren probar esta configuración, pero no marcó ninguna diferencia:

  DISCOURSE_SMTP_AUTHENTICATION: "login"
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

¿Cómo puedo diagnosticar esta falla?

@Falco ¿Cómo hago este cambio en mi configuración de Discourse? No encuentro ninguna documentación para una configuración que pueda agregar a mi archivo app.yml.