Les e-mails n'arrivent plus à être envoyés - fin de fichier atteinte

Bonjour à tous, et désolé si cela ressemble à certains des autres messages mentionnant cette erreur.

Depuis quatre jours, aucun e-mail n’est envoyé, et l’e-mail de test échoue également.

J’ai parcouru les sujets existants similaires, mais dans mon cas, rien (à ma connaissance) n’a changé, et les e-mails ont cessé de fonctionner après avoir fonctionné pendant des mois sans problème.

Nous utilisons un hébergement chez Digital Ocean et configurons le relais SMTP de G Suite pour relayer les e-mails depuis l’adresse IP du droplet.

L’erreur exacte affichée dans Sidekiq est un peu plus détaillée que celle que je reçois de discourse-doctor.

Jobs::HandledExceptionWrapper: Wrapped EOFError: end of file reached

discourse-doctor indique simplement : UNEXPECTED ERROR: end of file reached

J’ai également pu confirmer la connexion au serveur avec :

telnet smtp-relay.gmail.com 587

Je me souviens d’une brève interruption il y a plusieurs mois où les e-mails ont cessé d’être envoyés, mais je ne me rappelle pas de l’erreur (à cette époque, j’ai pu réessayer depuis Sidekiq sans aucun problème).

Quelqu’un a-t-il rencontré quelque chose de similaire ou possède-t-il une configuration similaire qui fonctionne encore ? Merci d’avance !

Je n’ai pas encore de conseils utiles, mais je rencontre exactement le même problème avec exactement la même configuration : un droplet DigitalOcean, envoi d’e-mails via smtp-relay.gmail.com, et des erreurs EOF.

Sidekiq signale ce qui suit :

Jobs::HandledExceptionWrapper: Wrapped EOFError: end of file reached

En consultant /logs, j’obtiens une trace d’appel (backtrace) pour l’échec, mais rien ne ressort immédiatement comme utile.

Informations :

Job exception: end of file reached

Trace d’appel :

/usr/local/lib/ruby/2.7.0/net/protocol.rb:225:in `rbuf_fill'
/usr/local/lib/ruby/2.7.0/net/protocol.rb:191:in `readuntil'
/usr/local/lib/ruby/2.7.0/net/protocol.rb:201:in `readline'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:944:in `recv_response'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:929:in `block in getok'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:954:in `critical'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:927:in `getok'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:826:in `helo'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:600:in `do_helo'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:554:in `do_start'
/usr/local/lib/ruby/2.7.0/net/smtp.rb:518:in `start'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:109:in `start_smtp_session'
mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb:100:in `deliver!'
mail-2.7.1/lib/mail/message.rb:2159:in `do_delivery'
mail-2.7.1/lib/mail/message.rb:260:in `block in deliver'
actionmailer-6.0.3.3/lib/action_mailer/base.rb:589:in `block in deliver_mail'
activesupport-6.0.3.3/lib/active_support/notifications.rb:180:in `block in instrument'
activesupport-6.0.3.3/lib/active_support/notifications/instrumenter.rb:24:in `instrument'
activesupport-6.0.3.3/lib/active_support/notifications.rb:180:in `instrument'
actionmailer-6.0.3.3/lib/action_mailer/base.rb:587:in `deliver_mail'
mail-2.7.1/lib/mail/message.rb:260:in `deliver'
actionmailer-6.0.3.3/lib/action_mailer/message_delivery.rb:115:in `block in deliver_now'
actionmailer-6.0.3.3/lib/action_mailer/rescuable.rb:17:in `handle_exceptions'
actionmailer-6.0.3.3/lib/action_mailer/message_delivery.rb:114:in `deliver_now'
/var/www/discourse/lib/email/sender.rb:234:in `send'
/var/www/discourse/app/jobs/regular/user_email.rb:70:in `send_user_email'
/var/www/discourse/app/jobs/regular/user_email.rb:25:in `execute'
/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'
rails_multisite-2.5.0/lib/rails_multisite/connection_management.rb:76:in `with_connection'
/var/www/discourse/app/jobs/base.rb:221:in `block in perform'
/var/www/discourse/app/jobs/base.rb:217:in `each'
/var/www/discourse/app/jobs/base.rb:217:in `perform'
sidekiq-6.1.2/lib/sidekiq/processor.rb:196:in `execute_job'
sidekiq-6.1.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'
/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'
sidekiq-6.1.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'
sidekiq-6.1.2/lib/sidekiq/processor.rb:163:in `block in process'
sidekiq-6.1.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_retry.rb:111:in `local'
sidekiq-6.1.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'
sidekiq-6.1.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/processor.rb:257:in `stats'
sidekiq-6.1.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_logger.rb:13:in `call'
sidekiq-6.1.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'
sidekiq-6.1.2/lib/sidekiq/job_retry.rb:78:in `global'
sidekiq-6.1.2/lib/sidekiq/processor.rb:124:in `block in dispatch'
sidekiq-6.1.2/lib/sidekiq/logger.rb:10:in `with'
sidekiq-6.1.2/lib/sidekiq/job_logger.rb:33:in `prepare'
sidekiq-6.1.2/lib/sidekiq/processor.rb:123:in `dispatch'
sidekiq-6.1.2/lib/sidekiq/processor.rb:162:in `process'
sidekiq-6.1.2/lib/sidekiq/processor.rb:78:in `process_one'
sidekiq-6.1.2/lib/sidekiq/processor.rb:68:in `run'
sidekiq-6.1.2/lib/sidekiq/util.rb:15:in `watchdog'
sidekiq-6.1.2/lib/sidekiq/util.rb:24:in `block in safe_thread'

