جعل قابلية التشغيل البيني مقارنة قابلة للتكرار
بيان أن جهاز الاستقبال يدعم التحديث DMARC ليست نتيجة التشغيل البيني. والسؤال المفيد هو ما إذا كانت التطبيقات المحددة، في ضوء المدخلات المكافئة الخاضعة للرقابة، تنتج الاكتشاف المتوقع، تنسيقوالسياسة وسلوك الإبلاغ. تحتاج المقارنة إلى الحفاظ على تلك المراحل بدلاً من تقليل التجربة إلى ما إذا كانت رسالتان قد وصلتا إلى البريد الوارد.
ابدأ بكتالوج الحالة الذي تم إصداره ومالك الاختبار المحدد. قم بتسجيل برنامج أو خدمة جهاز الاستقبال والتكوين ومعلومات الإصدار التي يمكن الوصول إليها وأي معلومات مجهولة. لا يجوز للخدمة المُدارة الكشف عن إصدار التنفيذ الخاص بها؛ هذا القيد ينتمي إلى المصفوفة. لا تستبدل المعلومات المفقودة بمطالبة اعتماد مستمدة من إعلان المنتج أو الطابع الزمني للتقرير الحديث.
تجميد المدخلات التي يمكن أن تغير النتيجة
في كل حالة، احتفظ ببايتات الرسالة والمغلف وافتراضات مصدر الاتصال وبيانات DNS ذات الصلة وتوقيت المراقبة وملف تعريف التكوين. قم بعمل اختلافات بين عمليتي اختبار متعمدة ومرئية. إذا قام أحد المسارات بتعديل رسالة موقعة أو استخدم نطاق مغلف مختلف، فلن تقتصر المقارنة على سلوك تنفيذ DMARC فقط.
استخدم فقط النطاقات وأجهزة الاستقبال والرسائل غير الحساسة الخاضعة للرقابة. احتفظ بحالات التصميم الخيالي منفصلة عن التركيبات القابلة للتنفيذ وعينات التسليم الفعلية. كتابة النتيجة المتوقعة ومرجع مواصفاتها قبل إجراء الاختبار؛ وإلا فإن النتيجة المفاجئة يمكن وصفها بأثر رجعي كما هو متوقع. يجب أن تظل حالة عدم التشغيل بشكل صريح غير قيد التشغيل، ولا تتلقى تصريحًا مستنتجًا من الوثائق.
مخزون المرسل مهم أيضًا. قم بتضمين الطرق التمثيلية المشروعة، وخاصة الخدمات غير المباشرة والدورية، عند تحديد ما إذا كانت تغطية المختبر ذات صلة بتغيير الإنتاج. يمكن أن تكون حالة البروتوكول صحيحة مع حذف تدفق الأعمال الذي سيتأثر بالفعل.
قارن الاكتشاف والمحاذاة قبل التصرف
RFC 9989 القسم 4.10 يصف سلوك السير على شجرة DNS ، بينما يمكن للتطبيقات السابقة استخدام طريقة الاكتشاف القديمة المدعومة. يجب أن تغطي الحالات سياسة مجال المؤلف الواضحة والترتيبات الاحتياطية الخاضعة للرقابة. إضافة حالات سياسة النطاق الفرعي والنطاق غير الموجود فقط مع شروط DNS المحددة بوضوح؛ تسمية تقول أن النطاق الفرعي ليس كافيًا لتحديد السياسة المتوقعة.
التقط السجل المحدد والمعرفات المصادق عليها المستخدمة للمحاذاة. ثم قم بتسجيل سياسة p أو sp أو np المحددة وحالة الاختبار. RFC 9989 القسم 4.4 يحدد علاقة المحاذاة. تمرير SPF أو DKIM بالنسبة للهوية غير ذات الصلة، يجب ألا يتم تصنيفها بشكل خاطئ على أنها DMARC ناجحة لمجرد أن المتلقي قبل الرسالة في النهاية.
وأخيرًا، قم بتسجيل التجاوزات المحلية والتصرف الفعلي كنتائج منفصلة. يمكن أن تؤدي تصفية المحتوى والتوجيه والقرارات المحلية إلى إنشاء نتائج تسليم مختلفة حتى عندما توافق حسابات DMARC العادية. قم بتشخيص أول مرحلة مختلفة بدلاً من إسناد كل اختلاف في صندوق البريد إلى اكتشاف السياسة.
تضمين اختبار الانتقال دون افتراض التكافؤ
هناك حالة مفيدة تقارن كيفية معالجة عمليات التنفيذ المحددة سجل تحتوي على p=reject و t=y. تحت RFC 9989 القسم 4.7، يكون العلاج الاختباري للرسالة الفاشلة بمستوى واحد أقل، وهو العزل. قد يتبع التنفيذ القديم الذي لا يتعرف على منطق مدعوم مختلفًا. وهذا سؤال توافق متوقع يجب قياسه، وليس سببًا لنشر هذا السجل كمفتاح أمان عالمي.
افصل قضايا معاهدة التعاون بشأن البراءات التاريخية عن قضايا t. لا ينبغي الإعلان عن توافق الخطة التي طلبت أخذ العينات من قبل لمجرد أن جهاز الاستقبال المحدث يتجاهل عنصر التحكم القديم دون وجود خطأ في بناء الجملة. إن تأثير العمل المقصود والآلية المحددة والنتيجة المرصودة كلها تحتاج إلى مجالات خاصة بها.
احتفظ بحالات العلامات غير المعروفة والسياسة المفقودة والمدخلات المشوهة ضمن نطاق اختبار خاضع للرقابة. لا تستخدم مجال الإنتاج كهدف تجريبي للسجلات الغامضة عمدًا. يجب أن يحدد تصميم الاختبار نفسه متطلبات الموافقة والاسترداد ذات الصلة قبل أي تنفيذ تشغيلي.
اختبار التقارير كقدرة منفصلة
RFC 9990 يحدد بنية التقرير المجمع، بما في ذلك طريقة الاكتشاف الاختيارية وسياق الاختبار. يمكن للتقرير الذي يحمل هذه الحقول أن يدعم ملاحظة حول هذا التقرير؛ لا يثبت الحقل الاختياري المحذوف السلوك القديم. احتفظ بالتقرير الأولي وملف تعريف المحلل اللغوي، لأن المستهلك يمكن أن يفقد المعلومات حتى عندما يقوم المتلقي بإنشائها بشكل صحيح.
يمكن أن تتضمن فترات التقرير تحولات في السياسة، لذا فإن التجميع الواحد لا يمثل دائمًا نسخة من سياسة واحدة مجمدة. قم بمحاذاة الإطار الزمني للمقارنة والأدلة المصدرية قبل استخدام الأعداد لشرح رسالة معينة. ينتمي إلغاء البيانات المكررة وتوافق المخطط إلى خطة اختبار التقارير بدلاً من إخفائها في لوحة المعلومات.
يعد الإبلاغ عن الفشل بُعدًا مستقلاً آخر. RFC 9991 يترك الجيل خاضعًا لاستعداد المتلقي وقيود الخصوصية. لا تقرير الفشل لا يعد دليلاً كافيًا على فشل اختبار التشغيل البيني. قم بتسجيل ما إذا كان الإبلاغ مطلوبًا ومدعومًا ومصرحًا به ومستلمًا وقابلاً للتفسير دون جمع محتوى الرسالة غير الضروري.
مصفوفة خيالية مع عدم وجود خلايا نتائج ملحوظة
تسمي ورقة العمل الخيالية جهاز الاستقبال A كمرجع دلالي حالي وجهاز الاستقبال B كملف تعريف قديم. يتم تعيين نفس الرسالة المخترعة ولقطة DNS لكل منهما لـ p=reject; t=y حالة. عمود السياسة المتوقعة لـ A مشتق من المواصفات. لا يزال تنفيذ الخيار "ب" وجميع النتائج الفعلية يتطلب أدلة؛ لا يُفترض أن يتصرف أي منتج مثل الملصق.
تتضمن المصفوفة المخططة أيضًا عنصر تحكم محاذيًا مباشرًا، وحالة مجال مصادق عليه غير ذات صلة، وحالة اكتشاف احتياطي، وحالات تنسيق مجمعة. تظل كل خلية تنفيذ غير قيد التشغيل. وهذا يجعل ورقة العمل إعدادًا مفيدًا دون الحاجة إلى إثبات التصنيع للمطابقة أو اعتماد جهاز الاستقبال.
الحفاظ على متطلبات الإصدار الدقيق
بوابة الأدلة الأصلية هي: الاحتفاظ بمصفوفة قابلية التشغيل البيني ذات الإصدار مع حالات إدخال متطابقة ونتائج كاملة تمت ملاحظتها. متطلبات التشغيل هي: التحقق من صحة المواصفات الأساسية الحالية والاحتفاظ بمثال عملي قبل الصياغة. المصفوفة الخيالية المحتفظ بها لا ترضي المراقبة الحية ولا الاستعداد للإنتاج. تظل أدلة التنفيذ المحددة والنتائج الخاضعة للرقابة والمراجعة البشرية للشركات الصغيرة والمتوسطة والموافقة على بدء الأعمال وتفويض النشر مفتوحة. لم تقم هذه المخطوطة بإجراء أي اختبار لجهاز الاستقبال أو تغيير DNS أو نقل الرسائل.