Ma compréhension actuelle est que Email::Processor.process! appelle Email::Receiver.new avec mail=nil, ce qui déclenche une Email::Receiver.EmptyEmailError, laissant @receiver indéfini.
La partie rescue suivante s’attend à un @receiver initialisé.
Ne devrait-il pas y avoir une erreur levée par Email::Processor.initialize lorsqu’il est appelé avec mail==nil ?
Mise à jour : Ok, c’est définitivement confirmé que c’est le problème. Grâce à l’analyse de @thoka, je sais maintenant quoi chercher, le problème vient effectivement des e-mails vides. Remarquez comment les messages sont non lus exactement jusqu’au point où un e-mail vide apparaît ?
Le supprimer de la boîte de réception permet au traitement de se débloquer à nouveau. C’est-à-dire jusqu’à ce qu’il rencontre le prochain e-mail qui était vide :
Ainsi, les e-mails vides bloquent actuellement le système pour nous, du moins au-delà d’un certain nombre, car il semble que ce soit un peu aléatoire quant à savoir s’il se bloque définitivement ou non.
Je suppose que nous devons surveiller les choses pour le moment, mais ce serait formidable si cela pouvait être résolu. Merci !!
Salut @mekentosj, je me penche sur ce problème. Savez-vous comment les e-mails vides sont générés actuellement ? Je me demande s’il y a une cause profonde que je dois investiguer (en plus de corriger l’erreur).
Excellent, merci d’avoir examiné cela ! Je ne suis pas entièrement sûr de la manière dont ils parviennent à envoyer ces e-mails. Les exemples dans la capture d’écran semblent être des réponses où quelqu’un (ou son application de messagerie) a simplement supprimé tout le contenu du corps avant de répondre (cela semble se produire plus souvent avec des personnes répondant en chinois, donc peut-être un problème de codage de caractères ou un certain type d’application de messagerie). Mais d’autres méthodes que je pourrais imaginer comme pertinentes/possibles dans notre configuration seraient que quelqu’un nous envoie un e-mail avec uniquement une pièce jointe sans contenu de corps et seulement un sujet, ou (certaines personnes semblent encore faire cela), leur question entièrement dans le sujet de l’e-mail, sans contenu de corps.
En fait, je viens de trouver l’e-mail, j’enverrai le fichier eml dans un DM (car il contient l’adresse e-mail de l’utilisateur), peut-être qu’il contient plus d’indices.
Merci, l’e-mail semble avoir été généré par un tiers (Tencent/Chine). J’ai examiné les en-têtes de l’e-mail et j’ai repéré des choses inhabituelles (j’ai mis en surbrillance les parties intéressantes ci-dessous). L’e-mail ne contient aucun corps, mais il semble s’agir d’une réponse automatique à un e-mail envoyé à cette boîte aux lettres qq.
J’ai fait une recherche rapide sur X-QQ-MIME et il semble que plusieurs autres sites rencontrent des problèmes similaires lors du traitement des e-mails provenant d’adresses qq.com.
Je pense qu’il est sûr pour nous d’ignorer tout e-mail qui ne contient pas le corps du message. Nous pouvons le journaliser silencieusement et empêcher l’erreur de se produire.
Cool, donc oui, cela confirme mon sentiment que cela affectait principalement les utilisateurs chinois de notre communauté.
Je pense qu’il est sûr pour nous de passer outre tout e-mail qui ne contient pas le corps de l’e-mail. Nous pouvons le journaliser silencieusement et empêcher l’erreur d’être levée.
Oui, tant qu’il ne saute pas les e-mails qui ne contiennent que des pièces jointes, même si l’expéditeur n’a rien tapé (je ne suis pas un expert en e-mail, donc peut-être que cela contient toujours un corps).
L’autre scénario que j’ai mentionné où l’utilisateur taperait uniquement dans l’objet mais laisserait l’e-mail vide est déjà ignoré, je suppose ? Sinon, vous devriez d’une manière ou d’une autre identifier ceux-là parmi ces e-mails problématiques.
L’alternative serait que le champ d’en-tête X-QQ-AUTO-REPLY: true soit reconnu avant que l’erreur ne soit levée par le mécanisme qui détecte les e-mails générés automatiquement.
En outre, vous voudrez probablement toujours que cette erreur particulière soit résolue en faisant ce que Sam a suggéré
J’ai décodé le sujet de l’e-mail en base64 et j’ai obtenu : 你好，我是Focus and Flat Agile 17
Je pense que cela est dû aux caractères chinois, ils sont encodés en base64 avant l’envoi. Cela explique le format brouillé pour le nom de l’expéditeur et le sujet.
J’espère que la logique existante gère déjà cela, mais je vais vérifier comment nous traitons les pièces jointes et le sujet de l’e-mail lors du traitement des e-mails à partir de pop3.
Je pense que cela serait ignoré par la logique de traitement des e-mails actuelle. Lorsqu’il n’y a pas de texte dans le corps mais que tout le reste est en place, j’obtiens :
Email can not be processed: Email::Receiver::NoBodyDetectedError
J’ai testé cela en utilisant un corps vide de gmail multipart pour le texte brut et le html :
J’ai effectué une mise à jour pour éviter l’erreur causée par is_bounce?.
Il existe un paramètre de site pour le suivi des journaux d’e-mails :
SiteSetting.log_mail_processing_failures
Enregistre tous les échecs de traitement des e-mails dans /logs
Si cela est activé, l’erreur d’e-mail vide apparaîtra toujours dans les journaux d’e-mails, mais n’entraînera pas l’échec du travail comme c’est le cas actuellement. J’ai ajouté les détails du commit ici à titre de référence :
Je vois cette erreur dans les journaux, est-ce lié ? Il semble que nous n’ayons pas reçu d’e-mails de notre POP3 depuis des jours et cela cause beaucoup de problèmes. J’ai vérifié et je n’ai pas d’e-mails vides sur POP3, comment puis-je le débloquer ? Je viens de mettre à jour vers la dernière version, cela n’a pas aidé.
750194 Impossible de traiter l’e-mail : Email::Receiver::EmptyEmailError
/var/www/discourse/lib/email/processor.rb:183:in `log_email_process_failure'
/var/www/discourse/lib/email/processor.rb:29:in `rescue in process!'
/var/www/discourse/lib/email/processor.rb:16:in `process!'
/var/www/discourse/lib/email/processor.rb:13:in `process!'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:23:in `process_popmail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:43:in `block (2 levels) in poll_pop3'
net-pop-0.1.2/lib/net/pop.rb:669:in `each'
net-pop-0.1.2/lib/net/pop.rb:669:in `each_mail'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:40:in `block in poll_pop3'
net-pop-0.1.2/lib/net/pop.rb:531:in `start'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:39:in `poll_pop3'
/var/www/discourse/app/jobs/scheduled/poll_mailbox.rb:14:in `execute'
/var/www/discourse/app/jobs/base.rb:249:in `block (2 levels) in perform'
rails_multisite-4.0.1/lib/rails_multisite/connection_management.rb:80:in `with_connection'
/var/www/discourse/app/jobs/base.rb:236:in `block in perform'
/var/www/discourse/app/jobs/base.rb:232:in `each'
/var/www/discourse/app/jobs/base.rb:232:in `perform'
/var/www/discourse/app/jobs/base.rb:297:in `perform'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:122:in `process_queue'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:70:in `worker_loop'
mini_scheduler-0.16.0/lib/mini_scheduler/manager.rb:59:in `block (2 levels) in ensure_worker_threads'
explose.
