يستطيع مدقق النقل اكتشاف مشكلة حقيقية دون إثبات أمان كل رسالة ترسلها أو تستقبلها مؤسستك. تراقب معظم عمليات التحقق نقطة نهاية محددة في وقت معين باستخدام محلل معين وطريقة التحقق من الصحة. وبالتالي فإن النتيجة التي يمكن الدفاع عنها تتضمن النطاق والتغطية المفقودة، وليس مجرد شارة النجاح.
تحديد مخزون طريق التسليم
مراجع: RFC 8461 §3.4, RFC 8461 §5.1, RFC 7672 §2.2.
قم بإدراج مجالات المستلمين وأسماء مضيف MX والأولويات وعناوين IPv4 و IPv6 والبوابات المستضافة ومسارات تجاوز الفشل. لاحظ ما إذا كان الاختبار يتبع توجيه MX العادي أو مضيفًا ذكيًا تم تكوينه بشكل صريح. سجل تنفيذ المرسل وما إذا كان يدعمه MTA-STS, DANE أو سياسة TLS الإلزامية المحلية. يمكن لأنظمة الإرسال المختلفة اتخاذ قرارات مختلفة لنفس مجال الاستقبال.
ثم حدد المطالبة التي يمكن أن يدعمها كل شيك. يمكن لطلب HTTPS العام إثبات توفر السياسة من وجهة النظر تلك. يمكن لمسبار TLS ملاحظة الشهادة المقدمة على العنوان المختار. يمكن أن يوفر استعلام DNS الذي تم التحقق من صحته أدلة حول DNSSEC الحالة ضمن نموذج ثقة المحلل المحدد. لا شيء وحده يثبت أن الإرسال الحقيقي MTA استخدمت نفس البيانات وفرضت سياسة التسليم المتوقع.
التقاط الحالة بدلاً من النتائج فقط
مراجع: RFC 8461 §3.3, RFC 8461 §4, RFC 7672 §3.
بالنسبة إلى MTA-STS ، احتفظ بسجل الاكتشاف وبايتات سياسة HTTPS الدقيقة ووقت الاسترداد والوضع والعمر وحالة ذاكرة التخزين المؤقت للمرسل. بالنسبة إلى DANE ، احتفظ بـ MX و TLSA الإجابات وحالة التحقق من الصحة ومقارنة الارتباط. لكل اتصال SMTP ، التقط المضيف المحدد وIP، STARTTLS التفاوض ونتائج التحقق من النظراء وقرار التسليم. RFC 8461 الأقسام 3-5, RFC 7672 الأقسام 2-3.
يجب أن يسجل المسبار الفاشل مرحلة فشله. مهلة DNS ، مهلة TCP، غياب STARTTLS ، فشل المصافحة وعدم تطابق الشهادة ليست نتائج قابلة للتبديل. كما أن المصافحة الناجحة لا تثبت أن المرسل سيرفض الاتصال المنخفض في المستقبل. قم بتضمين الحالات السلبية الخاضعة للرقابة عند التصريح بذلك، خاصة قبل تفعيل متطلبات النقل الصارمة.
العمل من خلال فجوة التغطية
في مثال المخزون الاصطناعي هذا، يحتوي mx1.example.net على مسارات IPv4 و IPv6 و mx2.example.net عبارة عن نسخة احتياطية. تغطي عينة المراقبة عنوان IPv4 الخاص بـ mx1 فقط. يجب أن يضع المخزون علامة على مسارات IPv6 والنسخ الاحتياطي التي لم يتم اختبارها بدلاً من نشر النجاح عبر الثلاثة. الملاحظة اصطناعية بشكل واضح ولا تحمل أي ادعاء بوجود اتصال حقيقي.
أضف صف قبول من جانب المرسل لـ MTA الداعم باستخدام سياسة فرض صالحة، وآخر بذاكرة تخزين مؤقت فارغة، ومرسل قادر على DANE مع TLSA تم التحقق من صحته. تظل هذه الصفوف معلقة حتى يتم التقاط السجلات الفعلية. وهذا يجعل خطة القبول مفيدة دون تقديم النتائج المتوقعة كقياسات. كما أنه يسمح للمستجيب للحوادث بمعرفة ما إذا كان قد تم استخدام المسار الفاشل أم لا.
التوفيق بين التقارير والأدلة التشغيلية
مراجع: RFC 8460 §4.1, RFC 8460 §4.2.
TLS-RPT يمكن أن تكشف التقارير عن حالات الفشل التي شاهدها المرسلون المشاركون خلال فترة التقرير، مما يكمل التحقيقات في الوقت المناسب. لا تعد أعداد الجلسات الخاصة بهم أعدادًا للرسائل الفريدة، كما أن تغطيتها ليست عالمية. لا تثبت فترة إعداد التقارير الهادئة نجاح جميع المسارات، ويمكن أن تؤدي عمليات إعادة المحاولة المتكررة إلى تعقيد تقديرات تأثير الأعمال. RFC 8460 القسم 4.4.
احتفظ بالنتيجة الأولية، والطابع الزمني، وإصدار الأداة أو الأمر، والاستنتاج الأضيق الذي استخلصته منها. أعد الاختبار بعد تجديد الشهادة وترحيل MX وتغييرات DNSSEC وتحديثات السياسة. تتضمن حزمة المراجعة سبعة نصوص استرجاع تم الاحتفاظ بها في 7 نوفمبر 2026، مع وحدات بايت شهادة النظير للجلسات الأربع التي وصلت إلى الحصول على الشهادة. وهي تغطي عميل/خادم IPv4 Python المحلي في المنافذ التي تم إنشاؤها بمدخلات الثقة والسياسة التي تم تكوينها بشكل صريح، وليس الإنترنت SMTP أو سلسلة التحقق من DNSSEC أو قوائم انتظار MTA للإنتاج أو الامتثال الكامل لملف تعريف شهادة MTA-STS . تم فحص الجلسات التاريخية ولكن لم يتم إعادة تشغيلها هنا. لم يتم اختبار مثال Internet IPv4 و IPv6 ومسارات النسخ الاحتياطي؛ لا شيء يرث تصريحًا محليًا. يتحقق نموذج التغطية دون اتصال الذي تم تنفيذه حديثًا فقط من أن مسارًا اصطناعيًا تمت ملاحظته يترك المسارات الأخرى المدرجة دون اختبار. قم بالتقاط MTA المقصود وملاحظات التوجيه قبل المطالبة بضمان النشر.