الخلاصة

  • يعرّف RFC 9991 تقرير فشل DMARC المفصل لرسالة واحدة أخفقت أو لمجموعة رسائل تشترك في سبب مشابه، وقد يصل بسرعة ويحمل مواد أكثر حساسية من التقرير التجميعي.
  • تمثل قيمتا ruf وfo طلباً من مالك النطاق، لا أمراً ملزماً. ويظل مستقبِل البريد هو من يقرر أنواع التقارير التي يرسلها، إن أرسل شيئاً، وفق سياسته وحالة الفشل والتزاماته المتعلقة بالخصوصية والأمن.
  • يقترح Daniel Kade إيصالاً محدود الغرض للإفصاح عن الفشل، يسجل الاختيار والتنقيح والتجميع وتحديد المعدل والنقل والوصول والحذف، من دون الاحتفاظ بالمتن أو العناوين أو بيانات الاعتماد أو الحمولة الخبيثة.

النافذة التي تكشف العطل قد تكشف صاحب الرسالة

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

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

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

الطلب والتوليد والاستهلاك ثلاث سلطات

صدر RFC 9991 في مايو 2026 بصفته مواصفة على مسار المعايير. وهو، مع مواصفة DMARC الأساسية الجديدة ووثيقة التقارير التجميعية، يحل محل الأجزاء ذات الصلة من RFC 7489، كما يحدّث قواعد أقدم للإبلاغ عن إخفاق المصادقة.

ينشر مالك النطاق وجهات ruf وخيارات fo في سجل سياسة DMARC. تحدد هذه القيم مكان طلب التقرير وأنواع الإخفاق التي تهم المالك. لكنها ليست قناة أوامر. فالجهة المستقبِلة تحدد، وفق الإخفاق والخيار المطلوب وسياستها الداخلية، أنواع التقارير التي سترسلها، إن أرسلت أياً منها.

تنقسم السلسلة إلى ثلاثة قرارات. يقرر المالك أن يطلب وإلى أين يوجه طلبه. ويقرر المستقبِل هل يفصح وما القدر الذي يفصح عنه. ويقرر المستهلك من يطّلع وكيف يحلل وكم يحتفظ وهل يعيد الإرسال. نجاح فحص في طبقة لا يثبت شرعية الطبقة التالية.

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

زيادة التفاصيل تغيّر فئة الدليل

يفصل تنسيق تقارير إساءة الاستخدام بين شرح يقرأه الإنسان وحقول آلية ومواد مأخوذة من الرسالة الأصلية في أجزاء MIME مختلفة. ويضيف RFC 9991 دلالات خاصة بـDMARC، منها Identity-Alignment وتفاصيل DKIM ذات الصلة ومعلومات DNS الخاصة بـSPF ونوع إخفاق المصادقة.

نطاق Identity-Alignment ضيق عن قصد. فهو يسرد آليات المصادقة التي لم تثبت هوية محاذية، أو يذكر none حين تنجح الآليات التي جرت تجربتها. ولا يفسر سبب تعطل التوقيع، ولا يثبت أن المؤلف الظاهر أرسل الرسالة، ولا أن المحتوى خبيث، ولا أن تصرف المستقبِل اللاحق صحيح، ولا أن الإفصاح مأذون.

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

تفويض الوجهة الخارجية يثبت الاستعداد لا الاستحقاق

يمكن لسجل السياسة أن يوجه التقارير خارج النطاق التنظيمي. يعيد RFC 9991 استخدام آلية تفويض الوجهة الخارجية الواردة في التقارير التجميعية: تنشر الوجهة سجلاً في DNS يبين استعدادها لاستقبال تقارير عن النطاق الطالب. يمنع ذلك مالك نطاق من توجيه سيل من التقارير إلى طرف ثالث غير راغب.

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

تحتاج الحوكمة إلى فصل سؤالين: هل الوجهة مؤهلة لاستقبال هذا النوع من التقارير؟ وهل الإفصاح المحدد متناسب مع غرضه؟ قبول الوجهة لبعض التقارير لا يمنحها حقاً في كل ما يملكه المولد. ودمج القرارين يحول استعداداً فنياً إلى ادعاء سلطة.

التقليل الجيد يبقي الجواب ويزيل ما عداه

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

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

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

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

تحديد المعدل يجعل الصمت قابلاً لعدة تفسيرات

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

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

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

التقرير نفسه محتوى غير موثوق

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

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

وقد تكون الأتمتة الأهم أتمتة رفض: نزع المحتوى النشط، رفض بنى MIME غير المدعومة، حجر المرفقات، وضع سقف لفك الضغط والتحليل، ومنع الفهرسة العامة. نجاح المحلل البرمجي ليس نهاية القرار، بل بداية الحفظ الخاضع للسيطرة.

إيصال إفصاح محدود الغرض

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

يبدأ الإيصال بنطاق سياسة DMARC، ووقت استعلام DNS ونتيجته، ووجهات ruf المطلوبة، وشرط fo، ونتيجة تفويض الوجهة الخارجية، ونسخة سياسة المستقبِل، والغرض وتاريخ انتهائه. ثم يحدد فئة الفشل وما إذا كانت الحالة فردية أم مجمعة.

ويسرد فئات البيانات المختارة، لا البيانات نفسها: حقول مصادقة مشتقة، أو مجموعة محدودة من ترويسات المسار، أو رمز عنوان منقح، أو مقتطفاً مقيداً. ويسجل طريقة التنقيح ونسختها، ونطاق الربط، وقاعدة التجميع، ونتيجة تحديد المعدل، والنقل الآمن، وخطأ التوليد. ومن جهة الاستهلاك، يربط دور المستخدم وحدود الوصول ونتيجة العزل وموعد الاحتفاظ وحدث الحذف أو الاستبدال بقرار مسؤول.

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

بهذا، حين يسأل أحدهم لاحقاً لماذا عبرت هذه البايتات حدود المؤسسة، لن تكون الإجابة «لأن DNS طلبها»، بل سلسلة قرارات محلية محددة يمكن مراجعتها.

المصادر

  1. Lu Heng — سيادة البيانات بين الواقع التقني والعملي
  2. Lu Heng — لماذا وُجدت BTW Media
  3. Lu Heng — مرآة السياسة
  4. IANA — معاملات تنسيق تقارير إساءة استخدام الرسائل
  5. صفحة معلومات RFC 9991
  6. RFC 5322 — تنسيق رسائل الإنترنت
  7. RFC 5965 — تنسيق قابل للتوسعة لتقارير إساءة استخدام البريد
  8. RFC 6590 — تنقيح البيانات الحساسة من تقارير إساءة استخدام البريد
  9. RFC 6591 — الإبلاغ عن إخفاق المصادقة باستخدام ARF
  10. RFC 6650 — إنشاء تقارير ملاحظات البريد واستخدامها
  11. RFC 7489 — DMARC
  12. RFC 9989 — DMARC
  13. RFC 9990 — تقارير DMARC التجميعية
  14. RFC 9991 — تقارير فشل DMARC