SMTP Net::ReadTimeout sans relation avec des problèmes de réseau ou de connexion - l'hôte SMTP est juste lent

Fonctionnalité
1

Bonjour,

depuis plusieurs semaines, l’envoi d’e-mails depuis mon instance Discourse échoue. Les paramètres SMTP sont inchangés, le test curl fonctionne toujours mais est notablement lent. Le serveur smtp de notre hébergeur (que nous devons utiliser pour envoyer des e-mails) a un temps d’envoi constant de 7 secondes.

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

J’ai comparé cela à notre serveur de messagerie interne avec moins d’une seconde par e-mail. Les 7 secondes de l’hébergeur de messagerie ne seraient pas un vrai problème, mais je n’ai pas réussi à identifier un paramètre pour lever le délai d’attente (apparemment codé en dur ?) de 5 secondes. L’open_timeout et, me semble-t-il, le read_timeout plus pertinent sont également visibles dans l’interface de test sur /admin/email :

screenshots
screenshots707×842 34.6 KB

  • Les timings dans le conteneur de l’application docker sont identiques à un test local ou à un test sur l’hôte docker.
  • Les e-mails envoyés par cURL sont livrés correctement (après l’attente de 7 secondes + un clin d’œil).
  • Pour des raisons de confidentialité, les solutions de contournement habituelles comme sendgrid, mailgun, etc. ne sont malheureusement pas une option.
  • Peut-être qu’un passage à ActionMailer 7.0.x a déclenché ce problème pour moi ?

Merci pour toute idée sur la façon de configurer read_timeout.

1 « J'aime »
Cannot send email - problem with port 465
2

Pour cela, il est nécessaire d’ajouter ces nouveaux paramètres sur

Donc, cela ressemble à

  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
    }

Pouvez-vous faire une pull request avec les modifications ?

2 « J'aime »
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

Salut @Falco,

Merci pour votre réponse rapide. Vous avez raison, ces changements sont effectifs :

screenshot
screenshot571×215 8.85 KB

  • Les nouveaux délais d’attente de app.yml sont visibles
  • Les e-mails peuvent être envoyés.

Comme mon Ruby est pratiquement inexistant, je ferai de mon mieux pour préparer la pull request et je vous suis déjà très reconnaissant pour votre aide et pour Discourse en général.

Cordialement,

Roland

2 « J'aime »
4

Le PR est en ligne : Allow configuration of smtp timeout settings by rolandkoller · Pull Request #17863 · discourse/discourse · GitHub

Je serais reconnaissant pour toute suggestion sur comment/si je peux améliorer le PR.

4 « J'aime »
5

Nous avons juste besoin d’une signature CLA dans la PR pour que nous puissions la fusionner.

2 « J'aime »
6

Désolé, j’ai eu un long week-end. Terminé.

7

Pour information, ils font cela exprès pour décourager les spammeurs. La plupart des outils anti-spam automatisés ont également un délai d’attente de 5 secondes.

1 « J'aime »
8

Je m’attends exactement à cela, car le délai du côté du serveur SMTP est trop homogène. Ainsi, la correction suggérée par @Falco qui est maintenant dans PR#17863 pourrait être pertinente pour plus d’utilisateurs.

Il y a une erreur dans le test unitaire core frontend (Headless Firefox). Je suis loin de savoir ce qui se passe, mais je ne m’attendrais pas à ce que cela soit déclenché par notre changement ici.

1 « J'aime »
9

Merci pour la PR et les tests. C’est maintenant fusionné.

1 « J'aime »
10

Ce sujet a été automatiquement fermé après 4 jours. Les nouvelles réponses ne sont plus autorisées.