ما يوسع البدل عمدا
قد يكون مستهلك التقرير على استعداد لتلقيه DMARC تقارير لأي مجال بدلاً من نشر مالك ترخيص واحد لكل علاقة. RFC 9990 يسمح صراحةً بسجل DNS الخاص بأحرف البدل لهذا الغرض. مثاله يضع أ سجل TXT في *. _report._dmarc.example.com مع v=DMARC1. يعد هذا اشتراكًا واسع النطاق من خلال النطاق المتلقي، وليس آلية تثبت أنه تم فحص كل عميل مُبلغ.
التمييز مهم من الناحية التشغيلية. يمكن لمزود الخدمة اختيار كمية واسعة بشكل شرعي بينما يطلب التحقق على مستوى الحساب بشكل منفصل قبل عرض البيانات للعميل. لا ينفذ سجل DNS ضوابط الحساب هذه. يجب أن تحدد المراجعة الأمنية بالضبط الحدود التي تغيرها حرف البدل وأي الحدود تظل مسؤولية التطبيق المتلقي ومالكيه. RFC 9990 ، القسم 4
احتفظ بالاستعلامات الدقيقة مرئية أسفل حرف البدل
لا يزال المُبلغ ينشئ بحث التفويض من المجال الذي تم استرداد السياسة فيه، وهو _report. تسميات _dmarc والمضيف الوجهة. حرف البدل عبارة عن إستراتيجية نشر DNS يمكنها الإجابة على هذه الاستفسارات؛ ولا يلغي الحاجة إلى فهم المالك الذي تم الاستعلام عنه أو القيمة التي تم إرجاعها. الحفاظ على المالك والرد الدقيق عند التحقق من علاقة معينة.
يجب أن تجتاز إجابة التأكيد قواعد تحليل التحقق الخارجي، بما في ذلك الإلزامية الأولى v=DMARC1. تظل قيمة الإصدار DMARC1 مع حالة الأحرف المطلوبة. لا تعد نية المسؤول لاستخدام حرف البدل دليلاً على أن استعلامًا معينًا يتم حله كما هو متوقع في شجرة DNS المنشورة. يمكن أن تؤثر سجلات الاسم الدقيق وبنية DNS على الدقة الحقيقية، لذلك يجب أن تحتفظ الاختبارات المقترحة بالإجابة الفعلية بدلاً من افتراض أن لقطة الشاشة تثبت التغطية. RFC 9990 ، القسم 4; RFC 9989 ، القسم 4.7
إذن دخول منفصل عن الملكية والوصول إلى البيانات
تشير حرف البدل إلى أن مجال الاستقبال مستعد لتلقي التقارير التي يغطيها ترتيب البروتوكول. لا يثبت أن الشخص الذي يسجل الدخول إلى لوحة المعلومات يتحكم في المجال المسمى داخل التقرير. كما أنه لا يثبت أن مرسل العنصر الذي تم تحميله جدير بالثقة أو أن التقرير ينتمي إلى الحساب الذي يستلمه.
حدد متطلبات القبول على مستوى التطبيق بشكل منفصل: ربط المجال بالمستأجر، والوصول المصدق، وتتبع المصدر، والمعالجة المكررة، ومراجعة النطاقات غير المتوقعة. هذه عناصر تحكم مقترحة، وليست ادعاءات بشأن منصة EmailAuth التي تم تنفيذها. لا ينبغي للتقرير الذي يشير إلى مؤسسة أن ينشئ علاقة ملكية تلقائيًا أو يعرض البيانات للحساب الأول الذي يطالب بالاسم.
احتفظ بالفوترة والإعداد وترخيص البيانات بعيدًا عن استنتاج DNS . إن الاستعداد الواسع لتلقي حركة المرور لا يعني الموافقة على تسجيل مؤسسة في خدمة مدفوعة أو نشر تكوينها الملحوظ. إذا كان سير العمل يحتاج إلى هذه الإجراءات، فإنه يتطلب قرارات وأدلة واضحة تتجاوز سجل أحرف البدل. يجب أن تحدد المراجعة المالك المسؤول عن كل حد بدلاً من التعامل مع نتيجة DNS واحدة كموافقة شاملة.
حساب لإساءة الاستخدام وضغط الموارد
يحذر RFC 9990 من أن محتوى التقرير يمكن أن يهاجم برنامج إلغاء الضغط أو محلل XML وأن بيانات التقرير قد تكون مزورة. ولذلك يجب أن تفترض خدمة الاستقبال واسعة النطاق أن الإذن بتلقي التقارير لا يجعل كل ملف يصل آمنًا أو دقيقًا. ينتمي تخطيط السعة وحدود المحلل اللغوي وفحوصات المصدر إلى جانب تصميم الترخيص.
اقتراح أحجام الرسائل المحدودة، وحدود الحجم غير المضغوط، وتحليل ميزانيات الوقت، وعزل قائمة الانتظار، والتنبيه بحجم مصدر غير متوقع. يجب اختيار القيم الرقمية واختبارها للبيئة الفعلية بدلاً من نسخها من حد عالمي مخترع. احتفظ بأسباب الرفض وتجنب السماح لمصدر واحد صاخب بإخفاء أدلة العميل غير ذات الصلة. لا يُزعم أنه تم نشر أو اختبار أي من عناصر التحكم هذه هنا. RFC 9990 ، القسم 8.1 و8.2
إذن السحب والتخزين المؤقت
يمكن لمستهلك التقرير المثقل بالحجم أن يزيل سجل DNS المؤكد، لكن RFC 9990 يشير إلى أن التخزين المؤقت الإيجابي يمكن أن يؤخر التأثير طالما TTL للسجل. لا تعد بالوقف الفوري للبلاغات بعد تغيير DNS . قد تحتاج أنظمة الإدخال أيضًا إلى التعامل مع التقارير التي تم إنشاؤها بالفعل أو وضعها في قائمة الانتظار بشكل مستقل عن حالة البحث الجديدة.
يجب أن تحدد خطة السحب مالك السجل، ومسار الموافقة، وأدلة TTL ذات الصلة، وسلوك المدخول أثناء عملية النقل ومسؤوليات الاتصال. قد تؤثر إزالة حرف البدل على العديد من العلاقات المشروعة في وقت واحد. يحتاج الانتقال المقترح إلى الترخيص الصريح لكل مجال إلى جرد لتلك العلاقات وخطة تحقق، وليس فقط سجل الحذف.
حافظ على التمييز بين سحب DNS وإلغاء الوصول إلى التطبيق. لا تؤدي إزالة إذن الاستلام في حد ذاتها إلى حذف التقارير المخزنة أو إغلاق حسابات العملاء أو إلغاء جلسات المستخدم الحالية. هذه عناصر تحكم منفصلة لها آثار منفصلة على التفويض والاحتفاظ. RFC 9990 ، القسم 4
مراجعة الحدود الخيالية وتصميم الاختبار
خذ بعين الاعتبار مستهلكًا خياليًا على reports.example.net الذي يقترح * . _report._dmarc.reports.example.net بالقيمة v=DMARC1; . بالنسبة للسياسة الافتراضية على blue.example.com ، سيكون الاستعلام الدقيق هو blue.example.com._report._dmarc.reports.example.net . لم يتم تنفيذ أي استعلام أو منشور أو تثبيت DNS لهذا المثال.
ستحتفظ خطة الحالة الإيجابية بالاستعلام الدقيق وتؤكد اجتياز قيمة التفويض التي تم إرجاعها للتحليل. يجب اختيار خطة الحالة السلبية بعناية: نطاق مصدر آخر موجه إلى نفس الوجهة المعتمدة على نطاق واسع ليس بالضرورة غير مصرح به، لأن حرف البدل يغطي عمدا نطاقات المصدر بشكل عام. بدلاً من ذلك، يمكن لمضيف الوجهة الذي يتم التحكم فيه بشكل منفصل دون إذن أن يوضح حدود الوجهة الخارجية، بشرط أن تكون أي تجهيزات فعلية مصرح بها ومعزولة.
يجب أن تسرد ورقة العمل مالك حرف البدل، والتغطية المتوقعة، ومالكي الاختبار الدقيق، والإجابات، وتحليل الإصدار، وحدود مضيف الوجهة، وعمليات التحقق من وصول المستأجر. ويجب عليه أيضًا تسجيل خطة التراجع والقيود المفروضة على معالجة التقرير. النتائج المتوقعة هي فرضيات التصميم حتى يتم إجراء الاختبارات الفعلية المحددة؛ ولا يجب أن يتم تصنيفها على أنها مقبولة لمجرد أن المنطق معقول.
الأدلة الأصلية التي لم يتم حلها وبوابات الإفراج
يتطلب الكتالوج صاحب التفويض والإجابة الدقيقة، بما في ذلك الاختبار الإيجابي واختبار الوجهة غير المصرح بها. تظل تلك الملاحظات الأصلية مفتوحة. توفر هذه المخطوطة تصميمًا اختباريًا مقترحًا وأسماء خيالية، وليس نشرًا فعالاً لأحرف البدل أو تقييم الوصول إلى الحساب.
قبل النشر كدليل تشغيلي تم التحقق منه، يجب على المراجع المؤهل فحص استجابات DNS الفعلية والتأكد من أن الاختبار السلبي يتجاوز بالفعل حدود التفويض المقصودة. تظل الأدلة الأصلية، والمراجعة البشرية، وقابلية تطبيق المصدر، وطرق الإنتاج، وإمكانية الوصول المرئي، وإصدار المالك مفتوحة. لم يتم إجراء أي اتصال خارجي أو تحميل تقرير أو تعديل DNS لهذا العمل.