بوابة بريد إلكتروني آمنة و DMARC حل المشكلات التشغيلية المتداخلة ولكنها غير قابلة للتبديل. قد تقوم البوابة بفحص الرسائل أو توجيهها أو عزلها أو تعديلها. يقوم DMARC بتقييم المصادقة المتوافقة ويوفر معلومات سياسة المجال للمستلمين. السؤال المهم هو كيف يتصرف مسارك بالكامل، بما في ذلك التحويلات بعد إنشاء التوقيع.
ارسم مسار الرسالة الفعلي
تقديم السجل والتوقيع ومعالجة البوابة والاستلام النهائي بالترتيب. حدد المكونات التي تتحكم فيها والهويات المصرح لكل منها بالتوقيع عليها. لا يمكن للرسم التخطيطي الذي يشير إلى تمكين البوابة فقط تحديد ما إذا كان جهاز الاستقبال المتلقي للمعلومات سيحصل على توقيع محاذٍ سليم. الحصول على الرسائل الأولية الأصلية والنهائية من مسار اختبار معتمد، مع الاحتفاظ بمعرفات الرسائل وأوقاتها.
DKIM يغطي الرؤوس المحددة والنص الأساسي. يمكن أن تؤدي إعادة كتابة النص إلى إبطال التوقيع الحالي حتى لو كان الرابط الذي تم تغييره جزءًا من ميزة أمان مشروعة. يحدد RFC 6376 سلوك التوقيع والتحقق. مواصفات DKIM. الحفاظ على قائمة العناوين الموقعة، تحديد العنوان القانوني الاختيارات وأي معلمة لطول الجسم عند شرح فشل محدد.
مكان التحقق والتوقيع عمدا
يمكن لبوابة البريد الوارد التحقق من الرسالة قبل التعديل، ولكن هذه النتيجة الداخلية ليست جديرة بالثقة تلقائيًا لكل مستلم. حدد كيف يتعرف النظام التالي على النتائج الموثوقة وماذا يفعل مع تأكيدات الرأس غير الموثوقة. RFC 8601. قد يصل المدقق اللاحق الذي يتحقق من البايتات المعدلة إلى نتيجة مختلفة لسبب مشروع.
بالنسبة للمسار الصادر الذي تديره، فإن التوقيع بعد التحويلات المعتمدة يمكن أن يتجنب كسر التوقيع النهائي. يجب أن يكون المُوقع مفوضًا لمجاله، و تنسيق لا يزال بحاجة إلى التقييم. إن إضافة توقيع صالح من نطاق بوابة غير ذي صلة لا يؤدي بالضرورة إلى نتيجة DMARC متوافقة. لا تقم بإزالة التفتيش الأمني لمجرد الحفاظ على التوقيع دون مراجعة تصميم التحكم الأوسع.
تتبع إعادة كتابة افتراضية
لنفترض أن أحد مُوقعي اختبار العلامة التجارية المعتمدين قام بتوقيع نص رسالة يحتوي على عنوان URL. تقوم البوابة بعد ذلك بتغيير عنوان URL المغطى دون إضافة توقيع معتمد بعد ذلك. إذا تغيرت وحدات البايت الموقعة الأساسية، فلن يتم التحقق من صحة التوقيع السابق مقابل النص الذي تم تغييره. التحويل الذي يترك وحدات البايت الموقعة الأساسية ذات الصلة دون تغيير لا يحتاج إلى كسر التوقيع. افحص التحديد الأساسي والرؤوس المحددة وأي حد l= بدلاً من افتراض أن كل عملية إعادة كتابة لها نفس التأثير.
إذا قام موقع معتمد منفصل بالتوقيع على الرسالة المحولة النهائية، فقد يتم التحقق من هذا التوقيع الجديد حتى أثناء فشل التوقيع القديم. ولا يصلح التوقيع القديم أو يثبت أن الموقع الجديد يتمتع بسلطة تجارية. قم بتقييم محاذاة المجال d= الجديد ونتيجة جهاز الاستقبال النهائي الموثوق به. هذه نتائج افتراضية قائمة على البروتوكول، وليست عينات رسائل أولية أو مفاتيح تم إنشاؤها أو مخرجات dkimpy أو تجربة بوابة منفذة.
ترجمة النتيجة إلى اختبار الطريق
في الإنتاج، قم بإعادة إنتاج التحويل المعتمد ذي الصلة باستخدام المستلمين الخاضعين للرقابة والتكوين المدعوم من البائع. التقط النتائج الموثوقة للمستلم النهائي بدلاً من استنتاج النجاح من وحدة تحكم البوابة. قارن نفس مراجعة المحتوى عبر المسار، ولاحظ التغييرات الأخرى مثل بادئات الموضوع أو إخلاء المسؤولية. التوقيع الجديد العابر لا يثبت بقاء المصادقة السابقة.
التعامل مع فشل الاختبار أيضًا. إذا كانت خطوة التوقيع غير متاحة، فحدد ما إذا كان البريد سيظل في قائمة الانتظار أو يفشل أو يغادر بدون التوقيع المتوقع. احتفظ بتعليمات الاسترداد مرتبطة بالخدمة الفعلية. تجنب تجاوز الطوارئ الذي يحول مشكلة المصادقة المضمنة إلى ترحيل غير مقيد أو تسليم غير خاضع للفحص.
يجب أن يذكر سجل القبول المسار الذي تم اختباره والتحويل ووضع الموقّع والهويات النهائية ونتيجة جهاز الاستقبال. الحفاظ على عمليات فحص منفصلة لتصفية البرامج الضارة، التصيد الكشف ومصادقة المجال. ويعد اجتياز اختبار واحد دليلاً مفيدًا على هذه الإمكانية، وليس شهادة بأن الرسالة أو البوابة بأكملها آمنة.
حدود المصدر والتنفيذ
RFC 9989 الأقسام 4.4 و5.3.5 و5.4 التمييز بين المصادقة والمحاذاة والتعامل؛ المرور لا يؤيد محتوى الرسالة. إن القرارات التشغيلية هنا هي توصيات محددة النطاق وأمثلة افتراضية بشكل واضح، وليست اختبارات جديدة للعميل أو المزود أو التركيبة التاريخية. إن أي تغيير حقيقي يتطلب نطاقًا معتمدًا خاصًا به، وأدلة محتفظ بها، وقرارًا مسؤولًا.