[ DKIM ]

شرح الخلافات بين محلل الرأس والمتلقي

قارن بين وحدات بايت الرسالة والتوقيت و DNS وحدود الثقة قبل التعامل مع فحص DKIM اللاحق كتصحيح.

بواسطة فريق البحث EmailAuth · 3 دقائق قراءة

[النقاط الرئيسية]

  • افصل تقرير المتلقي المخزن عن التحقق الجديد.
  • قم بتسجيل العينة والحالة الرئيسية والوقت والتوقيع المحدد.
  • احتفظ بالملاحظات وقم بتسمية المدخلات التاريخية المفقودة.
في هذه الصفحة

يمكن لمحلل الرأس أن يختلف مع جهاز الاستقبال الأصلي دون أن يتم اختلاق أي من الملاحظتين. ربما قاموا بتقييم وحدات بايت مختلفة للرسائل أو حالة مفتاح DNS مختلفة أو سياسات تحقق مختلفة في أوقات مختلفة. الحفاظ على الأدلة الأصلية ومقارنة الشروط قبل تحديد معنى الخلاف.

إن النتيجة التاريخية المعروضة والتحقق المشفر الجديد هما عمليتان مختلفتان. تلخيص بعض الأدوات Authentication-Results موجودة بالفعل في العينة. يقوم آخرون باسترداد المفاتيح والتحقق من العينة الحالية. حدد العملية التي يقوم بها المحلل قبل مقارنة مخرجاته بنتيجة نظام الاستقبال.

الحفاظ على الأصل وتحديد الحدود

قم بتصدير الرسالة الأولية باستخدام أسلوب يحافظ على تمثيل الرسالة. احتفظ بنسخة أصلية غير محررة واحسب تجزئة الملف لمقارنتها لاحقًا. قم بتسجيل طريقة التجميع ووقت التسليم وصندوق البريد المصدر. يمكن أن توضح تجزئة الملف أن هناك ملفين تم تصديرهما مختلفان؛ فهو لا يفسر في حد ذاته أي اختلاف يهم DKIM.

حدد Authentication-Results التي أنشأها المتلقي ومعرف المصادقة الموثوق به. الرؤوس التي يقدمها مرسل غير موثوق به ليست دليلاً موثوقًا للمستقبل. RFC 8601 §7.1 يصف حدود الثقة هذه. حدد أيضًا ما إذا كان المستلم قد قام بتقييم الرسالة قبل أن تقوم بوابة لاحقة أو عملية تصدير بتغييرها.

قارن المدخلات الفعلية للمحلل

بالنسبة للتوقيع العادي لكامل الجسم، تحذف كتلة الرأس المنسوخة النص اللازم لإعادة حساب DKIM الخاص بها تجزئة الجسم. الحالة الخاصة l=0 تجزئة صفر ثمانيات ولا توفر أي حماية لسلامة الجسم؛ ولا يتنازل عن عمليات التحقق من الرأس أو المفتاح أو غيرها. يرى RFC 6376 §3.5, §3.7 و §5.4.1. يمكن أن يؤدي لصق النص أيضًا إلى تغيير نهايات الأسطر أو الطي. إذا كان المحلل يفتقر إلى الرسالة الكاملة، فقد يفسر النتائج المبلغ عنها بدلاً من التحقق بشكل مستقل من التوقيع بأكمله. تسمية الواجهة الخاصة بها وحدها لا تحل هذا السؤال.

قارن العينات الكاملة عندما تكون متاحة. DKIM تحديد العنوان القانوني في RFC 6376 §3.4 يتسامح مع تحويلات محددة، وليس التكافؤ التعسفي للمحتوى المقدم. لا تعني تجزئة الملف المختلفة تلقائيًا فشل DKIM ، نظرًا لأن بعض تغييرات البايت قد تتم تطبيعها؛ تقوم تجزئة الملف المتطابقة بإنشاء وحدات بايت متطابقة فقط، وليس DNS متطابقًا أو سياق السياسة.

تحقق مما تغير في DNS والوقت

اقرأ d وs لكل توقيع وسجل الإجابات الرئيسية التي تمت ملاحظتها أثناء الفحص اللاحق. ربما تم سحب المفتاح الأصلي أو إبطاله أو استبداله منذ التسليم. RFC 6376 §6.1.2 يعتمد التحقق على استرداد مواد التحقق المناسبة، بحيث يمكن أن يتواجد المرور التاريخي مع نتيجة لاحقة بدون مفتاح.

قم أيضًا بفحص أي قيمة x لانتهاء صلاحية التوقيع ومعالجة وقت المدقق. قد يتم تقييم أداة لاحقة بعد انتهاء صلاحية التوقيع. RFC 6376 §6.1.1 يسمح للمدققين بتجاهل التوقيعات منتهية الصلاحية؛ يجب التحقق من سلوك أداة معينة بدلاً من افتراضه. لا تصنف هذه النتيجة كدليل على انتهاء صلاحية التوقيع عندما قام المستلم بمعالجته في الأصل. عندما لا تتوفر إجابة DNS القديمة، اذكر أنه لا يمكن إعادة إنتاج حساب التشفير التاريخي بالكامل من الأدلة الحالية.

