SMTP Net::ReadTimeout senza relazione con problemi di rete o di accesso - l'host SMTP è semplicemente lento

Funzionalità
1

Ciao,

da diverse settimane l’invio di email dalla mia istanza Discourse non funziona. Le impostazioni SMTP non sono cambiate, il test curl funziona ancora ma è notevolmente lento. Il server SMTP del nostro hoster (che dobbiamo utilizzare per inviare email) ha un tempo di invio costante di 7 secondi.

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

Ho confrontato questo con il nostro server di posta interno con meno di 1 secondo per email. I 7 secondi dell’hoster di posta non sarebbero un vero problema, ma non sono riuscito a identificare un’impostazione per aumentare il timeout (apparentemente hardcoded?) di 5 secondi. L’open_timeout e, a mio parere, il più rilevante read_timeout sono visibili anche nell’interfaccia di test su /admin/email:

screenshots
screenshots707×842 34.6 KB

  • I tempi nel container dell’app Docker sono identici a un test locale o a un test sull’host Docker.
  • Le email inviate tramite cURL vengono consegnate correttamente (dopo l’attesa di 7 secondi + un batter d’occhio).
  • Per motivi di privacy, i soliti workaround come sendgrid, mailgun, ecc. purtroppo non sono un’opzione.
  • Forse un passaggio ad ActionMailer 7.0.x ha innescato questo problema per me?

Grazie per qualsiasi idea su come configurare read_timeout.

1 Mi Piace
Cannot send email - problem with port 465
2

Per questo è necessario aggiungere quelle nuove impostazioni su

Quindi dovrebbe apparire così

  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
    }

Puoi fare una pull request con le modifiche?

2 Mi Piace
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

Ciao @Falco,

grazie per la tua rapida risposta. Hai ragione, queste modifiche sono effettive:

screenshot
screenshot571×215 8.85 KB

  • Il nuovo timeout da app.yml è visibile
  • Le email possono essere inviate.

Dato che il mio Ruby è praticamente inesistente, farò del mio meglio per preparare la pull request e ti ringrazio già molto per il tuo aiuto e per Discourse in generale.

Cordiali saluti

Roland

2 Mi Piace
4

La PR è online: Allow configuration of smtp timeout settings by rolandkoller · Pull Request #17863 · discourse/discourse · GitHub

Sarei grato per qualsiasi suggerimento su come/se posso migliorare la PR.

4 Mi Piace
5

Abbiamo solo bisogno di una firma CLA nel PR per poterlo unire.

2 Mi Piace
6

Scusa, ho avuto un weekend lungo. Fatto.

7

A titolo informativo, lo fanno apposta per scoraggiare gli spammer. La maggior parte degli strumenti automatici anti-spam ha anche un timeout di 5 secondi.

1 Mi Piace
8

Mi aspetto esattamente questo, poiché il ritardo sul lato del server SMTP è troppo omogeneo. Quindi la correzione suggerita da @Falco che ora è in PR#17863 potrebbe essere rilevante per più utenti.

C’è un errore nel test unitario di core frontend (Headless Firefox). Sono lontano dal sapere cosa sta succedendo, ma non mi aspetterei che questo fosse innescato dal nostro cambiamento qui.

1 Mi Piace
9

Grazie per la PR e per il test. È stata unita.

1 Mi Piace
10

Questo argomento è stato chiuso automaticamente dopo 4 giorni. Non sono più ammessi nuovi messaggi.