لاحظنا مؤخرًا أن بعض الرسائل لم تتم مزامنتها من القائمة البريدية Mailman3 إلى المنتدى.
تُظهر سجلات رفض البريد الإلكتروني أن هذه الرسائل واجهت خطأ Email::Receiver::InvalidPost.
رسالة الخطأ المسجلة هي إحدى هاتين الرسالتين:
نأسف، لكن رسالة البريد الإلكتروني الخاصة بك إلى [“tor-relays@lists.torproject.org”] (بعنوان [tor-relays] قياسات عرض النطاق الترددي لشبكات الترحيل وزمن الاستجابة) لم تنجح.
السبب:
تم رفض الوصول
إذا كان بإمكانك تصحيح المشكلة، فيرجى المحاولة مرة أخرى.
أو:
نأسف، لكن رسالة البريد الإلكتروني الخاصة بك إلى [“tor-relays@lists.torproject.org”] (بعنوان [tor-relays] رد: قنوات الويب الموزع لتوزيع تيليجرام) لم تنجح.
السبب:
حدث خطأ ما. ربما تم إغلاق هذا الموضوع أو حذفه أثناء نظرك إليه؟
إذا كان بإمكانك تصحيح المشكلة، فيرجى المحاولة مرة أخرى.
لا يمكنني العثور على أي خطأ في هذه الرسائل من خلال النظر إلى رؤوسها، على الرغم من أنه في بعض الحالات، يحتوي النص المستخرج كما هو مسجل فقط على تذييل القائمة البريدية، أو في حالة أخرى، هو عبارة عن مجموعة من الأحرف غير المفهومة كما لو كان هناك خلل في فك الترميز.
لقد حاولت إعادة إنتاج هذه المشكلة باستخدام قائمة بريدية اختبار وفئة اختبار ولكن لم أنجح. أي مساعدة في تصحيح هذه المشكلة ستكون موضع تقدير.
وهل يمكنك من فضلك إرسال سجل البريد الإلكتروني لـ Discourse (مُعدل قليلاً إن أمكن)؟
هل هذه أشياء أحتاج إلى استخراجها من الحاوية أم من المضيف؟ نقوم أيضًا بمعالجة البريد عبر حاوية mail-receiver. أم أنك تريد السجلات التي يتم عرضها في واجهة المستخدم الرسومية (على سبيل المثال، /admin/email-logs/rejected)؟
في بعض الأحيان، يرسل Microsoft Exchange بيانات غير مفهومة إذا تم تكوينه بشكل خاطئ ليعتقد أنه يتحدث إلى… لست متأكدًا - خادم Exchange آخر؟ شيء آخر داخل بنيته التحتية؟
يمكنك النظر إلى البريد الخام من وحدة تحكم Discourse باستخدام، على سبيل المثال:
mid = 'message-id from the log'
puts IncomingEmail.find_by(message_id: mid).raw
يعرض هذا البريد الإلكتروني الخام الذي تلقته Discourse. على سبيل المثال، نص الرسالة هذا الذي سحبته للتو من قائمة الرفض الواردة لدينا هو بالفعل غير مفهوم:
This is a multi-part message in MIME format.
--=====003_Dragon855807841081_=====
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: base64
7bgir+m+vzzIDCLE0mDmZrfIXvvmXjY=
--=====003_Dragon855807841081_=====
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: base64
LP/0L4tqmfZizO0DCDDE10uOzMZqzSHDjq04SLPaBjibLVHz+V94m1M45NDN
55aM8SMIf9XY4EFjP9CCFz+ojfmJqmubaz+bjrzmubw+bjWTiGSuLg==
--=====003_Dragon855807841081_=====--
كلاهما سيكون رائعًا. إذا كنت تستخدم PuTTy SSH، يمكنك استخراج سجلات الحاوية، ويمكنك اقتطاع واجهة Discourse. ومع ذلك، لا يمكنك البحث عن الكلمات في الصورة بسهولة، لحذفها
إذا نقرت على الخطأ في السجلات، فهل يظهر السبب في سبب الارتداد؟
تأتي هذه الرسائل بنكهتين:
نأسف، لكن رسالة البريد الإلكتروني الخاصة بك إلى ["tor-relays@lists.torproject.org"] (بعنوان [tor-relays] Re: تقرير إساءة من المرحلات في العائلة 7EAAC49A7840D33B62FA276429F3B03C92AA9327) لم تنجح.
السبب:
حدث خطأ ما. ربما تم إغلاق هذا الموضوع أو حذفه أثناء نظرك إليه؟
إذا كان بإمكانك تصحيح المشكلة، فيرجى المحاولة مرة أخرى.
يمكنني التأكيد على أنه لم يحدث أي شيء من هذا القبيل (تم إغلاق الموضوع أو حذفه) في هذه الحالات.
في بعض الأحيان الأخرى، يكون السبب ببساطة هو Access Denied.
مرحباً lavamind - نعتذر عن إثارة موضوع قديم، ولكن أردت التحقق أولاً قبل أن نتعمق أكثر في تصحيح الأخطاء.
هل ما زلت ترى رفضات Email::Receiver::InvalidPost على عكس البريد الإلكتروني للقائمة البريدية حتى الآن (أواخر 2025 / أوائل 2026)؟
إذا كانت الإجابة نعم، هل يمكنك مشاركة لقطة سريعة لـ:
عدد مرات حدوث ذلك تقريباً (على سبيل المثال، يومياً / أسبوعياً، نسبة الرسائل)
ما إذا كان “سبب” البريد الإلكتروني المرفوض لا يزال “تم رفض الوصول” مقابل “الموضوع مغلق/محذوف”
ما إذا كان يؤثر على قائمة/فئة واحدة أم عدة قوائم
بمجرد أن نؤكد أنه لا يزال يحدث، يمكننا المتابعة لجمع الحد الأدنى من التشخيصات لفشل حديث واحد (معرّف الرسالة + البريد الإلكتروني الخام المخزن المقابل، إلخ).
لا داعي للاعتذار، أنا سعيد جداً لأنك تحقق في هذا الأمر.
مرحباً lavamind - آسف لإثارة موضوع قديم، ولكن أردت التحقق أولاً قبل أن نتعمق أكثر في تصحيح الأخطاء.
هل ما زلت ترى رفضات Email::Receiver::InvalidPost على عكس البريد لقائمة المراسلات حتى الآن (أواخر 2025 / أوائل 2026)؟
نعم، المشكلة لا تزال تحدث.
تقريباً كم مرة يحدث ذلك (على سبيل المثال، يومياً / أسبوعياً، نسبة مئوية من الرسائل)
من الصعب تحديد التكرار بالضبط، لكن المشكلة تؤثر على ما لا يقل عن عدة رسائل أسبوعياً، تقدير تقريبي ربما يتراوح بين 5 إلى 10% من الرسائل؟ يبدو أن بعض المرسلين ممثلون بشكل مفرط في سجلات الأخطاء، لذا على الأقل لا يبدو الأمر عشوائياً تماماً.
ما إذا كان “سبب” البريد الإلكتروني المرفوض لا يزال “تم رفض الوصول” بشكل أساسي مقابل “تم إغلاق الموضوع/حذفه”
لا يزال مزيجاً من الاثنين.
ما إذا كان يؤثر على قائمة/فئة واحدة أو متعددة
إنه يؤثر بشكل أساسي على فئة tor-relays، لكن هذه القائمة تتلقى مدخلات منتظمة من مرسلين متعددين على عكس القوائم الأخرى التي نعكسها، والتي تتلقى حركة مرور أقل بكثير.
بمجرد أن نؤكد أنه لا يزال يحدث، يمكننا المتابعة لجمع الحد الأدنى من التشخيصات لفشل حديث واحد (معرّف الرسالة + البريد الإلكتروني الخام المخزن المقابل، إلخ).
يمكننا النظر في هذا الموضوع الأخير. يشير أرشيف Mailman إلى أنه استقبل 5 رسائل، لكن موضوع مرآة المنتدى يحتوي على 3 مشاركات فقط. تحتوي سجلات الرفض على 3 أخطاء InvalidPost لهذا الموضوع (2 من نفس المرسل، وهذا غريب) وبالنسبة للجميع كان سبب الرفض المعروض هو “حدث خطأ ما. ربما تم إغلاق هذا الموضوع أو حذفه أثناء نظرك إليه؟”
شكرًا lavamind - هذه نقطة بيانات مفيدة حقًا، خاصةً بوجود موضوع مرجعي ملموس مثل “أرشيف بريد يظهر 5، موضوع منتدى يظهر 3”.
نظرًا لأنك ترى هذا عدة مرات في الأسبوع (بشكل تقريبي 5-10% من الرسائل) وأن سبب الارتداد لهذا الحادث هو دائمًا التباين المضلل “الموضوع مغلق/محذوف”، فإن الخطوة التالية الأفضل هي التقاط رسالة فاشلة واحدة من البداية إلى النهاية حتى نتمكن من رؤية ما كان يعتقده Discourse أنه يفعله.
لإحدى رسائل البريد الإلكتروني الثلاثة المرفوضة المرتبطة بذلك الموضوع المرآة، هل يمكنك الحصول على ما يلي:
من /admin/email-logs/rejected، افتح أحد صفوف InvalidPost لهذا الحادث وانسخ:
معرّف الرسالة (Message-ID)
التاريخ/الوقت
(المحذوف) إلى / من / الموضوع المعروض في الصف
نص سبب الارتداد الكامل (كما هو معروض)
من وحدة تحكم Rails (في حاوية تطبيق Discourse)، استخرج البريد الإلكتروني الخام الذي قام Discourse بتخزينه:
@supermathie هل لا يزال IncomingEmail هو المكان القياسي لجلب البيانات الخام، وهل هناك أي شيء آخر تود الحصول عليه بجانبه لتصحيح أخطاء InvalidPost؟
mid = "<الصق معرّف الرسالة من سجل البريد الإلكتروني المرتد>"
ie = IncomingEmail.find_by(message_id: mid)
puts ie&.raw
قم أيضًا بسحب سمات EmailLog المقترنة لنفس معرّف الرسالة (غالبًا ما يكشف هذا ما إذا كان Discourse قد تعامل معه كـ رد مقابل موضوع جديد، وما هي معرّفات الموضوع/الفئة التي تم حلها):
دعنا نركز على هذه الرسالة المرسلة إلى موضوع القائمة البريدية.
تُظهر رؤوس سجلات الحادث للرسالة المرفوضة ما يلي:
Message-ID: <20260103080033.5f6d8f90@dorfdsl.de>
Date: Sat, 03 Jan 2026 08:00:33 +0100
From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Re: Questions about running an exit relay
نص سبب الرفض الكامل هو كما يلي:
We're sorry, but your email message to ["tor-relays@lists.torproject.org"] (titled [tor-relays] Re: Questions about running an exit relay) didn't work.
Reason:
Something has gone wrong. Perhaps this topic was closed or deleted while you were looking at it?
If you can correct the problem, please try again.
السجل النصي العادي للبريد الإلكتروني المرسل إلى Discourse من Mailman (IncomingEmail) متاح هنا (لا أعتقد أنه يحتوي على أي بيانات ليست عامة بالفعل، ولكن على أي حال قمت بتعيين هذا الرابط لينتهي مفعوله بمرور الوقت).
لسوء الحظ، لم تسفر محاولاتي لاستخراج EmailLog عن أي نتيجة: يبدو أن Discourse ليس لديه مثل هذا السجل لتلك الرسالة.
شكرًا @lavamind - هذا ممتاز (معرّف الرسالة + نص الرفض + نسخة مما خزنه Discourse).
أيضًا: خطئي بخصوص طلب EmailLog - من المعقول جدًا (وربما متوقع) ألا يكون هناك صف في EmailLog لرفض وارد كهذا. EmailLog مخصص بشكل أساسي للبريد الصادر، بينما البريد الوارد يعيش في IncomingEmail (الذي قمت بسحبه بالفعل). @supermathie هل يمكنك تأكيد أنني لا أوجه الناس إلى المسار الخاطئ هنا؟
نظرًا لأن لدينا IncomingEmail، هل يمكنك لصق حقول البيانات الوصفية (metadata fields) من نفس السجل؟ سيوفر ذلك سياق “ما الذي حاول Discourse القيام به؟” الذي كنت آمل الحصول عليه من EmailLog.
في وحدة تحكم Rails:
# @supermathie تدقيق للتحقق: لتصحيح أخطاء المشاركة غير الصالحة الواردة، هل بيانات `IncomingEmail` الوصفية هي الشيء الصحيح التالي الذي يجب جمعه؟
mid = "<20260103080033.5f6d8f90@dorfdsl.de>"
ie = IncomingEmail.find_by(message_id: mid)
pp ie&.attributes&.slice(
"id",
"message_id",
"from_address",
"to_addresses",
"cc_addresses",
"subject",
"created_at",
"user_id",
"post_id",
"topic_id",
"error"
)
# اختياري: إذا كنت مرتاحًا، فهذا مفيد أيضًا في كثير من الأحيان
# (إنه يوضح ما استخرجه Discourse كنص أساسي مقابل ما خزنه كنص خام)
pp ie&.attributes&.slice("raw", "cooked")
(إذا كانت النصوص الخام/المطبوخة ضخمة، فلا تتردد في استبعادها - لقد شاركت النص الخام بالفعل.)
لماذا هذه الحقول مهمة:
topic_id / post_id (إذا كانت موجودة) تخبرنا ما إذا كان Discourse قد حلل هذا كـرد/مشاركة جديدة وما الذي استهدفه.
user_id يخبرنا أي مستخدم مُعدّ/حقيقي قام Discourse بتعيين المُرسل إليه (حالات الأذونات / “تم رفض الوصول”).
error غالبًا ما يكون أكثر تحديدًا من نص الارتداد العام “تم إغلاق الموضوع/حذفه”.
إذا أظهرت تلك السمات أن دقة topic_id/post_id تشير إلى الموضوع المرآة، فإن الخطوة التالية المحتملة هي معرفة سبب اعتبار المستلم له غير صالح (نص أساسي فارغ مستخرج، فك تشفير MIME، عدم تطابق الأذونات، عدم تطابق مفتاح الرد، إلخ). إذا أظهر عدم وجود دقة للموضوع/المشاركة على الإطلاق، نركز على رؤوس التوجيه / اكتشاف الرد.
ومرة أخرى - شكرًا على لصق الرابط. إن الحصول على معرّف رسالة واحد وملموس يفشل بهذه الطريقة هو بالضبط ما نحتاجه للتوقف عن التخمين.
