Prolonger le délai d'attente SMTP

Existe-t-il un moyen de prolonger l’intervalle de délai d’attente lorsque Discourse attend que le serveur SMTP renvoie l’accusé de réception qu’un message électronique a été soumis ? Alternativement, existe-t-il un moyen de configurer Discourse pour ne pas exiger cet accusé de réception.

Je rencontre un problème où mon instance Discourse génère des e-mails en double. Discourse reçoit une erreur Net::Timeout lors de la soumission d’e-mails pour livraison. Mon fournisseur de messagerie livre effectivement les e-mails, mais Discurse ne le sait pas et continue de renvoyer les e-mails. Cela se répète à l’infini.

Nous avons récemment ajouté la personnalisation du délai d’attente SMTP, mais cela concerne la connexion SMTP réelle :

Il semble que votre problème survienne après l’établissement de la connexion et que le problème concerne le délai d’attente de la transaction d’envoi ?

2 « J'aime »

Oui, d’après ce que je peux dire. La connexion est établie, le message électronique est soumis mais une erreur Net::Timeout est signalée après cela.

En utilisant le script discourse_doctor, je vois l’ID du message renvoyé lorsque la transition réussit et l’erreur Net::Timeout lorsqu’elle échoue.

Ce problème est apparu après la mise à jour vers Discourse 2.9.0.beta5. Je suppose que Discourse est devenu moins tolérant à cette erreur avec cette mise à jour.

Je n’ai trouvé aucun changement lié dans les gems ruby mail et net/smtp. Votre serveur SMTP se comporte peut-être mal ? Serait-il possible pour vous d’en migrer vers un autre ?

1 « J'aime »

Merci d’avoir vérifié. Je suis d’accord, mon fournisseur de messagerie semble être la cause du problème car il ne répond pas assez rapidement après la soumission d’un e-mail. Je ne peux que supposer que le problème est lié à la charge, dans le sens où certains jours, je ne rencontre pas le problème.

Changer de fournisseur de messagerie représente un défi important pour plusieurs raisons. Trouver un moyen de configurer Discourse pour contourner ce problème est la solution la plus attrayante.

Passer à un nouveau fournisseur de messagerie semble être la seule solution à ce problème, mais cela nécessite de reconfigurer le fournisseur de messagerie pour mon domaine entier, ce qui est une tâche que je souhaiterais éviter.

Existe-t-il une modification que je puisse apporter au code de Discourse gérant l’envoi d’e-mails pour qu’il ignore les échecs de soumission d’e-mails, comme il le faisait auparavant ? Je ne suis pas un développeur Rails, donc je ne sais même pas par où commencer. Je ne veux pas compromettre ma capacité à accepter les futures mises à jour de Discourse.

Sur quoi basez-vous la déclaration ci-dessus ? Vous ne pouvez réellement recevoir des e-mails que sur un seul ensemble d’infrastructures par domaine/sous-domaine, mais plusieurs services peuvent relayer les e-mails en son nom.

Alternativement, vous pourriez également créer un nouveau sous-domaine dédié à votre instance, ce qui ne nécessite même pas de reconstruction pour être configuré.

J’ai essayé cela à un moment donné dans le passé et j’ai mal configuré les choses et je n’ai pas pu le comprendre, d’où ma réticence à changer quoi que ce soit. Je préférerais également que les e-mails Discourse proviennent de mon domaine d’entreprise, mais étant donné que cela ne fonctionnera plus, je vais réessayer de faire ce que vous suggérez et d’utiliser un sous-domaine pour les e-mails sortants.

J’ai créé un sous-domaine d’e-mail en utilisant RackSpace Cloud et j’ai confirmé que je peux envoyer des e-mails via celui-ci depuis mon Mac en utilisant Apple Mail et curl. J’ai également confirmé que je peux envoyer des e-mails depuis mon serveur en utilisant curl. Cependant, j’obtiens cette erreur 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!)

Mon fichier app.yml contient ces paramètres :

  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)

Cela correspond à la configuration documentée ici.

J’ai essayé de définir DISCOURSE_SMTP_ENABLE_START_TLS sur false. D’autres publications concernant l’erreur Net::ReadTimeout suggèrent d’essayer ces paramètres, mais cela n’a fait aucune différence :

  DISCOURSE_SMTP_AUTHENTICATION: "login"
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none

Comment puis-je diagnostiquer cet échec ?

@Falco comment puis-je apporter cette modification à ma configuration Discourse ? Je ne trouve aucune documentation pour un paramètre que je peux ajouter à mon fichier app.yml.