العمل من خلال مثالين متناقضين

المثال التوضيحي الأول: تمرير تقارير المتلقي محدد old1 يوم الاثنين، ويتقاعد المرسل old1 يوم الجمعة. تشير إعادة الفحص يوم السبت إلى عدم وجود مفتاح. ولا تمحو هذه النتيجة اللاحقة الملاحظة الموثوقة التي تمت يوم الاثنين، على الرغم من أن إعادة إنتاج التحقق الذي تم يوم الاثنين بشكل مستقل يتطلب المدخلات التاريخية ذات الصلة.

المثال التوضيحي الثاني: يتم التحقق من الملف الأصلي المستلم، بينما تفشل النسخة الملصقة بعد تغيير التذييل أو تسلسل MIME . قارن التمثيل المغطى والنقطة التي حدث فيها التغيير. قد تكمن المشكلة في معالجة العينة بدلاً من التوقيع الأصلي للمرسل. هذه مجرد تركيبات مقارنة، وليست ادعاءات حول محلل أو مستأجر حقيقي.

الإبلاغ عن الخلاف بدقة

قم بإنشاء سجل مقارنة يحتوي على نماذج التجزئات، وطرق التجميع، وأوقات المراقبة، وd وs، والإجابات الرئيسية، وإصدارات التحقق، والنتائج المُبلغ عنها، والاختلافات المعروفة في السياسة. افحص التوقيعات المتعددة بشكل منفصل، حيث أن الأدوات قد تسلط الضوء على توقيعات مختلفة. حافظ على صلاحية DKIM مختلفة عن DMARC تنسيق والتسليم النهائي .

استنتج فقط ما تدعمه الأدلة: وحدات البايت المختلفة، أو DNS المتغير، أو الصلاحية المنقضية، أو التوقيع المحدد المختلف، أو السياق الذي لم يتم حله. الحفاظ على عدم اليقين عندما تكون المدخلات الأصلية مفقودة. يعد المحلل اللاحق بمثابة دليل تشخيصي مفيد، ولكنه ليس آلة زمنية ولا ينبغي أن يحل محل نتيجة جهاز الاستقبال الأصلي الموثوق به بصمت.

الأدلة اللازمة لاتخاذ القرار المقبل

استخدم صف مقارنة لكل توقيع: تجزئة العينة الأصلية/الوقت، عينة التجزئة/الوقت اللاحقة، d/s، المفتاح الملحوظ، x إذا كان موجودًا، الأداة/الإصدار، العملية (تحليل التقرير أو التحقق منه)، النتيجة والفجوة المتبقية. تترك وحدات البايت النموذجية المتطابقة مع DNS التاريخي غير المتاح فجوة في الحالة الرئيسية، وليست دليلاً على خطأ أي من الأداتين. إذا اختلفت العينات، قارن التمثيل القانوني المغطى قبل تحديد السببية.

[ الوجبات الجاهزة ]

افصل تقرير المتلقي المخزن عن التحقق الجديد. قم بتسجيل العينة والحالة الرئيسية والوقت والتوقيع المحدد. احتفظ بالملاحظات وقم بتسمية المدخلات التاريخية المفقودة.

[ حسب الدور ]

ماذا يعني هذا بالنسبة لك

اختر دورك للخطوات العملية التالية.

تكنولوجيا المعلومات / مدير البريد

بناء مقارنة قابلة للتكرار

تنتمي وحدات البايت والحالة الرئيسية وافتراضات التحقق إلى سجل الأدلة.

الخطوات التالية

  1. التجزئة والحفاظ على كل عينة الخام.
  2. سجل إجابات d وs و DNS .
  3. تحديد التوقيع الذي تم تقييمه لكل أداة.

كبير مسؤولي أمن المعلومات / SecOps

الحفاظ على الأدلة التاريخية سليمة

يمكن للترويسات غير الموثوق بها والفحوصات بأثر رجعي أن تشوه سرد الحادث.

الخطوات التالية

  1. التحقق من مصدر النتيجة.
  2. ملاحظة تاريخية منفصلة عن إعادة الفحص.
  3. توثيق المدخلات المفقودة وعدم اليقين المتبقي.

المؤسس / غير التقنية

اسأل ما الذي فحصته الأداة بالفعل

قد تصف النتيجة الحمراء عينة تم تغييرها أو بحثًا لاحقًا بدلاً من التسليم الأصلي الفاشل.

الخطوات التالية

  1. الحفاظ على الرسالة الأصلية.
  2. قارن أوقات المراقبة.
  3. تجنب استخلاص استنتاجات العمل من تسمية ملخصة.