Environnement :

hostname	conversation-app
process_id	736
application_version	e6bbe9b5df4d86fe711aa8b1d886489d30875633
current_db	default
current_hostname	conversation.sevarg.net
job	Jobs::UserEmail
problem_db	default
time	12:42 pm
opts	
type	digest
user_id	30
current_site_id	default

discourse-doctor affiche un résultat général similaire :

==================== TEST DE COURRIER ====================
Pour un test robuste, obtenez une adresse sur http://www.mail-tester.com/
Ou envoyez simplement un message de test à vous-même.
Adresse e-mail pour le test de courrier ? ('n' pour ignorer) [[mon e-mail]] : 
Envoi du courrier à [mon e-mail]... 
Test de l'envoi vers [mon e-mail] en utilisant smtp-relay.gmail.com:587.
======================================== ERREUR ========================================
                                    ERREUR INATTENDUE

fin de fichier atteinte

====================================== SOLUTION =======================================
Ce n'est pas une erreur courante. Aucune solution recommandée n'existe !

Veuillez signaler le message d'erreur exact ci-dessus à https://meta.discourse.org/
(Et une solution, si vous en trouvez une !)
=======================================================================================

Je peux également me connecter au relais via telnet sur le port 587 (et envoyer un message de test manuellement – je n’avais pas fait ça depuis une décennie…), et je n’ai rien changé de ce dont je me souvienne récemment qui aurait pu affecter l’envoi de courriers.

Je suis complètement bloqué en ce qui concerne les nouveaux utilisateurs, etc., ce qui pose un problème car j’utilise également ce service pour les commentaires de blog. Je n’ai rien trouvé dans les journaux Google qui soit particulièrement utile, et je suis vraiment à court d’idées pour continuer le dépannage. Tout semble être configuré correctement, mais cela ne fonctionne simplement plus.

Eh bien, c’est assurément un soulagement de savoir que ma configuration n’est pas trop inhabituelle et que je ne suis pas seul dans mes ennuis. Je me demande, le problème a-t-il commencé il y a environ 5 jours pour vous aussi ? Peut-être qu’une mise à jour a été appliquée à un élément commun dans nos pipelines.

Merci de partager les détails et la trace d’exécution. Les miens étaient très similaires aux vôtres, et les erreurs étaient identiques.

Je n’ai pas tenté d’envoyer manuellement un e-mail via telnet, mais je soupçonne que cela fonctionnerait comme cela l’a fait pour vous..

Je suis dans la même situation, et nous activons manuellement les nouveaux utilisateurs pour le moment (heureusement, cela ne concerne que quelques-uns par jour). Étant donné que je n’ai rien changé dans G Suite, Digital Ocean ou la configuration de Discourse, je suis réticent à commencer à modifier quoi que ce soit sans pouvoir identifier ce qui cause réellement le problème. :confused:

Le premier vrai pic d’échecs côté Sidekiq s’est produit le 14 janvier, donc… il y a 5 jours. Avant cela, j’avais eu quelques échecs aléatoires liés à des adresses e-mail incorrectes ou similaires, mais rien qui augmentait rapidement.

J’ai essayé de recréer les paramètres de relais dans la Console d’administration Google et de les modifier (y compris ceux qui devraient être entièrement ouverts), sans aucun changement. J’ai également essayé différents ports pour l’envoi de courriers, toujours sans changement.

