فهمي الحالي هو أن Email::Processor.process! يستدعي Email::Receiver.new مع mail=nil مما يثير خطأ Email::Receiver.EmptyEmailError، تاركًا @receiver غير معرف.
الجزء rescue التالي يتوقع @receiver تم تهيئته.
ألا ينبغي أن تثير Email::Processor.initialize بعض الأخطاء عند استدعائها مع mail==nil؟
تحديث: حسنًا، تم التأكيد بالتأكيد على أن هذه هي المشكلة. بفضل تحليل @thoka، عرفت الآن ما الذي أبحث عنه، المشكلة هي بالفعل رسائل البريد الإلكتروني الفارغة. لاحظ كيف أن الرسائل غير مقروءة حتى النقطة التي تظهر فيها رسالة بريد إلكتروني فارغة؟
لذلك، فإن رسائل البريد الإلكتروني الفارغة حاليًا تجعل النظام عالقًا بالنسبة لنا، على الأقل بعد عدد معين لأنها تبدو وكأنها مسألة نجاح أو فشل ما إذا كانت عالقة بشكل دائم أم لا.
أعتقد أنه يتعين علينا مراقبة الأمور في الوقت الحالي ولكن سيكون من الرائع إصلاح هذا بالتأكيد. شكرًا!!
أهلاً @mekentosj، أنا أبحث في هذه المشكلة. هل تعرف كيف يتم إنشاء رسائل البريد الإلكتروني الفارغة حاليًا؟ أتساءل عما إذا كان هناك سبب جذري أحتاج إلى التحقيق فيه (إلى جانب إصلاح الخطأ).
عظيم، شكرًا لك على البحث في هذا الأمر! لست متأكدًا تمامًا من كيفية إرسالهم لهذه رسائل البريد الإلكتروني. تبدو الأمثلة في لقطة الشاشة وكأنها ردود حيث قام شخص ما (أو تطبيق البريد الإلكتروني الخاص به) بإزالة كل المحتوى من نص الرسالة قبل الرد (يبدو أن هذا يحدث بشكل متكرر مع الأشخاص الذين يردون باللغة الصينية، لذا ربما تكون هناك مشكلة في ترميز الأحرف أو نوع معين من تطبيقات البريد الإلكتروني). ولكن هناك طرق أخرى يمكنني تخيلها ذات صلة/ممكنة في إعداداتنا وهي أن يرسل شخص ما إلينا مرفقًا فقط بدون أي محتوى نصي وفي سطر الموضوع فقط، أو (يبدو أن بعض الأشخاص ما زالوا يفعلون ذلك)، سؤالهم بالكامل في سطر موضوع البريد الإلكتروني، بدون محتوى نصي.
في الواقع، لقد عثرت للتو على البريد الإلكتروني، وسأرسل ملف eml في رسالة خاصة (لأنه يحتوي على عنوان البريد الإلكتروني للمستخدم)، ربما يحتوي على مزيد من الأدلة.
شكرًا، يبدو أن البريد الإلكتروني تم إنشاؤه بواسطة طرف ثالث (Tencent/China). لقد ألقيت نظرة على رؤوس البريد الإلكتروني ولاحظت بعض الأشياء غير العادية (لقد أبرزت الأجزاء المثيرة للاهتمام أدناه). لا يحتوي البريد الإلكتروني على أي نص على الإطلاق، ولكنه يبدو ردًا تلقائيًا على بريد إلكتروني تم إرساله إلى صندوق بريد qq هذا.
لقد أجريت بحثًا سريعًا عن X-QQ-MIME ويبدو أن عددًا من المواقع الأخرى تواجه مشكلات مماثلة في معالجة البريد من عناوين qq.com.
أعتقد أنه من الآمن بالنسبة لنا تخطي أي بريد لا يحتوي على نص البريد الإلكتروني. يمكننا تسجيله بصمت ومنع ظهور الخطأ.
رائع، هذا يؤكد شعوري بأنه كان يؤثر بشكل أساسي على المستخدمين الصينيين في مجتمعنا.
أعتقد أنه من الآمن لنا تخطي أي بريد إلكتروني لا يحتوي على نص البريد الإلكتروني. يمكننا تسجيله بصمت ومنع حدوث الخطأ.
نعم، طالما أنه لا يتخطى رسائل البريد الإلكتروني التي تحتوي فقط على مرفقات حتى لو لم يكتب المرسل شيئًا (أنا لست خبيرًا في البريد الإلكتروني، لذا ربما لا يزال يحتوي على نص).
السيناريو الآخر الذي ذكرته حيث يكتب المستخدم فقط في الموضوع ولكنه يترك البريد الإلكتروني فارغًا، أعتقد أنه يتم تخطيه حاليًا؟ إذا لم يكن الأمر كذلك، فسيتعين عليك بطريقة ما تحديد تلك الرسائل من رسائل البريد الإلكتروني التي تسبب المشكلة.
البديل هو أن يتم التعرف على حقل رأس X-QQ-AUTO-REPLY: true قبل أن يتم رفع الخطأ بواسطة الآلية التي تكتشف رسائل البريد الإلكتروني التي تم إنشاؤها تلقائيًا.
لقد أجريت تحديثًا لمنع الخطأ الذي تسببه is_bounce?.
يوجد إعداد للموقع لتتبع سجلات البريد:
SiteSetting.log_mail_processing_failures
Log all email processing failures to /logs
إذا تم تمكين هذا، فسيظل خطأ البريد الإلكتروني الفارغ يظهر في سجلات البريد ولكنه لن يتسبب في فشل المهمة كما يحدث حاليًا. لقد أضفت تفاصيل الالتزام هنا كمرجع:
هل هذا الخطأ في السجلات متعلق بالمشكلة؟ يبدو أننا لم نستلم رسائل البريد الإلكتروني من POP3 منذ أيام وهذا يسبب الكثير من المشاكل. لقد تحققت ولا توجد لدي رسائل بريد إلكتروني فارغة على POP3، كيف يمكنني حل هذه المشكلة؟ لقد قمت للتو بالترقية إلى أحدث إصدار ولم يساعد ذلك.
750194 لا يمكن معالجة البريد الإلكتروني: 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'
ينفجر بطريقة ما.
