Mi entendimiento actual es que Email::Processor.process! llama a Email::Receiver.new con mail=nil, lo que genera una Email::Receiver.EmptyEmailError, dejando @receiver indefinido.
La parte rescue siguiente espera un @receiver inicializado.
¿No debería Email::Processor.initialize generar algún error cuando se llama con mail==nil?
Actualización: Ok, confirmado definitivamente que este es el problema. Gracias al análisis de @thoka, ahora sé qué buscar, el problema son efectivamente los correos electrónicos vacíos. ¿Notas cómo los mensajes no se han leído exactamente hasta el punto en que aparece un correo electrónico vacío?
Eliminarlo de la bandeja de entrada hace que el procesamiento se desbloquee de nuevo. Es decir, hasta que llega al siguiente correo electrónico que estaba en blanco:
Por lo tanto, los correos electrónicos en blanco actualmente nos bloquean el sistema, al menos más allá de un cierto número, porque parece ser un poco impredecible si se bloquea permanentemente o no.
Supongo que tenemos que monitorear las cosas por ahora, pero sería genial si esto pudiera arreglarse. ¡¡Gracias!!
Hola @mekentosj, estoy investigando este problema. ¿Sabes cómo se están generando actualmente los correos electrónicos en blanco? Me pregunto si hay una causa raíz que deba investigar (además de solucionar el error).
¡Genial, gracias por investigar esto! No estoy del todo seguro de cómo logran enviar estos correos electrónicos. Los ejemplos en la captura de pantalla parecen ser respuestas en las que alguien (o su aplicación de correo electrónico) simplemente eliminó todo el contenido del cuerpo antes de responder (parece ocurrir con más frecuencia con personas que responden en chino, así que tal vez sea un problema de codificación de caracteres o un cierto tipo de aplicación de correo electrónico). Pero otras formas que podría imaginar que serían relevantes/posibles en nuestra configuración es que alguien nos envíe un correo electrónico solo con un archivo adjunto sin contenido en el cuerpo y solo con un asunto, o (algunas personas todavía parecen hacer esto), su pregunta completamente en el asunto del correo electrónico, sin contenido en el cuerpo.
En realidad, acabo de encontrar el correo electrónico, enviaré el archivo eml en un DM (ya que contiene la dirección de correo electrónico del usuario), tal vez contenga más pistas.
Gracias, el correo electrónico parece haber sido generado por un tercero (Tencent/China). Eché un vistazo a las cabeceras del correo electrónico y noté algunas cosas inusuales (resalté las partes interesantes a continuación). El correo electrónico no contiene ningún cuerpo, pero parece ser una respuesta automática a un correo electrónico enviado a ese buzón de qq.
Hice una búsqueda rápida de X-QQ-MIME y parece que varios otros sitios están experimentando problemas similares al procesar correos de direcciones de qq.com.
Creo que es seguro omitir cualquier correo que no contenga el cuerpo del correo electrónico. Podemos registrarlo silenciosamente y evitar que se genere el error.
Genial, así que sí, eso confirma mi presentimiento de que en realidad estaba afectando principalmente a los usuarios chinos de nuestra comunidad.
Creo que es seguro omitir cualquier correo electrónico que no contenga el cuerpo del correo electrónico. Podemos registrarlo silenciosamente y evitar que se genere el error.
Sí, siempre y cuando no omita correos electrónicos que solo contengan archivos adjuntos, incluso si el remitente no ha escrito nada (no soy un experto en correo electrónico, así que tal vez eso todavía contenga un cuerpo).
El otro escenario que mencioné donde el usuario solo escribiría en el asunto pero dejaría el correo electrónico vacío, supongo que ya se omite actualmente. Si no es así, de alguna manera tendría que identificar esos correos electrónicos problemáticos.
La alternativa sería que el campo de encabezado X-QQ-AUTO-REPLY: true sea reconocido antes de que el error sea generado por el mecanismo que detecta los correos electrónicos generados automáticamente.
Además, probablemente aún querrás que este error en particular se resuelva haciendo lo que Sam sugirió
Decodifiqué la línea de asunto del correo electrónico en base64 y obtuve: 你好，我是Focus and Flat Agile 17
Creo que esto se debe a los caracteres chinos, que se codifican en base64 antes de enviarlos. Esto explica el formato ilegible para el nombre del remitente y el asunto.
Espero que la lógica existente ya maneje esto, pero verificaré cómo manejamos los archivos adjuntos y el asunto del correo electrónico al procesar el correo de pop3.
Creo que esto sería omitido por la lógica actual de procesamiento de correo. Cuando no hay texto en el cuerpo pero todo lo demás está en su lugar, obtengo:
Email can not be processed: Email::Receiver::NoBodyDetectedError
Probé esto usando un cuerpo de Gmail vacío multipart para texto plano y html:
He realizado una actualización para evitar el error causado por is_bounce?.
Hay una configuración del sitio para rastrear los registros de correo:
SiteSetting.log_mail_processing_failures
Registra todos los fallos en el procesamiento de correo en /logs
Si esto está habilitado, el error de correo en blanco seguirá apareciendo en los registros de correo, pero no provocará que el trabajo falle como lo hace actualmente. He añadido los detalles del commit aquí como referencia:
Estoy viendo este error en los registros, ¿está relacionado? Parece que no hemos recibido correos electrónicos de nuestro POP3 en días y está causando muchos problemas. Comprobé y no tengo correos electrónicos vacíos en POP3, ¿cómo puedo desbloquearlo? Acabo de actualizar a la última versión y no ayudó.
750194 No se puede procesar el correo electrónico: 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'
está fallando.
