Reply-by-Email fonctionnait, maintenant cassé

Notre fonctionnalité de réponse par e-mail a fonctionné pendant deux ans, puis a cessé de fonctionner il y a 17 jours sans raison apparente. J’ai consulté les journaux d’action du personnel pour cette période et il n’y a eu aucune modification de configuration pertinente, aucune mise à niveau et aucun nouveau plugin. Qu’est-ce qui a pu causer ce dysfonctionnement ?


Aucun e-mail reçu après le 30 septembre :


Ils ne sont pas non plus rejetés :


Rien d’évidemment lié dans les journaux d’erreurs, mais il y a ceci :

aws-sdk-core-3.112.1/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'

aws-sdk-s3-1.96.1/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'

aws-sdk-s3-1.96.1/lib/aws-sdk-s3/plugins/dualstack.rb:36:in `call'

aws-sdk-s3-1.96.1/lib/aws-sdk-s3/plugins/accelerate.rb:50:in `call'

aws-sdk-core-3.112.1/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:22:in `call'

aws-sdk-core-3.112.1/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'

aws-sdk-core-3.112.1/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'

aws-sdk-core-3.112.1/lib/seahorse/client/plugins/request_callback.rb:71:in `call'

aws-sdk-core-3.112.1/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'

aws-sdk-core-3.112.1/lib/seahorse/client/plugins/response_target.rb:24:in `call'

aws-sdk-core-3.112.1/lib/seahorse/client/request.rb:72:in `send_request'

aws-sdk-s3-1.96.1/lib/aws-sdk-s3/client.rb:1274:in `copy_object'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:61:in `block in vacate_legacy_prefix'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `each'

/var/www/discourse/lib/backup_restore/s3_backup_store.rb:60:in `vacate_legacy_prefix'

/var/www/discourse/app/jobs/onceoff/vacate_legacy_prefix_backups.rb:7:in `execute_onceoff'

/var/www/discourse/app/jobs/onceoff/onceoff.rb:25:in `execute'

/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'

rails_multisite-3.1.0/lib/rails_multisite/connection_management.rb:80: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.2.2/lib/sidekiq/processor.rb:196:in `execute_job'

sidekiq-6.2.2/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'

sidekiq-6.2.2/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'

/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'

sidekiq-6.2.2/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'

sidekiq-6.2.2/lib/sidekiq/middleware/chain.rb:143:in `invoke'

sidekiq-6.2.2/lib/sidekiq/processor.rb:163:in `block in process'

sidekiq-6.2.2/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'

sidekiq-6.2.2/lib/sidekiq/job_retry.rb:112:in `local'

sidekiq-6.2.2/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'

sidekiq-6.2.2/lib/sidekiq.rb:38:in `block in <module:Sidekiq>'

sidekiq-6.2.2/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'

sidekiq-6.2.2/lib/sidekiq/processor.rb:257:in `stats'

sidekiq-6.2.2/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'

sidekiq-6.2.2/lib/sidekiq/job_logger.rb:13:in `call'

sidekiq-6.2.2/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'

sidekiq-6.2.2/lib/sidekiq/job_retry.rb:79:in `global'

sidekiq-6.2.2/lib/sidekiq/processor.rb:124:in `block in dispatch'

sidekiq-6.2.2/lib/sidekiq/logger.rb:11:in `with'

sidekiq-6.2.2/lib/sidekiq/job_logger.rb:33:in `prepare'

sidekiq-6.2.2/lib/sidekiq/processor.rb:123:in `dispatch'

sidekiq-6.2.2/lib/sidekiq/processor.rb:162:in `process'

sidekiq-6.2.2/lib/sidekiq/processor.rb:78:in `process_one'

sidekiq-6.2.2/lib/sidekiq/processor.rb:68:in `run'

sidekiq-6.2.2/lib/sidekiq/util.rb:43:in `watchdog'

sidekiq-6.2.2/lib/sidekiq/util.rb:52:in `block in safe_thread'

Utilisation de l’interrogation manuelle, et non de l’interrogation POP3 :

image


Les expéditeurs essayant de répondre par e-mail ne reçoivent aucun avis de rejet ni message d’erreur.

L’envoi d’e-mails depuis le forum fonctionne parfaitement. Rien d’anormal côté AWS SES (bien que je ne pense pas que cela ait un lien avec la réponse par e-mail ?).

Rien d’anormal dans discourse-doctor (sauf qu’il note des plugins non officiels, mais ceux-ci n’ont pas changé durant cette période).

Cela pourrait simplement être une coïncidence (et une partie de moi pense que c’est le cas), mais…

C’est un groupe plutôt aisé : il est peu probable que beaucoup d’appareils anciens soient utilisés.

Je pensais qu’il s’agissait davantage d’un problème côté serveur que d’un problème côté client.

Je pense que vous devez reconstruire votre conteneur de messagerie NFL.

J’ai peur d’avoir besoin de plus d’explications : aucune autre mention de la NFL (sauf pour les équipes de football) n’apparaît dans tout le méta. NFS ? Aucun conteneur correspondant dans /var/discourse/containers.

Désolé, correction automatique.

Reconstruisez votre conteneur de messagerie.

cd /var/discourse 
./launcher rebuild mail-receiver 

Merci @pfaffman, cela a résolu le problème. On dirait que vous avez déjà rencontré ce cas auparavant — y a-t-il quelque chose qui aurait dû être mieux fait ? Dans notre cas, les conséquences allaient au-delà du simple fait de ne pas recevoir les e-mails des utilisateurs :

VERP repose sur la réception d’e-mails entrants. Nous n’avons donc pas traité les rebonds et les plaintes pendant plusieurs jours, notre réputation auprès de SES s’est effondrée, et ils ont suspendu l’envoi de nos e-mails.

C’est la conséquence de DST Root CA X3 Expiration (September 2021) - Let's Encrypt. Cela a pris au dépourvu quelques personnes, et les problèmes qu’elle a causés pour les auto-hébergeurs de Discourse sont suffisamment subtils pour avoir été négligés. Il reste encore des problèmes à résoudre.

Je soupçonne qu’ils ont cessé d’être gérés le 1er octobre.

Je n’ai jamais réussi à faire fonctionner SES. Une solution de contournement d’urgence consisterait à configurer l’envoi de courriels avec Mailgun.