يمكن لنظام البريد الإبلاغ SPF تمرير و DKIM تمر بينما DMARC لا يزال يفشل. وهذه النتيجة ليست متناقضة. تبدأ كل آلية بهوية مختلفة، ويضيف DMARC اختبار العلاقة بين هوية المرور والمجال في عنوان "من" للرسالة.
الطريقة الموثوقة للتحقق من الرسالة هي تسجيل سلسلة الهوية قبل تغيير DNS . ابدأ بالمجال الذي يراه المستلم في "من". ثم قم بتسجيل المجال المستخدم لنظام التعرف على SPF وكل مجال موجود في ملف توقيع DKIM. فقط بعد ذلك يجب عليك التقييم تنسيق ونتيجة DMARC على مستوى الرسالة.
قم بتسمية الهويات الثلاث قبل قراءة النتائج
تأمل هذه الرسالة الخيالية:
من: فريق الفوترة < statements@billing.example.com > Return-Path : < bounce+739@mailer.example.net > DKIM-Signature : ... d=billing.example.com; s=outbound1; ...المجال من هو billing.example.com. يطلق عليه DMARC اسم مجال المؤلف. ال مرسل المغلف ويمثلها هنا Return-Path اِختِصاص mailer.example.net; للتحقق من البريد من هذه الرسالة العادية، هذه هي الهوية التي يتم تقييم نظام التعرف على هوية SPF ضمنها RFC 7208 §2.4. منفصل HELO يمكن أن يحدث الاختيار أيضًا ضمن RFC 7208 §2.3; تم تحديد معالجة Return-Path في RFC 5321 §4.4. مجال توقيع DKIM هو قيمة d=، وهو billing.example.com في هذا المثال.
اسم العرض مثل فريق الفوترة ليس هوية مصادقة. الرد على ليس مجال المؤلف أيضًا. يمكن أن تكون هذه الحقول ذات أهمية للتحقيق في الاحتيال، ولكنها لا تحل محل النطاقات التي يقارنها DMARC .
تسجيل النتائج والمحاذاة بشكل منفصل
يعني تمرير نظام التعرف على SPF الأولي أن مصدر الاتصال قد تم اعتماده لهوية نظام التعرف على هوية SPF التي تم تقييمها. يعني مرور DKIM الأولي التوقيع الذي تم التحقق منه d= المجال ومواد الرسالة المغطاة. لا تشير أي من النتيجتين، في حد ذاتها، إلى أن المجال الخاص به له العلاقة المطلوبة مع From.
ولذلك يحتاج DMARC إلى عمودين لكل مسار:
- المسار: SPF )؛ سؤال المصادقة: هل اجتاز نظام التعرف على هوية SPF هوية المغلف التي تم تقييمها؟; سؤال المحاذاة: هل تتوافق هذه الهوية مع مجال المؤلف؟
- المسار: DKIM ؛ سؤال المصادقة: هل مر هذا التوقيع لمجاله d=؟; سؤال المحاذاة: هل يتماشى المجال d= مع مجال المؤلف؟
تحت RFC 9989 §3.2.10.2، تتطلب المحاذاة الصارمة المساواة الدقيقة في المجال. تحت RFC 9989 §4.10.2، تستخدم المحاذاة المريحة علاقة اكتشاف المجال التنظيمي المعمول بها. لا تقترب من هذا الحد عن طريق أخذ التسميتين الأخيرتين، لأن قواعد اللاحقة العامة يمكن أن تجعل هذا الاختصار خاطئًا.
العمل من خلال تمريرة وتمريرة خام مضللة
ما يلي هو مثال تعليمي تركيبي، وليس رسالة عميل. افترض وجود سياسة صالحة قابلة للتطبيق، وعمليات فحص مكتملة، ونتائج استلام موثوقة، وأوضاع محاذاة معروفة؛ RFC 9989 §5.3.5 يحدد قاعدة النجاح/الفشل الناتجة.
- الملاحظة: من؛ الرسالة أ: alerts@example.com ؛ الرسالة ب: alerts@example.com
- الملاحظة: نتيجة SPF ؛ الرسالة أ: قم بالتمرير إلى bounce.vendor.example.net ؛ الرسالة ب: قم بالتمرير إلى bounce.vendor.example.net
- الملاحظة: محاذاة SPF ؟؛ الرسالة أ: لا؛ الرسالة ب: لا
- الملاحظة: نتيجة DKIM ؛ الرسالة أ: قم بالتمرير باستخدام d=example.com; الرسالة ب: قم بالتمرير باستخدام d=vendor.example.net
- ملاحظة: محاذاة DKIM ؟؛ الرسالة أ: نعم؛ الرسالة ب: لا
- الملاحظة: DMARC على مستوى الرسالة؛ الرسالة أ: المرور عبر DKIM ؛ الرسالة ب: فشل
تمرر الرسالة "أ DMARC لأن توقيع DKIM واحد يتم التحقق منه ومحاذاته. لا تؤدي نتيجة SPF غير المحاذية إلى إلغاء هذا المسار الصحيح. تحتوي الرسالة B على تمريرتين للمصادقة الأولية، ولكن لا يتطابق أي من النطاقات المصادق عليها مع مجال المؤلف، لذلك لا يوجد مسار DMARC عابر.
يعد هذا الجدول أيضًا سجل تغيير مفيدًا. يوضح ما إذا كان الإصلاح ينتمي إلى هوية المغلف أو تكوين التوقيع أو المجال المرئي من. لا يعد الرمز الأخضر الذي لا يحتوي على هذه النطاقات دليلاً كافيًا للسماح بتغيير DNS .
فحص كل توقيع DKIM
يمكن أن تحمل الرسالة أكثر من توقيع DKIM واحد. يمكن لكل من الخدمة الصادرة والبوابة والوسيط إضافة واحدة. تقييم كل توقيع بشكل مستقل. يمكن لتوقيع تمرير محاذٍ أن يوفر مسار DKIM حتى عندما يكون التوقيع الآخر غير محاذي أو يفشل.
لا تستنتج محدد من اسم المزود اقرأ s= القيمة من رأس DKIM-Signature الفعلي، ودمجها مع هذا التوقيع d= المجال، والاستعلام عن اسم DNS الناتج تحت RFC 6376 §3.6.2.1. يؤدي نشر المفتاح إلى إتاحة مواد التحقق فقط. لا يزال يتعين على نظام الإرسال إنشاء توقيع صالح باستخدام المفتاح الخاص المقابل.
يمكن أن يؤدي البريد غير المباشر إلى تغيير المحتوى الموقع أو مسار المغلف. ومن ثم يمكن أن يؤثر إعادة التوجيه على نظام التعرف على SPF ، بينما يمكن أن تؤثر تعديلات القائمة DKIM . تعامل مع المسار المرصود كدليل للتحقيق، وليس دليلاً على أن المرسل الأصلي أو الوسيط كان ضارًا.
استخدم أدلة الاستلام الموثوقة
Authentication-Results يمكن تلخيص الهويات والنتائج، ولكن الثقة تعتمد على مكان إضافة الرأس. يمكن للمرسل إدراج رأس يدعي النجاح. تحت RFC 8601 §7.1، استخدم النتيجة التي ينتجها نظام الاستقبال الذي تديره، أو أي حدود أخرى تفهم كيفية التعامل معها.
عندما تم رفض الرسالة قبل التسليم، فقد لا تكون هناك نسخة تم تسليمها. استخدم استجابة الرفض وسجلات الموفر وأي قياس استقبال عن بعد متاح. لا تخترع الهويات المفقودة من رمز الخطأ وحده.
تحويل سلسلة الهوية إلى سجل تشغيلي
لكل مرسل مادة، احتفظ بما يلي:
- صاحب العمل والتطبيق؛
- من المجالات المصرح باستخدامها؛
- هوية المغلف المرصودة؛
- كل DKIM d= المجال والمحدد؛
- نتيجة المصادقة لكل مسار؛
- وضع المحاذاة والاستنتاج؛
- تاريخ اختبار تمثيلي ومعرف الرسالة.
يفصل هذا السجل ترخيص العمل عن أدلة البروتوكول. كما أنه يمنع حدوث خطأ شائع: تغيير جذر المنظمة سجل SPF لحل مشكلة محاذاة DKIM ، أو تغيير سياسة DMARC عندما يكون تكوين المرسل هو الخلل الحقيقي.
بمجرد أن تصبح سلسلة الهوية واضحة، استخدم دليل استكشاف أخطاء المحاذاة وإصلاحها لإصلاح المسار الفاشل و مخزون المرسل لتعيين الملكية.
احتفظ بالنتيجة ضمن الأدلة
بالنسبة للرسالة أ، اكتب تمرير/عدم محاذاة SPF وتمرير/محاذاة DKIM كحقائق منفصلة. بالنسبة إلى B، لا تقم بتحويل تمريرتين أوليتين غير مرتبطتين إلى تمريرة DMARC . احتفظ بكل توقيع بشكل مستقل ولا تستنتج هوية SMTP من اسم العرض فقط. هذه الحالات والتوقيع المختصر هي أمثلة تعليمية وليست مادة توقيع صالحة أو تحقق منفذ.