طرفان يصنعان علاقة الإبلاغ
نشر وجهة التقارير في المجال DMARC تعبر السياسة عن طلب مالك المجال. ولا يتطلب الأمر من جانب واحد وجهة غير ذات صلة لقبول التقارير الناتجة. التحقق من الوجهة الخارجية يحمي المستلمين من أن يتم اختيارهم كأهداف تقرير غير راغبة. ينشر الجانب المتلقي الإذن من خلال DNS ، بينما يتحقق الجانب المبلغ من هذا الإذن قبل استخدام الوجهة الخارجية.
RFC 9990 تطبق إجراءات التحقق الخاصة بها عندما يكون ذلك مناسبًا المجال التنظيمي تعرض المقارنة وجهة خارجية لإعداد التقارير المجمعة. لا تستبدل هذه القاعدة باختبار مبسط يوضح اختلاف السلاسل الموجودة في عنوان "من" وعنوان التقرير. يجب الاحتفاظ بمجال السياسة المكتشف والمضيف الوجهة وسياق المجال التنظيمي حتى يكون قرار إجراء التحقق قابلاً للتكرار. RFC 9990 ، القسم 4
قم ببناء اسم المالك بالترتيب الصحيح
قم باستخراج المضيف الوجهة من URI الخاص بإعداد التقارير. أسبقية _التقرير. _dmarc ، ثم قم بإضافة اسم المجال الذي تم استرداد السياسة منه مسبقًا، وتحويل هذا المجال إلى علامة A إذا لزم الأمر. يمتلك مالك DNS الناتج النموذج Policy-domain._report. _dmarc.destination-host. يتم الاستعلام عنه سجلات TXT. إذا تجاوز الاسم المنشأ حدود DNS ، فلا يمكن إجراء تحديد ترخيص إيجابي.
يستخدم هذا البناء المجال الفعلي الذي تم استرداد السياسة منه. لا تختصرها إلى أحد الوالدين المألوفين لمجرد أن هذا الوالد يشبه العلامة التجارية للمؤسسة. وبالمثل، لا يتم إدراج الجزء المحلي من عنوان mailto في اسم مالك DNS . احتفظ بمعرف URI الأصلي ومضيف الوجهة الذي تم تحليله حتى يتمكن المراجعون من رؤية كيفية اتباع الاسم المنشأ من المدخلات. RFC 9990 ، القسم 4
التحقق من صحة الاستجابة بدلاً من التعرف على سلسلة مألوفة
يتم تحليل السجلات التي تم إرجاعها كقوائم قيمة العلامة. يجب أن تظهر العلامة v=DMARC1 الإلزامية أولاً، وتكون الفاصلة المنقوطة اللاحقة اختيارية. يتم تجاهل السجلات التي تفشل في اختبار التحليل المحدد. ويحدد سجل مؤهل واحد متبقي على الأقل ترتيبات إعداد التقارير الخارجية بموجب هذا الإجراء. إجابة فارغة أو قيمة TXT غير ذات صلة أو سجل مع وضع الإصدار الخاطئ لا ينشئ الإذن.
قيمة إصدار DMARC حساسة لحالة الأحرف: DMARC1 هي القيمة المطلوبة، وليست تقريبية بأحرف صغيرة أو إصدار بروتوكول تم اختراعه حديثًا. لا ينبغي الخلط بين قواعد مقارنة أسماء DNS ومتطلبات حالة قيمة الإصدار. يجب أن تحافظ المراجعة على وحدات بايت الإجابة الدقيقة وحدود التسجيل بدلاً من تطبيع التفاصيل قبل التحقق من الصحة. RFC 9990 ، القسم 4; RFC 9989 ، القسم 4.7 و4.8
احترام سلوك التجاوز والفشل
يمكن أن يوفر سجل الترخيص تجاوز وجهة إعداد التقارير بموجب الإجراء. يجب أن يستخدم معرف URI المهيمن نفس مضيف الوجهة المستخرج في البداية. يمنع هذا التقييد استجابة التخويل من إعادة توجيه العملية إلى سلسلة من المستلمين غير المرتبطين. إذا كان التأكيد يحتوي على تجاوز مع مضيف مختلف، فيجب ألا يقوم منشئ التقرير بإنشاء تقرير إلى URI الأصلي أو تجاوز.
إذا لم يؤكد التحقق التفويض، فيجب تجاهل معرف URI الخارجي. خطأ DNS المؤقت له علاجه الخاص: قد يختار المتلقي فشل التسليم مؤقتًا حتى يمكن تكرار اختبار التحقق لاحقًا. احتفظ بهذا الإذن كـ MAY، وليس ضمانًا عالميًا لإعادة المحاولة أو وصفًا لتطبيق تم اختباره. لا يزال فحص DNS الناجح لا يثبت وجود صندوق البريد الوجهة، أو يقبل حجم التقرير أو يغذي لوحة معلومات العميل المقصود. RFC 9990 ، القسم 4
التمييز بين طلبات تقرير التجميع والفشل
ل تقارير مجمعة، الإجراء مرتبط بـ rua. تم تحديد تقرير الفشل بشكل منفصل في RFC 9991. بالنسبة إلى وجهات تقرير الفشل الخارجية، يتطلب هذا المستند نفس إجراء التحقق الخارجي مع استبدال ruf أينما ظهر rua. لا تعامل تقارير الفشل على أنها ممكّنة تلقائيًا لمجرد تدفق التقارير المجمعة، أو قم بنسخ معالجة الوجهة المجمعة دون التعرف على نوع التقرير المنفصل.
تقارير الفشل تثير مخاوف إضافية بشأن الكشف عن البيانات لأن محتواها يمكن أن يكون أكثر تفصيلاً من الملخصات المجمعة. لا يعد سجل ترخيص DNS الصحيح بديلاً عن قرار المنظمة بشأن البيانات التي يمكن مشاركتها ومع من ولأي غرض. لا توفر هذه المخطوطة أي إذن لطلب التقارير الفعلية أو نقلها أو تحميلها. يجب أن يفي أي إعداد حقيقي بموافقات الخصوصية والمستلم والتشغيلية المعمول بها. RFC 9991 ، القسم 5 و 7
ورقة عمل البناء الخيالي والقبول
افترض أنه تم استرداد سياسة وهمية من blue.example.com وتطلب تقارير مجمعة على mailto:reports@red.example.net. مالك الترخيص المُنشأ هو blue.example.com._report._dmarc.red.example.net . إجابة TXT افتراضية قيمتها الكاملة هي v=DMARC1; يفي بمتطلبات الإصدار الأول المصور. لم يتم تنفيذ أي استعلام DNS ، ولا يدعي هذا المثال أن الأسماء لديها سجلات منشورة.
يجب أن تحتفظ ورقة العمل بنتيجة البحث عن السياسة، ومجال السياسة المكتشف، ومعرف URI الأصلي للتقارير، والمضيف الوجهة، ومقارنة المجال التنظيمي، والمالك المُنشأ، ونوع الاستعلام، والطابع الزمني، والسجلات التي تم إرجاعها بدقة، ونتائج التحليل. قم بإضافة حقل منفصل لأي تجاوز وتأكيد تقييد المضيف الخاص به. يجب أن يكون المراجع قادرًا على إعادة بناء الاسم دون الاعتماد على لقطة شاشة للموفر أو العرض المختصر لمحرر DNS .
استخدم قسم القبول الثاني للتجميع: الحساب المقصود وصندوق البريد الوجهة ونوع التقرير المعتمد ومالك خط الأنابيب. تصف هذه الحقول سير عمل التحقق المخطط له، وليس دليل الاستيعاب المكتمل. اجعل نتيجة علاقة DNS متميزة عن الاستلام والتحليل وإسناد المستأجر وعرض لوحة المعلومات. يمكن أن ينجح فحص الأذونات بينما يظل جزء آخر من مسار المجموعة دون حل.
جاري النشر والتنفيذ
يتطلب الكتالوج إنشاء بحث دقيق عن التفويض من نطاقات المصدر والوجهة والتحقق من إجابته. توفر هذه المسودة بناءًا خياليًا فقط. تظل الإجابة الفعلية ونص الاستعلام الأصلي وتنفيذ مجال الاستلام مفتوحين. لم يتم نشر أي سجل DNS ، ولم يتم الوصول إلى صندوق بريد ولم يتم إرسال أي تقرير.
قبل الإصدار كدليل تشغيلي، احصل على دليل معتمد لعلاقة الإنتاج الدقيقة واطلب من مراجع مؤهل التأكد من سياق اكتشاف السياسة، وتحليل الإصدار ومعالجة التجاوز. احتفظ بتاريخ المصدر وميز بين متطلبات المعايير وإعداد الحساب الخاص بالمزود. تظل جميع بوابات الإصدار الستة مفتوحة، بما في ذلك الأدلة الأصلية، والمراجعة البشرية، وقابلية تطبيق المصدر، وطرق الإنتاج، وإمكانية الوصول المرئي، وإصدار المالك.
يمكن أن يؤدي التغيير اللاحق في الوجهة أو مجال اكتشاف السياسة إلى تغيير مالك التفويض المطلوب. تعامل معها كعلاقة ذات نطاق جديد للتحقق بدلاً من افتراض أن الفحص الإيجابي القديم يغطي كل عنوان تقارير مستقبلي. والنتيجة المفيدة هي سلسلة أذونات قابلة للتدقيق، وليس مجرد قيمة TXT منسوخة.