محلل تقارير فشل البريد DSN: مشاريع تخرج هندسة البرمجيات

إشعار الفشل ليس رسالة واحدة بسيطة

رسالة DSN تحمل معلومات عن حالة التسليم، وقد تحتوي أجزاء متعددة فيها بيانات الرسالة الأصلية ومعلومات المستلم. مشروع تخرج هندسة البرمجيات يبني محللاً يقرأ عينات معيارية محلية ويفسر حالة كل مستلم. لا يرسل بريداً ولا يعيد المحاولة تلقائياً؛ هدفه أن يشرح لماذا لا يمكن اتخاذ قرار واحد للرسالة كلها إذا اختلفت حالات العناوين.

RFC 3464 يحدد تنسيق Delivery Status Notification، وRFC 3463 يعرف enhanced status codes. الرموز مثل 4.x.x و5.x.x تعطي فئة مؤقتة أو دائمة على مستوى البروتوكول، لكنها لا تقدم وحدها سياسة retry كاملة لكل تطبيق. اعرض الرمز والنص الخام ومصدر التفسير معاً، ولا تحول النص الحر من خادم إلى تعليمات قابلة للتنفيذ.

حلل الحقول مع حفظ الأصل

اقرأ MIME fixtures عبر مكتبة بريد موثوقة، ثم استخرج Reporting-MTA وFinal-Recipient وAction وStatus وDiagnostic-Code إن وجدت. خزّن النص الأصلي للمقطع داخل fixture فقط، واعرض نسخة مهربة HTML كي لا ينفذ نص غير موثوق في الواجهة. إذا غاب حقل أو تكرر، ارفع ملاحظة بنيوية بدلاً من ملئه بتخمين.

لا تفترض أن جميع أنظمة البريد تولد DSN بالشكل نفسه أو أن كل الفشل ينتج إشعاراً. RFC 5321 يحدد ردود SMTP أثناء الجلسة؛ أما التقرير اللاحق فله تنسيق مختلف. احتفظ بحدود الفصل بين رفض فوري عند الأمر SMTP وإشعار DSN وصل بعد محاولة التسليم، لأن توقيته يغير المعنى التشغيلي.

حوّل كل مستلم إلى مسار

مثّل الرسالة وrecipient منفصلين. قد يقبل الخادم بعض العناوين ويرفض أخرى؛ لذلك يكون لكل مستلم action وstatus مستقلان. أضف خطاً زمنياً فيه وقت الإرسال التجريبي، رد SMTP إن وجد، وقت استقبال الإشعار الاصطناعي، وعدد محاولات مفترض. إذا لم تتوفر ساعة أو معرف رسالة موثوق، اعرض البيانات ناقصة ولا ترتب أحداثاً بالتخمين.

صمم حالة `delayed` ثم `failed`، وحالة `delivered` بعد محاولة، وحالة رفض أولي. اجعل السياسة قابلة للتعديل في config، مثلاً أقصى عدد محاولات وفاصل متزايد، لكن اعرضها كسياسة المشروع لا كقاعدة RFC. لا ترسل الرسالة من التطبيق ولا تستخدم عنواناً حقيقياً؛ كل هذا نموذج حالات للاختبار.

مثال لرمز مؤقت ودائم

افترض fixture لمستلم اصطناعي ترجع action=delayed ورمز 4.2.0، ثم إشعاراً لاحقاً failed ورمز 5.1.1. يفسر البرنامج التقرير الثاني كحالة نهائية وفق classification الممثلة في قواعد المشروع، ويوقف المحاولات المستقبلية لذلك المستلم فقط. هذه بيانات تعليمية، ويجب على الفريق التأكد من دلالة الرمز من RFC والوثائق الخاصة ببيئته.

لا تجمع رموزاً من مقالات الإنترنت وتضعها كجدول شامل. أنشئ ملف mapping لجزء صغير من الفئات، اربط كل مدخل بمصدره، واجعل unknown status ظاهراً. النص التشخيصي قد يحتوي أسماء مضيفين أو عناوين؛ احجبه في العرض الافتراضي واحذف البيانات الشخصية من fixture. اشرح اختلاف التفسير بين status class العام والرمز التفصيلي.

اختبارات لا تشغل SMTP

جهز حالات DSN صحيحة، جزء ناقص، رمز غير معروف، عدة مستلمين بنتائج متباينة، تقرير مكرر، وإشعار يصل خارج الترتيب. معيار القبول أن تبقى حالة كل مستلم مستقلة وأن لا يؤدي DSN مكرر إلى إضافة محاولة جديدة. اختبر parsing لرسائل multipart باستخدام fixtures، مع مقارنة البنية والحقول لا byte-for-byte serialization.

اكتب اختبارات قرار السياسة منفصلة عن parser: نفس الحدث مع سياسة مختلفة ينتج اقتراحاً مختلفاً لكن سجل المصدر يبقى ثابتاً. افحص أن الواجهة لا تسمح بنقرة «إعادة إرسال» فعلية. إذا فشل التحليل، احتفظ بحالة unknown مع السبب لا تصنيف دائم. هذا يمنع إساءة تفسير تقرير مشوه كأن العنوان غير صالح قطعاً.

ما الذي لا يستطيع DSN إثباته

لا يضمن وصول التقرير نفسه، ولا يكشف بالضرورة كل سبب داخلي، وقد تختلف صياغة Diagnostics باختلاف النظام. التقرير المتأخر لا يعني أن المستخدم قرأ الرسالة أو أن تطبيقه عالجها. لذلك يجب أن يسمى الناتج «تحليل حالة التسليم» لا «تأكيد وصول للمستلم». عند تصميم retry لمنتج حقيقي، تؤخذ في الاعتبار idempotency والسياسة ومعدل الإرسال والامتثال.

يسلم مشروع التخرج مجموعة fixtures منزوعة الهوية، parser، خريطة رموز صغيرة مسندة للمصدر، واختبارات ترتيب الأحداث. يصلح لنطاق مشاريع تخرج هندسة البرمجيات، ويمكن استكشافه عبر خدمة مشاريع التخرج وقواعد البيانات وواجهات API. يمكن مقارنة فكرته بمقال MIME round-trip، لكن هذا يحلل تقرير التسليم ولا يختبر تسلسل رسالة عامة أو تسليمها فعلياً. تعريف الحقول في RFC 3464 وتصنيف الرموز في RFC 3463؛ أما الإعادة فتظل سياسة التطبيق.