الخلاصة

  • يحدد RFC 9990 ملف XML يرسل فيه Mail Receiver إلى Domain Owner ملاحظات مجمعة عن السياسة التي رآها، وصفوف عناوين المصدر، والعدد، ونتائج المصادقة خلال فترة تقرير.
  • يؤكد فحص DNS لوجهة rua خارجية أن Report Consumer يقبل علاقة استقبال التقارير؛ ولا يثبت أن البيانات صحيحة أو كاملة ولا يمنحه سلطة تنفيذ على مرسل.

قد يبدو الرسم البياني حاسماً: عنوان IP وعدد كبير ونتيجة مصادقة وحالة reject. لكن RFC 9990 لا يصف حكماً صادراً عن العالم. فـ policy_published هي تهيئة DMARC التي لاحظها نظام الاستقبال، وكل record يقول إن عناوين IP شوهدت وهي تسلّم رسائل لصالح Author Domain إلى ذلك النظام. هذه الإضافة تحدد من البداية ما يمكن للنص أن يثبته.

يفيد التقرير في اكتشاف مزود إرسال غير مدرج، أو مفتاح DKIM يحتاج إلى إصلاح، أو مسار إعادة توجيه، أو زيادة تستحق فحصاً. لكنه لا يقول ما رآه جميع المستلمين، ولا يكشف هوية كاتب الرسالة، ولا يبرهن أن عنوان المصدر تعمد الخداع. وحتى عندما تبدو نتيجة السياسة صارمة، لا يقتضي ذلك أن يطبق مستلم آخر النتيجة نفسها أو أن يتخذ مالك النطاق إجراءً فورياً.

المشكلة تبدأ عندما يختزل نظام داخلي هذه الملاحظة إلى عبارة مثل «احتيال مؤكد» ثم يمررها إلى تعليق مورد أو تقييد حساب. يمكن تبرير قرار كهذا بأدلة مستقلة، لكنه ليس سطراً موجوداً في XML. معيار التقرير ينقل واقعة ملاحظة؛ ولا ينقل حق إصدار العقوبة.

فترة التقرير إطار للقياس لا سجل كامل

يتطلب RFC بيانات مولد التقرير وpolicy_published وسجلاً واحداً على الأقل. تحتوي البيانات على Report-ID وفترة UTC. ويشدد النص على أن begin وend يصفان فترة التقرير لا أول وآخر رسالة رآها المستقبل. الغالب أن تكون الفترة يوماً واحداً بتوقيت UTC ولا ينبغي أن تتداخل الفترات.

إذن غياب صف في نافذة لا يثبت غياب حركة البريد، ووجوده لا يثبت حجمها لدى بقية الإنترنت. توجد نتائج DKIM وSPF في auth_results، لكن RFC يصفها بأنها غير مفسرة بالنسبة إلى DMARC. وسبب تجاوز السياسة هو تفسير لاختيار جهة استقبال، لا شهادة على هوية بشرية أو ذنب أو دافع.

قبل تغيير سياسة ذات أثر كبير، ينبغي مقارَنة الصف بسجل المرسلين المصرح لهم، وتاريخ DNS والمفاتيح، وسجلات الإرسال المحلية، وتغيرات المزود، وملاحظات متكررة من مستقبلين مستقلين. يجب فصل الملف الأصلي وبصمته عن الحقول المستخرجة وعن النتيجة التي يصنعها لوحة المتابعة. «خطر عالٍ» قرار تفسيري لمن بنى اللوحة، وليس حقيقة يرسلها المعيار.

قبول الوجهة لا يقرر استعمال التقرير

يمكن لـ Domain Owner أن يضع وجهة التقارير في rua. إذا كانت الوجهة خارج نطاقه التنظيمي، ينفذ Mail Receiver آلية التحقق من الوجهة الخارجية: يبحث في اسم DNS المحدد؛ وإذا لم يحصل على تأكيد إيجابي فعليه تجاهل URI. هذه آلية دفاع ضد أن يضع مهاجم عنوان ضحية في سجل ثم يستدرج مستلمين كثيرين لإغراقها بالتقارير.

المعنى الإيجابي ضيق: هذا Report Consumer مستعد لتلقي التقارير لهذه العلاقة. لا يحدد من يقرأ التقرير، ولا مدة الاحتفاظ، ولا نقل البيانات إلى متعاقد آخر، ولا ربطها بقواعد أخرى، ولا الإجراء ضد مورد. يلفت RFC 9990 إلى أن سياسة الخصوصية أو شروط الاستخدام لدى Mail Receiver قد تقيد الإرسال إلى طرف ثالث. لا يتضمن التقرير محتوى الرسائل أو عناوين بريد الأفراد أو عناوين IP للأفراد، لكنه قد يتيح تحليلاً لحركة البريد على مستوى النطاق.

لهذا يلزم سجل حوكمة مستقل لكل مستهلك خارجي: النطاقات المسموح بها، الغرض، المالك المسؤول، مجموعة الوصول، التحويلات المسموح بها، مدة الاحتفاظ والحذف، النقل اللاحق، وخطة الحادث. يؤكد DNS مسار التسليم، لكنه لا يحل محل هذه الالتزامات.

وصول التقرير وتحليل XML وصدق البيانات ثلاث مسائل مختلفة

تنقل البيانات التجميعية كبند XML في بريد، وغالباً بعد ضغط GZIP. يطلب RFC أن تتوافق تدفقات البريد التي تحمل feedback مع DMARC وأن تنتهي إلى pass متوافق، لتقليل خطر معالجة تقارير مزيفة. كما تساعد المعرفات وأسماء الملفات في معالجة التكرار.

لكن هذا لا يجعل كل ادعاء في التقرير صحيحاً. ينبه RFC إلى إمكان تزوير البيانات التجميعية بكميات تؤثر في قرارات السياسة أو هندسة المنصة، وإلى أن التقرير المشوه قد يستنزف مفكك الضغط أو محلل XML عبر zip bomb أو XML bomb. قد يصل الملف إلى وجهة مصرح بها وباسم مألوف، ويظل كاذباً أو مؤذياً.

المسار السليم هو تحديد الميزانية ثم التحقق ثم التحليل ثم المقارنة ثم القرار. ضع حدوداً للحجم قبل الضغط وبعده، ولتعقيد XML ووقت التحليل، وتحقق من المخطط، واحفظ الأصل في مساحة مقيدة. عندما يكون الشكل موضع شك، يجوز للمقيّم أن يرفض التقرير أو يعزله للتنسيق مع مولده. نجاح التحليل لا يعني صحة الدليل، وصحة جزء من الدليل لا تعني مشروعية إجراء لا رجعة فيه.

يوضح RFC 9989 أن Domain Owner قد يحتاج، بحسب وتيرة البريد، إلى شهور من تقارير التجميع قبل أن يثق بأنه يصادق كل بريده بصورة صحيحة، وأن اختيار p متعلق بحاجته. التقرير يغذي قرار السياسة؛ لا يصنعه بالنيابة عنه.

قراءة تحريرية: طبقة مشتركة محدودة

هذه قراءة تحريرية وليست قاعدة IETF. يكفي للتشغيل المشترك شكل مشترك ومسار يمكن التحقق منه ومنع للانعكاس؛ ولا يلزم أن يصبح التقرير سلطة فوق سياسات البريد. يجب أن يبقى واضحاً أي مستقبل لاحظ، وأي مدقق قبل، ومن قرر، وما الأثر الفعلي.