La mia attuale comprensione è che Email::Processor.process! chiami Email::Receiver.new con mail=nil che solleva un Email::Receiver.EmptyEmailError, lasciando @receiver indefinito.
La parte rescue successiva si aspetta un @receiver inizializzato.
Non dovrebbe Email::Processor.initialize sollevare un errore quando chiamato con mail==nil?
Aggiornamento: Ok, confermato definitivamente che questo è il problema. Grazie all’analisi di @thoka ora so cosa cercare, il problema sono effettivamente le email vuote. Nota come i messaggi sono non letti esattamente fino al punto in cui appare un’email vuota?
Quindi le email vuote attualmente bloccano il sistema per noi, almeno oltre un certo numero perché sembra essere un po’ un caso di successo o fallimento se si blocca permanentemente o meno.
Suppongo che per ora dovremo monitorare le cose, ma sarebbe fantastico se questo potesse essere risolto. Grazie!!
Ciao @mekentosj, sto esaminando questo problema. Sai come vengono generate attualmente le email vuote? Mi chiedo se ci sia una causa principale che devo indagare (oltre a correggere l’errore).
Ottimo, grazie per aver approfondito la questione! Non sono del tutto sicuro di come riescano a inviare queste email. Gli esempi nello screenshot sembrano essere risposte in cui qualcuno (o la loro app di posta elettronica) ha semplicemente rimosso tutto il contenuto dal corpo prima di rispondere (sembra accadere più spesso con persone che rispondono in cinese, quindi forse un problema di codifica dei caratteri o un certo tipo di app di posta elettronica). Ma altri modi che potrei immaginare come rilevanti/possibili nella nostra configurazione sono che qualcuno ci invii un’email solo con un allegato senza contenuto nel corpo e solo un oggetto, oppure (alcune persone sembrano ancora farlo), la loro domanda interamente nell’oggetto dell’email, senza contenuto nel corpo.
Grazie, l’email sembra essere generata da una terza parte (Tencent/Cina). Ho dato un’occhiata agli header dell’email e ho notato alcune cose insolite (ho evidenziato le parti interessanti qui sotto). L’email non contiene alcun corpo, ma sembra essere una risposta automatica a un’email inviata a quella casella di posta qq.
Ho fatto una rapida ricerca per X-QQ-MIME e sembra che numerosi altri siti stiano riscontrando problemi simili nell’elaborazione della posta dagli indirizzi qq.com.
Penso che possiamo tranquillamente ignorare qualsiasi email che non contenga il corpo dell’email. Possiamo registrarla silenziosamente e impedire che venga generato l’errore.
Fantastico, quindi sì, questo conferma la mia sensazione che stesse interessando principalmente gli utenti cinesi della nostra community.
Penso che sia sicuro per noi saltare qualsiasi email che non contenga il corpo dell’email. Possiamo registrarla silenziosamente e impedire che venga generato l’errore.
Sì, purché non salti le email che contengono solo allegati anche se il mittente non ha digitato nulla (non sono un esperto di email, quindi forse quello contiene ancora un corpo).
L’altro scenario che ho menzionato in cui l’utente digita solo nell’oggetto ma lascia vuoto il corpo dell’email, immagino che venga già saltato? In caso contrario, dovresti in qualche modo identificarli da queste email che causano problemi.
L’alternativa sarebbe far riconoscere il campo header X-QQ-AUTO-REPLY: true prima che l’errore venga generato dal meccanismo che rileva le email generate automaticamente.
Inoltre, probabilmente vorrai comunque che questo particolare errore venga risolto facendo ciò che Sam ha suggerito
Ho decodificato l’oggetto dell’email in base64 e ho ottenuto: 你好，我是Focus and Flat Agile 17
Penso che ciò sia dovuto ai caratteri cinesi, che vengono codificati in base64 prima dell’invio. Questo spiega il formato confuso per il nome del mittente e l’oggetto.
Spero che la logica esistente gestisca già questo, ma verificherò come gestiamo gli allegati e l’oggetto dell’email quando elaboriamo la posta da pop3.
Penso che questo verrebbe saltato dalla logica di elaborazione della posta attuale. Quando non c’è testo nel corpo ma tutto il resto è a posto, ottengo:
Email can not be processed: Email::Receiver::NoBodyDetectedError
Ho testato questo utilizzando un corpo vuoto di Gmail multipart per testo normale e html:
Ho apportato un aggiornamento per prevenire l’errore causato da is_bounce?.
Esiste un’impostazione del sito per il tracciamento dei log di posta:
SiteSetting.log_mail_processing_failures
Registra tutti i fallimenti nell'elaborazione delle email in /logs
Se questa è abilitata, l’errore dell’email vuota apparirà comunque nei log di posta ma non causerà il fallimento del job come accade attualmente. Ho aggiunto i dettagli del commit qui per riferimento:
Sto riscontrando questo errore nei log, è correlato? Sembra che non riceviamo email dal nostro POP3 da giorni e ciò sta causando molti problemi. Ho controllato e non ho email vuote su POP3, come posso sbloccarlo? Ho appena aggiornato all’ultima versione, non ha aiutato.
750194 Email non può essere elaborata: 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'
stia esplodendo.
