SMTP Net::ReadTimeout sin relación con problemas de red o de inicio de sesión - el host SMTP es simplemente lento

Característica
1

Hola,

Desde hace varias semanas, el envío de correos desde mi instancia de Discourse falla. La configuración SMTP no ha cambiado, la prueba con curl sigue funcionando pero es notablemente lenta. El servidor SMTP de nuestro proveedor (que necesitamos para enviar correos) tiene un tiempo de envío constante de 7 segundos.

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
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying <IP>...
* Connected to smtp.<HOST> (<IP>) port 587 (#0)
< 220 mailproxy1.<HOST> Dovecot ready.
> EHLO ecm2
< 250-mailproxy1.<HOST>
< 250-8BITMIME
< 250-AUTH PLAIN LOGIN
< 250-BURL imap
< 250-ENHANCEDSTATUSCODES
< 250-SIZE
< 250-STARTTLS
< 250 PIPELINING
> AUTH PLAIN
< 334 
> xxxxxx=
  0     0    0     0    0     0      0      0 --:--:--  0:00:06 --:--:--     0
< 235 2.7.0 Authentication successful
  0     0    0     0    0     0      0      0 --:--:--  0:00:07 --:--:--     0
> MAIL FROM:<mail@<DOMAIN>>
< 250 2.1.0 Ok
> RCPT TO:<ME>
< 250 2.1.5 Ok
> DATA
< 354 End data with <CR><LF>.<CR><LF>
} [89 bytes data]
100    89    0     0    0    89      0     11 --:--:--  0:00:07 --:--:--    20
< 250 2.0.0 Ok: queued as 356C3288C85
100    89    0     0    0    89      0     11 --:--:--  0:00:07 --:--:--    26
* Connection #0 to host smtp.<HOST> left intact

Comparé esto con nuestro servidor de correo interno con menos de 1 segundo por correo. Los 7 segundos del proveedor de correo no serían un problema real, pero no pude identificar una configuración para levantar el tiempo de espera (aparentemente codificado) de 5 segundos. El open_timeout y, a mi parecer, el más relevante read_timeout también son visibles en la interfaz de prueba en /admin/email:

screenshots
screenshots707×842 34.6 KB

  • Los tiempos en el contenedor de la aplicación docker son idénticos a una prueba local o a una prueba en el host docker.
  • Los correos enviados por curl se entregan correctamente (después de la espera de 7 segundos + un instante).
  • Por razones de privacidad, las soluciones alternativas habituales como sendgrid, mailgun, etc. lamentablemente no son una opción.
  • ¿Quizás un cambio a ActionMailer 7.0.x me provocó este problema?

Gracias por cualquier idea sobre cómo configurar read_timeout.

1 me gusta
Cannot send email - problem with port 465
2

Para ello es necesario añadir esas nuevas configuraciones en

Así se ve

  if GlobalSetting.smtp_address
    settings = {
      address: GlobalSetting.smtp_address,
      port: GlobalSetting.smtp_port,
      domain: GlobalSetting.smtp_domain,
      user_name: GlobalSetting.smtp_user_name,
      password: GlobalSetting.smtp_password,
      authentication: GlobalSetting.smtp_authentication,
      enable_starttls_auto: GlobalSetting.smtp_enable_start_tls,
+     open_timeout: GlobalSetting.smtp_open_timeout,
+     read_timeout: GlobalSetting.smtp_read_timeout
    }

¿Puedes hacer una pull request con los cambios?

2 Me gusta
Extending SMTP timeout
Issues with mail sending to SMTP relay
Severe Email Issue since last update a couple days ago - 3.4.0.beta4-dev
3

Hola @Falco,

Gracias por tu rápida respuesta. Tienes razón, estos cambios son efectivos:

screenshot
screenshot571×215 8.85 KB

  • Los nuevos tiempos de espera de app.yml son visibles.
  • Se pueden enviar correos electrónicos.

Dado que mi Ruby es prácticamente inexistente, haré todo lo posible para preparar la solicitud de extracción y ya estoy muy agradecido por tu ayuda y por Discourse en general.

Saludos cordiales,

Roland

2 Me gusta
4

La PR está en línea: Allow configuration of smtp timeout settings by rolandkoller · Pull Request #17863 · discourse/discourse · GitHub

Agradecería cualquier aporte sobre cómo/si puedo mejorar la PR.

4 Me gusta
5

Solo necesitamos una firma de CLA en el PR para poder fusionarlo.

2 Me gusta
6

Lo siento, tuve un fin de semana largo. Hecho.

7

Para tu información, lo hacen a propósito para disuadir a los spammers. La mayoría de las herramientas automatizadas de spam también tienen un tiempo de espera de 5 segundos.

1 me gusta
8

Espero exactamente esto, ya que el retraso en el lado del servidor SMTP es demasiado homogéneo. Por lo tanto, la corrección sugerida por @Falco que ahora está en PR#17863 puede ser relevante para más usuarios.

Hay un error en la prueba unitaria de core frontend (Headless Firefox). Estoy lejos de saber qué está pasando, pero no esperaría que esto fuera activado por nuestro cambio aquí.

1 me gusta
9

Gracias por la PR y las pruebas. Ya está fusionado.

1 me gusta
10

Este tema se cerró automáticamente después de 4 días. Ya no se permiten nuevas respuestas.