De plus, je n’ai rien modifié, à ma connaissance, il y a 5 jours. :confused:

Autre signalement de problèmes : DigitalOcean → smtp-relay.gmail.com

Est-ce que quelqu’un peut facilement tester depuis une VM autre que DigitalOcean ? GCE ou autre chose ?

Je viens de lancer une installation de Discourse sur GCE avec mes identifiants et j’ai obtenu la même erreur (après avoir configuré mon relais pour se fier uniquement à l’authentification).

======================================== ERREUR ========================================
                                    ERREUR INATTENDUE

fin de fichier atteinte

====================================== SOLUTION =======================================
Ce n'est pas une erreur courante. Aucune solution recommandée n'existe !

Veuillez signaler le message d'erreur exact ci-dessus à https://meta.discourse.org/
(Et une solution, si vous en trouvez une !)
=======================================================================================

La configuration de l’authentification basée sur l’adresse IP pour le relais a donné les mêmes résultats. Je ne pense donc pas qu’il s’agisse d’un problème spécifique à DigitalOcean…

Malheureusement, le « dépannage des problèmes d’e-mail Ruby/Rails » dépasse mes compétences actuelles… des suggestions ?

Y a-t-il une chance que ce soit un problème SMTP Gmail ?

On dirait bien. Je ne sais pas comment résoudre le problème, et mes tentatives jusqu’à présent n’ont abouti à rien. Ils ont probablement modifié quelque chose, Discourse ne peut pas le gérer, et bien sûr, il n’y a aucun support.

J’ai déjà eu de la chance sur ces forums pour aider à identifier et résoudre des problèmes. Je ne sais pas pourquoi celui-ci est si silencieux.

Il est possible qu’il s’agisse d’un problème SMTP lié à Gmail/G Suite, mais @Syonyk a mentionné qu’il a pu envoyer manuellement un e-mail via telnet sur son droplet.

Je n’ai pas assez d’expérience pour savoir comment G Suite interprète le trafic envoyé depuis le site par rapport aux messages envoyés manuellement, mais cela semble indiquer que le problème vient du service qui envoie l’e-mail vers smtp-relay.gmail, et non du relais lui-même.

Pour information, l’adresse IP du droplet est également explicitement autorisée dans les paramètres d’administration de G Suite, et je n’ai modifié (et je n’ai toujours pas modifié) aucun paramètre dans l’un des services depuis plusieurs mois.

La seule fois où j’ai observé un phénomène similaire, cela n’a duré qu’un jour (peut-être deux — la page n’était pas très fréquentée à l’époque, donc je ne l’aurais probablement pas remarqué si cela avait duré plus longtemps), mais le problème semblait s’être résolu assez rapidement.

Sans une bonne trace de la conversation SMTP provenant de Discourse, je ne sais pas comment poursuivre le dépannage et je ne sais pas comment obtenir ces traces.

Existe-t-il un moyen de confirmer le nombre d’e-mails que j’envoie via Discourse par mois ? Si je dois passer à un autre relais SMTP, j’aurais besoin de connaître le budget nécessaire. C’est extrêmement frustrant.

Sous /admin/email/sent sur votre instance, vous devriez pouvoir voir ce qui a été envoyé et estimer l’utilisation à partir de là.

Hm…

J’ai lancé tcpdump sur le serveur et exécuté discourse-doctor. Voici ce que j’ai trouvé dans la sortie…

...
0x0030:  d10f f8e4 4548 4c4f 206c 6f63 616c 686f  ....EHLO.localho
	0x0040:  7374 0d0a                                st..
...
	0x0030:  de62 f0c3 3432 3120 342e 372e 3020 5472  .b..421.4.7.0.Tr
	0x0040:  7920 6167 6169 6e20 6c61 7465 722c 2063  y.again.later,.c
	0x0050:  6c6f 7369 6e67 2063 6f6e 6e65 6374 696f  losing.connectio
	0x0060:  6e2e 2028 4548 4c4f 2920 6a31 3673 6d34  n..(EHLO).j16sm4
	0x0070:  3831 3932 3976 736d 2e31 202d 2067 736d  81929vsm.1.-.gsm
	0x0080:  7470 0d0a                                tp..

Et, ce qui est important, je peux reproduire cet échec avec telnet.

