ألاحظ أن رسائل البريد الإلكتروني الواردة تُرفض بواسطة Discourse مع الرسالة:
لا يمكن معالجة البريد الإلكتروني: تم رفض الوصول
يبدو أن استقبال البريد الإلكتروني الوارد يعمل بشكل صحيح. تصل الرسالة إلى مستلم البريد، وتجتاز فحوصات SPF و DKIM و DMARC بنجاح. ثم تقوم Discourse بمعالجتها عبر Jobs::ProcessEmail.
يبدو أن السلوك يعتمد على محتوى MIME/الجسم:
بريد إلكتروني بسيط/نص عادي → مقبول
بريد إلكتروني يحتوي على توقيع Outlook، وجدول و/أو صور مضمنة → مرفوض برسالة تم رفض الوصول
يُظهر سجل البريد الإلكتروني المرفوض أن الفشل حدث في Email::Processor#process!.
إصدار تطبيق Discourse:
4143157a17dc3ff63c909c64d0cf578243d38861
تمت هجرة/استعادة هذا التثبيت مؤخرًا إلى خادم آخر، لكن التسليم عبر SMTP الوارد يعمل بشكل صحيح، ويبدو أن السلوك مرتبط تحديدًا بأجسام البريد الإلكتروني الغنية بالمحتوى.
يمكنني توفير رسالة MIME خام بعد إزالة البيانات الحساسة، بالإضافة إلى تشخيصات إضافية لـ IncomingEmail و Email::Receiver إذا كان ذلك مفيدًا.
تحديث: لقد أعدت الآن إنتاج سبب أخطاء Access Denied التي كنت أراها وفتحت طلب سحب (PR):
الجزء المهم من ملاحظتي الأصلية كان:
البريد الإلكتروني الوارد البسيط/العادي → مقبول
البريد الإلكتروني الأكثر ثراءً الذي يحتوي على وسائط مضمنة → مرفوض بـ Access Denied
كانت الرسائل المرفوضة تُعالج كمستخدمين مؤقتين/غرباء في فئة تسمح بالبريد الإلكتروني الوارد من الغرباء.
منذ #42079، يكتشف NewPostManager الوسائط المضمنة مباشرةً من محتوى المنشور عند غياب بيانات حجم الصورة. وهذا يسبب بشكل صحيح دخول هذه الرسائل إلى مسار المراجعة :contains_media.
ومع ذلك، قبل وضع المنشور في طابور للمراجعة، يقوم NewPostManager.default_handler بإجراء فحص Guardian العادي لإنشاء موضوع الفئة.
لمستخدم البريد الإلكتروني الوارد المؤقت، يمكن أن يفشل هذا الفحص حتى لو كان Email::Receiver قد قبل بالفعل مسار بريد الغرباء للفئة وتمرير skip_validations.
هذا ينتج الخطأ الذي كنت أراه:
Email::Receiver::InvalidPost: Access Denied
أضفت اختبار انحدار (regression test) شامل للمستقبل (receiver) لبريد إلكتروني يحتوي على وسائط من غريب.
على الفرع main الحالي، قبل الإصلاح، يعيد الاختبار إنتاج:
Email::Receiver::InvalidPost: Access Denied
كما اختبرت الحالة نفسها مباشرةً قبل #42079، حيث يتم قبول البريد الإلكتروني الوارد، مما يؤكد أن هذا انحدار تم إدخاله بواسطة ذلك التغيير.
يحافظ طلب السحب (PR) على المراجعة المقصودة للوسائط بدلاً من تجاوزها. مع الإصلاح، يتم وضع البريد الإلكتروني الوارد في طابور كـ ReviewableQueuedPost وتظل سبب المراجعة:
contains_media
تعمل مواصفات Email::Receiver و NewPostManager ذات الصلة محلياً:
261 مثالاً، 0 إخفاقات
لذا يبدو أن هذا يفسر سلوك Access Denied الذي أبلغت عنه أعلاه، بما في ذلك سبب عمل البريد الإلكتروني العادي بينما لم تعمل الرسائل الأكثر ثراءً التي تحتوي على وسائط مضمنة.