[ الأسئلة الشائعة ]

الأسئلة المتداولة

هل يمكن للمحلل التحقق من DKIM من الرؤوس وحدها؟

بالنسبة للتوقيعات العادية لكامل الجسم، لا: التحقق من تجزئة الجسم يحتاج إلى النص. مع l=0, يتم تجزئة الثمانيات الصفرية، بحيث لا يوفر التوقيع أي حماية لسلامة الجسم؛ لا تزال عمليات التحقق من الرأس والمفتاح وغيرها سارية. قد يقوم محلل الرؤوس فقط بتلخيص النتائج المبلغ عنها بدلاً من ذلك.

RFC 6376 §3.5 RFC 6376 §3.7 RFC 6376 §5.4.1 RFC 6376 §6.1.3

هل تثبت تجزئة الملف المختلفة DKIM يجب أن يفشل؟

لا. قد تتم تسوية بعض اختلافات البايت عن طريق تحديد DKIM ؛ فحص التمثيل المغطى الفعلي.

RFC 6376 §3.4

هل العينة المتطابقة تضمن نفس النتيجة؟

لا. يمكن أن يختلف DNS ووقت التقييم والتوقيع المحدد والسياسة.

RFC 6376 §6.1 RFC 6376 §6.1.2

هل يمكن أن يؤدي سحب المفتاح إلى تفسير فشل لاحق؟

نعم. قد لا يتمكن المدقق اللاحق من استرداد المفتاح المستخدم عند التسليم.

RFC 6376 §6.1.2

هل كل حقل Authentication-Results جدير بالثقة؟

لا، قم بإنشاء الحدود الموثوقة للمستلم ومعرف المصادقة.

RFC 8601 §7.1

هل يمكن أن يؤثر انتهاء الصلاحية على إعادة الفحص لاحقًا؟

نعم. قد يحدث التحقق لاحقًا بعد x حتى في حالة إجراء التقييم الأصلي مسبقًا.

RFC 6376 §3.5 RFC 6376 §6.1.1

ما هي النتيجة التي يجب الحفاظ عليها؟

الحفاظ على كل منهما مع أوقاتهم وسياقهم. لا تحل محل ملاحظة المتلقي التاريخي بصمت.

ماذا لو كان DNS التاريخي غير متوفر؟

اذكر هذا القيد. لا يمكن DNS الحالي وحده إعادة إنتاج شروط التحقق الأصلية بشكل كامل.

[ مصادر ]

مصادر

  1. RFC 6376

    الأقسام §1 · §3.1 · §3.4 · §3.5 · §3.7 · §6.1 · §6.1.1 · §6.1.2 · §6.1.3 · §5.4.1

  2. RFC 8601

    الأقسام §1.2 · §2.5 · §7.1

  3. RFC 9989

    الأقسام §4.4

[ مسرد ]

مسرد

DKIM
توقيع مرتبط بالمجال على محتوى الرسالة المحدد، ويتم التحقق منه باستخدام بيانات المفتاح العام.

RFC 6376 §1

محدد
القيمة s المستخدمة مع مجال التوقيع d للعثور على بيانات التحقق.

RFC 6376 §3.1 RFC 6376 §3.5

محاذاة DMARC
العلاقة المطلوبة بين المعرف المعتمد ومجال المؤلف.

RFC 9989 §4.4

تحديد العنوان القانوني
الإعداد المحدد للرؤوس أو النص قبل تجزئة DKIM والتحقق منها.

RFC 6376 §3.4

معرف خدمة المصادقة
معرف خدمة المصادقة التي تبلغ عن النتيجة؛ تعتمد الثقة أيضًا على حدود الاستقبال.

RFC 8601 §2.5 RFC 8601 §7.1

مصدر المؤسسة

لماذا كبار المؤسسات المالية والحكومات تقاعدوا من لوحات معلومات أمان البريد الإلكتروني الخاصة بهم.

تبيع لك منصات مصادقة البريد الإلكتروني التقليدية لوحة تحكم وتطلب من مهندسيك القيام بهذا العمل. في البيئات عالية المخاطر، تعني المراقبة اليدوية تأخير التنفيذ، والانحراف في التكوين، ونطاقات الظل غير الخاضعة للمراقبة.

EmailAuth هي منصة مصدر البريد الإلكتروني الوكيل. وكلاؤنا ينفذون p=reject، حافظ على محاذاة المرسلين الخارجيين وانقل نطاقاتك إلى كاملها RFC 9989 الامتثال، وهو معيار DMARC الجديد، مع إمكانية التدقيق البشري في الحلقة.

الحكومات المؤسسات الكبيرة المؤسسات المالية من المستوى الأول

SaaS · إيجار مخصص · Air-gapped محليًا · تشفير BYOK

قاعدة المعرفة