root@conversation:~# telnet smtp-relay.gmail.com 587
Trying 74.125.137.28...
Connected to smtp-relay.gmail.com.
Escape character is '^]'.
220 smtp-relay.gmail.com ESMTP ls8sm507258pjb.6 - gsmtp
ehlo localhost.localdomain
421 4.7.0 Try again later, closing connection. (EHLO) ls8sm507258pjb.6 - gsmtp
Connection closed by foreign host.

Si j’envoie un vrai domaine, j’obtiens la réponse attendue.

root@conversation:~# telnet smtp-relay.gmail.com 587
Trying 74.125.137.28...
Connected to smtp-relay.gmail.com.
Escape character is '^]'.
220 smtp-relay.gmail.com ESMTP p10sm668563uaw.3 - gsmtp
ehlo conversation.sevarg.net
250-smtp-relay.gmail.com at your service, [64.227.96.27]
250-SIZE 157286400
250-8BITMIME
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8

La question est donc : comment faire en sorte que Discourse envoie une chaîne de domaine correcte dans l’EHLO ?

Je ne sais pas si c’est le seul problème, mais cela semble prometteur à investiguer.

C’est tellement étrange. D’où cela a-t-il pu surgir soudainement ? Je n’ai effectué aucune mise à jour.

Ce n’est pas une régression récente, cela fonctionne ainsi depuis un moment. Google a modifié quelque chose.

discourse-doctor appelle le test situé dans /var/www/discourse/lib/tasks/emails.rake - si vous êtes dans l’image Docker.

J’ai modifié :

Net::SMTP.start(smtp[:address], smtp[:port], 'localhost', smtp[:user_name], smtp[:password], smtp[:authentication])

par

Net::SMTP.start(smtp[:address], smtp[:port], 'conversation.sevarg.net', smtp[:user_name], smtp[:password], smtp[:authentication])

Maintenant, j’obtiens une erreur différente.

======================================== ERREUR ========================================
                                    ERREUR INATTENDUE

503 5.5.1 mauvaise séquence de commandes e190sm562849qkd.9 - gsmtp


====================================== SOLUTION =======================================
Il ne s'agit pas d'une erreur courante. Aucune solution recommandée n'existe !

Veuillez signaler le message d'erreur exact ci-dessus sur https://meta.discourse.org/
(Et une solution, si vous en trouvez une !)
=======================================================================================

MAIS : il est important de noter que le tcpdump montre un flux qui ressemble à quelque chose de correct (assez).

22:33:48.393862 IP 64.227.96.27.54610 > 74.125.137.28.587: Flags [P.], seq 1:31, ack 59, win 502, options [nop,nop,TS val 3732187266 ecr 3508646052], length 30
	0x0000:  4500 0052 d4d6 4000 3f06 f237 40e3 601b  E..R..@.?..7@.`.
	0x0010:  4a7d 891c d552 024b 01b4 04a4 94ce dcc7  J}...R.K........
	0x0020:  8018 01f6 74dc 0000 0101 080a de74 a882  ....t........t..
	0x0030:  d121 b0a4 4548 4c4f 2063 6f6e 7665 7273  .!..EHLO.convers
	0x0040:  6174 696f 6e2e 7365 7661 7267 2e6e 6574  ation.sevarg.net
	0x0050:  0d0a                                     ..
22:33:48.408832 IP 74.125.137.28.587 > 64.227.96.27.54610: Flags [.], ack 31, win 256, options [nop,nop,TS val 3508646067 ecr 3732187266], length 0
	0x0000:  4500 0034 5e5d 0000 2b06 bccf 4a7d 891c  E..4^]..+...J}..
	0x0010:  40e3 601b 024b d552 94ce dcc7 01b4 04c2  @.`..K.R........
	0x0020:  8010 0100 a8ae 0000 0101 080a d121 b0b3  .............!..
	0x0030:  de74 a882                                .t..
22:33:48.469560 IP 74.125.137.28.587 > 64.227.96.27.54610: Flags [P.], seq 59:234, ack 31, win 256, options [nop,nop,TS val 3508646128 ecr 3732187266], length 175
	0x0000:  4500 00e3 5e8a 0000 2b06 bbf3 4a7d 891c  E...^...+...J}..
	0x0010:  40e3 601b 024b d552 94ce dcc7 01b4 04c2  @.`..K.R........
	0x0020:  8018 0100 929f 0000 0101 080a d121 b0f0  .............!..
	0x0030:  de74 a882 3235 302d 736d 7470 2d72 656c  .t..250-smtp-rel
	0x0040:  6179 2e67 6d61 696c 2e63 6f6d 2061 7420  ay.gmail.com.at.
	0x0050:  796f 7572 2073 6572 7669 6365 2c20 5b36  your.service,.[6
	0x0060:  342e 3232 372e 3936 2e32 375d 0d0a 3235  4.227.96.27]..25
	0x0070:  302d 5349 5a45 2031 3537 3238 3634 3030  0-SIZE.157286400
	0x0080:  0d0a 3235 302d 3842 4954 4d49 4d45 0d0a  ..250-8BITMIME..
	0x0090:  3235 302d 5354 4152 5454 4c53 0d0a 3235  250-STARTTLS..25
	0x00a0:  302d 454e 4841 4e43 4544 5354 4154 5553  0-ENHANCEDSTATUS
	0x00b0:  434f 4445 530d 0a32 3530 2d50 4950 454c  CODES..250-PIPEL
	0x00c0:  494e 494e 470d 0a32 3530 2d43 4855 4e4b  INING..250-CHUNK
	0x00d0:  494e 470d 0a32 3530 2053 4d54 5055 5446  ING..250.SMTPUTF
	0x00e0:  380d 0a                                  8..

Ainsi, au minimum, l’envoi de “EHLO localhost” ou “EHLO localhost.localdomain” fait partie du problème.

Maintenant, comment diable peut-on signaler un problème P0 aux vrais développeurs ?

J’ai certainement vu ces gars-là sur les forums. D’après ce que je peux voir, ils les surveillent assez de près. Je dirais GitHub, mais les problèmes semblent désactivés pour le dépôt.

D’accord.

Il s'agit d'un e-mail de test provenant de

https://conversation.sevarg.net

La délivrabilité des e-mails est complexe. Voici quelques éléments importants que vous devriez vérifier en premier :

Je viens de démontrer une correction, mais je ne sais pas comment la remonter en amont.

cd /var/discourse
./launcher enter app
vim ./vendor/bundle/ruby/2.7.0/gems/mail-2.7.1/lib/mail/network/delivery_methods/smtp.rb

Vous devez trouver la section suivante :

    DEFAULTS = {
      :address              => 'localhost',
      :port                 => 25,
      :domain               => 'localhost.localdomain',
      :user_name            => nil,
      :password             => nil,
      :authentication       => nil,
      :enable_starttls      => nil,
      :enable_starttls_auto => true,
      :openssl_verify_mode  => nil,
      :ssl                  => nil,
      :tls                  => nil,
      :open_timeout         => nil,
      :read_timeout         => nil
    }

Modifiez les lignes relatives au domaine.

    DEFAULTS = {
      :address              => 'conversation.sevarg.net',
      :port                 => 25,
      :domain               => 'conversation.sevarg.net',
      :user_name            => nil,
      :password             => nil,
      :authentication       => nil,
      :enable_starttls      => nil,
      :enable_starttls_auto => true,
      :openssl_verify_mode  => nil,
      :ssl                  => nil,
      :tls                  => nil,
      :open_timeout         => nil,
      :read_timeout         => nil
    }

Je ne sais pas laquelle est importante, mais modifier les deux a résolu le problème. Utilisez bien sûr votre propre domaine…

Quitez l’environnement de l’application.

./launcher restart app

Elle devrait maintenant pouvoir envoyer des e-mails.

Je m’attends à ce que cela ne survive pas aux mises à jour.

Cependant, j’envoie et reçois désormais des e-mails comme prévu.

Développeurs ? Plz2fix ?

Suite au bug que j’ai signalé, veuillez essayer ce qui suit :

Ajoutez

DISCOURSE_SMTP_DOMAIN: [votre domaine d'installation]

dans votre fichier app.yml (/var/discourse/containers/app.yml, très probablement)

Ensuite, reconstruisez l’application (cd /var/discourse; ./launcher rebuild app) et essayez d’envoyer des e-mails.

Pour être clair, DISCOURSE_SMTP_DOMAIN correspond-il au domaine de mon serveur Discourse ou au domaine de l’e-mail ?

Par exemple, mon serveur se trouve sur le sous-domaine community.acescentral.com et mes e-mails proviennent de admin@acescentral.com. Donc, DISCOURSE_SMTP_DOMAIN est-il le domaine principal acescentral.com ou le sous-domaine community ?

Merci beaucoup d’avoir été aussi tenace dans la recherche de cette solution.