تحقق DKIM: أفضل ممارسة لمصادقة البريد الإلكتروني
طائر
08/04/2017
البريد الإلكتروني
1 min read
النقاط الرئيسية
DKIM (إثبات ملكية البريد الإلكتروني) هو أسلوب مصادقة البريد الإلكتروني معتمد على المحتوى يتحقق مما إذا كان قد تم تغيير الرسالة بعد توقيعها.
على عكس SPF، الذي يتحقق من مسار الإرسال، فإن DKIM يتحقق من محتوى الرسالة نفسه باستخدام التوقيعات التشفيرية.
تستخدم DKIM مفتاحين: مفتاح خاص لتوقيع الرسائل الصادرة ومفتاح عام منشور في DNS للمستلمين للتحقق من التوقيعات.
تتضمن توقيع DKIM تجزئات لكلا الرأس والجسم، والمحددات، والتوقيتات، وحقول الهوية - كل ما يجب أن يعيد إنتاجه والتحقق منه من قبل المستلم.
تعتمد مصادقة DKIM على استلام الرسالة كاملة أولاً، مما يعني أنه يمكن أن تحدث الإخفاقات في وقت متأخر من العملية.
غالبًا ما يكون استكشاف مشاكل مصادقة DKIM صعبًا لأن المرسلين والمستلمين لا يمكنهم إعادة إنتاج بيئات التوقيع/التحقق لبعضهم البعض.
حتى عندما تفشل DKIM، فإنها عادةً لا تسبب مباشرة مشاكل في وصول الرسائل بمفردها ما لم يتم دمجها مع إشارات سمعة سلبية أخرى.
أهم النقاط في الأسئلة والأجوبة
ماذا تفعل DKIM بالضبط؟
يضيف DKIM توقيعًا تشفيريًا إلى رسالة البريد الإلكتروني، مما يسمح للخادم المستقبل بتأكيد ما إذا كان قد تم تعديل محتوى الرسالة بعد إرسالها.
كيف يختلف DKIM عن SPF؟
SPF يتحقق من من يُسمح له بإرسال البريد لاسم النطاق (استنادًا إلى المسار).
DKIM يتحقق مما إذا كان المحتوى سليمًا (استنادًا إلى المحتوى).
كلاهما يخدم أغراضًا مختلفة ويكملان بعضهما البعض.
ما الذي يوجد داخل رأس DKIM-Signature؟
تشمل الحقول الرئيسية:
v= الإصدار
a= خوارزمية
c= قواعد التوحيد
d= مجال التوقيع
s= المحدد
h= الرؤوس المضمنة في التوقيع
bh= تجزئة الجسم
b= بيانات التوقيع الفعلية
يساهم كل جزء في كيفية التحقق من صحة التوقيع.
كيف يتحقق الخادم المستلم من DKIM؟
يستخرج قيم d= و s=.
يبحث عن المفتاح العام في:
selector._domainkey.domain
يعيد توليد تجزئات الرأس والجسم.
يقارنها بالقيم bh= و b= في البريد الإلكتروني.
إذا كانت متطابقة، فإن الرسالة تجتاز DKIM.
ما هي أسباب فشل DKIM؟
تم تعديل الرسالة أثناء النقل (حتى تغييرات المسافة البيضاء إذا كنت تستخدم التهيئة الصارمة)
مفتاح عام غير صحيح أو مفقود في نظام أسماء النطاقات
أخطاء في تنسيق نظام أسماء النطاقات
تمت إزالة المحدد أو تدويره بشكل غير صحيح
هويات غير متناسقة (i= يجب أن تكون نفس النطاق أو النطاق الفرعي لـ d=)
لماذا يمكن أن تكون مشاكل DKIM صعبة في التحليل؟
نظرًا لأن الموقّع والمحقق يعملان في بيئات مختلفة تمامًا - ولا يمكن لأي من الجانبين إعادة بناء شروط التجزئة أو حالة التوقيع للجانب الآخر.
هذا يجعل فشل "مطابقة التجزئة" الغامض هو الأكثر إحباطًا للتشخيص.
هل يعني فشل DKIM أن البريد الإلكتروني سيصل إلى صندوق spam؟
ليس بالضرورة.
تعتبر DKIM مجرد إشارة واحدة. إذا كان للنطاق سمعة قوية وجاوز اختبارات أخرى (محاذاة SPF و DMARC، وانخفاض معدلات الشكاوي)، فإن فشل DKIM المعزول عادةً لا يؤثر على وصول الرسائل إلى صندوق الوارد بمفرده.
لماذا نستخدم DKIM على الإطلاق؟
يحمي سلامة الرسالة
يبني سمعة المجال
يتيح محاذاة DMARC
يساعد مقدمي خدمات البريد الإلكتروني على تمييز المرسلين الشرعيين عن المحتالين
تُعتبر DKIM ممارسة جيدة لجميع مرسلي البريد الإلكتروني الجادين.
عندما نتحدث عن "مصادقة البريد الإلكتروني"، فإننا نشير إلى تقنية توفر للمستلم رسالة مستوى معين من اليقين بأن الرسالة جاءت بالفعل من المصدر المدعى للرسالة. الفكرة وراء هذه التقنيات هي تحقيق مستوى معين من الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد الاحتيالي والتزوير، البريد الذي قد يقوض ثقة المستلم في تلقي البريد الإلكتروني. ومع ذلك، فإن فعل إرسال بريد إلكتروني موثق لا يعني أن البريد جيد أو مرغوب فيه؛ بل يعني فقط أن البريد هو من نوع يمكن من خلاله تأسيس سمعة للجهة الموثقة يمكن الاعتماد عليها واستخدامها في قرارات قبول البريد الإلكتروني وتوزيعه.
هناك نوعان من مصادقة البريد الإلكتروني قيد الاستخدام اليوم:
إطار سياسة المرسل (SPF)
البريد المُعرّف بمفاتيح المجال (DKIM)
في منشور اليوم، سأغطي ما هو DKIM وكيف يعمل.
عندما نتحدث عن "مصادقة البريد الإلكتروني"، فإننا نشير إلى تقنية توفر للمستلم رسالة مستوى معين من اليقين بأن الرسالة جاءت بالفعل من المصدر المدعى للرسالة. الفكرة وراء هذه التقنيات هي تحقيق مستوى معين من الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد الاحتيالي والتزوير، البريد الذي قد يقوض ثقة المستلم في تلقي البريد الإلكتروني. ومع ذلك، فإن فعل إرسال بريد إلكتروني موثق لا يعني أن البريد جيد أو مرغوب فيه؛ بل يعني فقط أن البريد هو من نوع يمكن من خلاله تأسيس سمعة للجهة الموثقة يمكن الاعتماد عليها واستخدامها في قرارات قبول البريد الإلكتروني وتوزيعه.
هناك نوعان من مصادقة البريد الإلكتروني قيد الاستخدام اليوم:
إطار سياسة المرسل (SPF)
البريد المُعرّف بمفاتيح المجال (DKIM)
في منشور اليوم، سأغطي ما هو DKIM وكيف يعمل.
عندما نتحدث عن "مصادقة البريد الإلكتروني"، فإننا نشير إلى تقنية توفر للمستلم رسالة مستوى معين من اليقين بأن الرسالة جاءت بالفعل من المصدر المدعى للرسالة. الفكرة وراء هذه التقنيات هي تحقيق مستوى معين من الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد الاحتيالي والتزوير، البريد الذي قد يقوض ثقة المستلم في تلقي البريد الإلكتروني. ومع ذلك، فإن فعل إرسال بريد إلكتروني موثق لا يعني أن البريد جيد أو مرغوب فيه؛ بل يعني فقط أن البريد هو من نوع يمكن من خلاله تأسيس سمعة للجهة الموثقة يمكن الاعتماد عليها واستخدامها في قرارات قبول البريد الإلكتروني وتوزيعه.
هناك نوعان من مصادقة البريد الإلكتروني قيد الاستخدام اليوم:
إطار سياسة المرسل (SPF)
البريد المُعرّف بمفاتيح المجال (DKIM)
في منشور اليوم، سأغطي ما هو DKIM وكيف يعمل.
نظرة عامة على DKIM
على عكس نظيرتها في المصادقة SPF، التي توفر طريقة لنطاق ما لتفويض مضيف لإرسال البريد نيابةً عنه، فإن DKIM توفر وسيلة لكي تأخذ كيان (نطاق، منظمة، شخص، إلخ) المسؤولية عن رسالة، بغض النظر عن الكيان الذي أرسل الرسالة فعليًا. بينما في كثير من الحالات يكون الكيان المسؤول والكيان المرسل هو نفسه، أو على الأقل مرتبط بشكل وثيق، مع DKIM لا يوجد شرط بأن يكون الأمر كذلك.
أهدافي لك من خلال هذا المنشور هي أن تتعلم وتفهم المفاهيم التالية حول DKIM:
DKIM هو مصادقة "مبنية على المحتوى"، على عكس SPF "المبنية على المسار".
يؤكد الكيان المسؤول مسؤوليته من خلال "توقيع" الرسالة باستخدام زوج من الهاشات التشفيرية المدخلة في رأس الرسالة.
يتم التحقق من صحة DKIM بواسطة النطاق المستقبل الذي يحاول توليد نفس الهاشين.
لا يمكن إكمال التحقق من صحة DKIM في كثير من الحالات حتى يتم نقل الرسالة الكاملة من قبل خادم الإرسال.
يمكن أن تكون عيوب التحقق صعبة في التحري عنها.
على عكس نظيرتها في المصادقة SPF، التي توفر طريقة لنطاق ما لتفويض مضيف لإرسال البريد نيابةً عنه، فإن DKIM توفر وسيلة لكي تأخذ كيان (نطاق، منظمة، شخص، إلخ) المسؤولية عن رسالة، بغض النظر عن الكيان الذي أرسل الرسالة فعليًا. بينما في كثير من الحالات يكون الكيان المسؤول والكيان المرسل هو نفسه، أو على الأقل مرتبط بشكل وثيق، مع DKIM لا يوجد شرط بأن يكون الأمر كذلك.
أهدافي لك من خلال هذا المنشور هي أن تتعلم وتفهم المفاهيم التالية حول DKIM:
DKIM هو مصادقة "مبنية على المحتوى"، على عكس SPF "المبنية على المسار".
يؤكد الكيان المسؤول مسؤوليته من خلال "توقيع" الرسالة باستخدام زوج من الهاشات التشفيرية المدخلة في رأس الرسالة.
يتم التحقق من صحة DKIM بواسطة النطاق المستقبل الذي يحاول توليد نفس الهاشين.
لا يمكن إكمال التحقق من صحة DKIM في كثير من الحالات حتى يتم نقل الرسالة الكاملة من قبل خادم الإرسال.
يمكن أن تكون عيوب التحقق صعبة في التحري عنها.
على عكس نظيرتها في المصادقة SPF، التي توفر طريقة لنطاق ما لتفويض مضيف لإرسال البريد نيابةً عنه، فإن DKIM توفر وسيلة لكي تأخذ كيان (نطاق، منظمة، شخص، إلخ) المسؤولية عن رسالة، بغض النظر عن الكيان الذي أرسل الرسالة فعليًا. بينما في كثير من الحالات يكون الكيان المسؤول والكيان المرسل هو نفسه، أو على الأقل مرتبط بشكل وثيق، مع DKIM لا يوجد شرط بأن يكون الأمر كذلك.
أهدافي لك من خلال هذا المنشور هي أن تتعلم وتفهم المفاهيم التالية حول DKIM:
DKIM هو مصادقة "مبنية على المحتوى"، على عكس SPF "المبنية على المسار".
يؤكد الكيان المسؤول مسؤوليته من خلال "توقيع" الرسالة باستخدام زوج من الهاشات التشفيرية المدخلة في رأس الرسالة.
يتم التحقق من صحة DKIM بواسطة النطاق المستقبل الذي يحاول توليد نفس الهاشين.
لا يمكن إكمال التحقق من صحة DKIM في كثير من الحالات حتى يتم نقل الرسالة الكاملة من قبل خادم الإرسال.
يمكن أن تكون عيوب التحقق صعبة في التحري عنها.
المصادقة المعتمدة على المحتوى
يشار إلى DKIM بأنه مصادقة "مبنية على المحتوى"، بدلاً من "مبنية على المسار"، لأن ما إذا كانت الرسالة تمر بعملية التحقق من DKIM يعتمد فقط على ما إذا كان المحتوى قد تغير بين الوقت الذي تم فيه التوقيع والوقت الذي تم فيه محاولة التحقق.
يشار إلى DKIM بأنه مصادقة "مبنية على المحتوى"، بدلاً من "مبنية على المسار"، لأن ما إذا كانت الرسالة تمر بعملية التحقق من DKIM يعتمد فقط على ما إذا كان المحتوى قد تغير بين الوقت الذي تم فيه التوقيع والوقت الذي تم فيه محاولة التحقق.
يشار إلى DKIM بأنه مصادقة "مبنية على المحتوى"، بدلاً من "مبنية على المسار"، لأن ما إذا كانت الرسالة تمر بعملية التحقق من DKIM يعتمد فقط على ما إذا كان المحتوى قد تغير بين الوقت الذي تم فيه التوقيع والوقت الذي تم فيه محاولة التحقق.
توقيع DKIM والتحقق منه
تسعى المنظمات التي ترغب في توقيع البريد باستخدام DKIM أولاً إلى توليد مفتاحين تشفيريين. يتم الاحتفاظ بأحد المفاتيح بشكل خاص ومتاح للخادم المرسل من أجل توقيع البريد، بينما يجب جعل المفتاح الآخر عامًا في DNS لاستخدامه من قبل المجالات المستلمة في محاولاتها للتحقق من التوقيع. تعتبر الأساليب المستخدمة لتوليد هذه المفاتيح وتثبيتها معتمدة على المنصة وخارج نطاق هذه التدوينة، على الرغم من أنني سأصف لاحقًا نشر مفتاح DKIM العام في DNS.
تسعى المنظمات التي ترغب في توقيع البريد باستخدام DKIM أولاً إلى توليد مفتاحين تشفيريين. يتم الاحتفاظ بأحد المفاتيح بشكل خاص ومتاح للخادم المرسل من أجل توقيع البريد، بينما يجب جعل المفتاح الآخر عامًا في DNS لاستخدامه من قبل المجالات المستلمة في محاولاتها للتحقق من التوقيع. تعتبر الأساليب المستخدمة لتوليد هذه المفاتيح وتثبيتها معتمدة على المنصة وخارج نطاق هذه التدوينة، على الرغم من أنني سأصف لاحقًا نشر مفتاح DKIM العام في DNS.
تسعى المنظمات التي ترغب في توقيع البريد باستخدام DKIM أولاً إلى توليد مفتاحين تشفيريين. يتم الاحتفاظ بأحد المفاتيح بشكل خاص ومتاح للخادم المرسل من أجل توقيع البريد، بينما يجب جعل المفتاح الآخر عامًا في DNS لاستخدامه من قبل المجالات المستلمة في محاولاتها للتحقق من التوقيع. تعتبر الأساليب المستخدمة لتوليد هذه المفاتيح وتثبيتها معتمدة على المنصة وخارج نطاق هذه التدوينة، على الرغم من أنني سأصف لاحقًا نشر مفتاح DKIM العام في DNS.
رأس توقيع DKIM
لبدء فهمنا لـ DKIM، دعونا أولاً نلقي نظرة على رأس DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
رأس DKIM-Signature هو سلسلة من أزواج المفتاح والقيمة، بعضها أكثر اهتمامًا للقارئ من الآخرين، لكنني سأصفها جميعًا هنا.
أولاً، سننظر إلى العناصر التي تهم القارئ بشكل عام:
v=1; – يحدد إصدار DKIM (1 هو القيمة الصالحة الوحيدة)
a=rsa-sha256; – الخوارزمية المستخدمة لإنشاء التجزئات التشفيرية
c=relaxed/relaxed; – هناك مجموعتان من القواعد بشأن إزالة المسافات البيضاء في الرؤوس والجسم يمكن تطبيقها عند إنشاء التجزئات في توقيع DKIM؛ تُسمى هذه القواعد "قواعد التحويل القياسية" (لذا مفتاح c) ومجموعات القواعد إما "مرخّصة" أو "صارمة".
t=1454417737; – الطابع الزمني لوقت إنشاء التوقيع.
تحتوي هذه الأجزاء الثلاثة من الرأس على معلومات التوقيع الفعلية:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – هذه هي تجزئة جسم الرسالة.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – هذه قائمة بالرؤوس التي تم استخدامها لإنشاء بيانات التوقيع الموضحة أدناه.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – هذه هي بيانات توقيع DKIM الفعلية
تُعتبر هذه الأجزاء الثلاثة الأكثر أهمية للخادم المستلم الذي سيتحقق من التوقيع:
d=welcome.foo.com; – يحدد النطاق الذي قام بتوقيع الرسالة
s=notices; – المُحدد؛ يمكن أن تحتوي المجالات على تحديدات متعددة تستخدمها عند توقيع الرسائل.
i=@welcome.foo.com; – هذه هي الهوية التي تم التوقيع بها نيابةً عن الرسالة. يمكن أن يبدو هذا بصيغة عنوان بريد إلكتروني، وقد يكون واحدًا أيضًا؛ قد يكون الجزء المحلي من عنوان البريد الإلكتروني فارغًا، كما في هذا المثال، ويجب أن يكون الجزء الخاص بالنطاق هو نفسه، أو نطاق فرعي، من النطاق في جزء d= من التوقيع.
السبب في أن هذه الأجزاء تهم الخادم المستلم هو أنها توفر المعلومات اللازمة لمساعدة المستلم في التحقق من التوقيع.
الحقل | المعنى | كيف يستخدمه المستقبلون |
|---|---|---|
v= | إصدار DKIM (دائمًا 1) | يؤكد تنسيق التوقيع |
a= | خوارزمية التجزئة + التوقيع (مثل، rsa-sha256) | يضمن أن المُصَدِّق يعيد إنشاء التوقيع بشكل صحيح |
c= | قواعد التحويل القياسية (الرأس/الجسم) | تطبيع المسافات البيضاء قبل التجزئة |
t= | الطابع الزمني لإنشاء التوقيع | يستخدم لفحص الحداثة ومنع تكرار المحاولات |
bh= | تجزئة الجسم | يعيد المستلم إنشاء هذا لتأكيد سلامة جسم الرسالة |
h= | قائمة الحقول الرئاسية الموقعة | يضمن أن الرؤوس المستخدمة في التوقيع متاحة وغير مُعدلة |
b= | توقيع DKIM الفعلي | يتحقق المستلم من هذا التوقيع مقابل المفتاح العام |
d= | النطاق المُوقع | يستخدم لتحديد المفتاح العام الخاص بالموقع |
s= | المحدد | يتم دمجه مع النطاق لتشكيل: selector._domainkey.domain |
i= | الهوية الموقعة | يجب أن تكون هي نفسها أو نطاق فرعي من d=، تحدد الكيان الموقّع |
لبدء فهمنا لـ DKIM، دعونا أولاً نلقي نظرة على رأس DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
رأس DKIM-Signature هو سلسلة من أزواج المفتاح والقيمة، بعضها أكثر اهتمامًا للقارئ من الآخرين، لكنني سأصفها جميعًا هنا.
أولاً، سننظر إلى العناصر التي تهم القارئ بشكل عام:
v=1; – يحدد إصدار DKIM (1 هو القيمة الصالحة الوحيدة)
a=rsa-sha256; – الخوارزمية المستخدمة لإنشاء التجزئات التشفيرية
c=relaxed/relaxed; – هناك مجموعتان من القواعد بشأن إزالة المسافات البيضاء في الرؤوس والجسم يمكن تطبيقها عند إنشاء التجزئات في توقيع DKIM؛ تُسمى هذه القواعد "قواعد التحويل القياسية" (لذا مفتاح c) ومجموعات القواعد إما "مرخّصة" أو "صارمة".
t=1454417737; – الطابع الزمني لوقت إنشاء التوقيع.
تحتوي هذه الأجزاء الثلاثة من الرأس على معلومات التوقيع الفعلية:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – هذه هي تجزئة جسم الرسالة.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – هذه قائمة بالرؤوس التي تم استخدامها لإنشاء بيانات التوقيع الموضحة أدناه.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – هذه هي بيانات توقيع DKIM الفعلية
تُعتبر هذه الأجزاء الثلاثة الأكثر أهمية للخادم المستلم الذي سيتحقق من التوقيع:
d=welcome.foo.com; – يحدد النطاق الذي قام بتوقيع الرسالة
s=notices; – المُحدد؛ يمكن أن تحتوي المجالات على تحديدات متعددة تستخدمها عند توقيع الرسائل.
i=@welcome.foo.com; – هذه هي الهوية التي تم التوقيع بها نيابةً عن الرسالة. يمكن أن يبدو هذا بصيغة عنوان بريد إلكتروني، وقد يكون واحدًا أيضًا؛ قد يكون الجزء المحلي من عنوان البريد الإلكتروني فارغًا، كما في هذا المثال، ويجب أن يكون الجزء الخاص بالنطاق هو نفسه، أو نطاق فرعي، من النطاق في جزء d= من التوقيع.
السبب في أن هذه الأجزاء تهم الخادم المستلم هو أنها توفر المعلومات اللازمة لمساعدة المستلم في التحقق من التوقيع.
الحقل | المعنى | كيف يستخدمه المستقبلون |
|---|---|---|
v= | إصدار DKIM (دائمًا 1) | يؤكد تنسيق التوقيع |
a= | خوارزمية التجزئة + التوقيع (مثل، rsa-sha256) | يضمن أن المُصَدِّق يعيد إنشاء التوقيع بشكل صحيح |
c= | قواعد التحويل القياسية (الرأس/الجسم) | تطبيع المسافات البيضاء قبل التجزئة |
t= | الطابع الزمني لإنشاء التوقيع | يستخدم لفحص الحداثة ومنع تكرار المحاولات |
bh= | تجزئة الجسم | يعيد المستلم إنشاء هذا لتأكيد سلامة جسم الرسالة |
h= | قائمة الحقول الرئاسية الموقعة | يضمن أن الرؤوس المستخدمة في التوقيع متاحة وغير مُعدلة |
b= | توقيع DKIM الفعلي | يتحقق المستلم من هذا التوقيع مقابل المفتاح العام |
d= | النطاق المُوقع | يستخدم لتحديد المفتاح العام الخاص بالموقع |
s= | المحدد | يتم دمجه مع النطاق لتشكيل: selector._domainkey.domain |
i= | الهوية الموقعة | يجب أن تكون هي نفسها أو نطاق فرعي من d=، تحدد الكيان الموقّع |
لبدء فهمنا لـ DKIM، دعونا أولاً نلقي نظرة على رأس DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
رأس DKIM-Signature هو سلسلة من أزواج المفتاح والقيمة، بعضها أكثر اهتمامًا للقارئ من الآخرين، لكنني سأصفها جميعًا هنا.
أولاً، سننظر إلى العناصر التي تهم القارئ بشكل عام:
v=1; – يحدد إصدار DKIM (1 هو القيمة الصالحة الوحيدة)
a=rsa-sha256; – الخوارزمية المستخدمة لإنشاء التجزئات التشفيرية
c=relaxed/relaxed; – هناك مجموعتان من القواعد بشأن إزالة المسافات البيضاء في الرؤوس والجسم يمكن تطبيقها عند إنشاء التجزئات في توقيع DKIM؛ تُسمى هذه القواعد "قواعد التحويل القياسية" (لذا مفتاح c) ومجموعات القواعد إما "مرخّصة" أو "صارمة".
t=1454417737; – الطابع الزمني لوقت إنشاء التوقيع.
تحتوي هذه الأجزاء الثلاثة من الرأس على معلومات التوقيع الفعلية:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – هذه هي تجزئة جسم الرسالة.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – هذه قائمة بالرؤوس التي تم استخدامها لإنشاء بيانات التوقيع الموضحة أدناه.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – هذه هي بيانات توقيع DKIM الفعلية
تُعتبر هذه الأجزاء الثلاثة الأكثر أهمية للخادم المستلم الذي سيتحقق من التوقيع:
d=welcome.foo.com; – يحدد النطاق الذي قام بتوقيع الرسالة
s=notices; – المُحدد؛ يمكن أن تحتوي المجالات على تحديدات متعددة تستخدمها عند توقيع الرسائل.
i=@welcome.foo.com; – هذه هي الهوية التي تم التوقيع بها نيابةً عن الرسالة. يمكن أن يبدو هذا بصيغة عنوان بريد إلكتروني، وقد يكون واحدًا أيضًا؛ قد يكون الجزء المحلي من عنوان البريد الإلكتروني فارغًا، كما في هذا المثال، ويجب أن يكون الجزء الخاص بالنطاق هو نفسه، أو نطاق فرعي، من النطاق في جزء d= من التوقيع.
السبب في أن هذه الأجزاء تهم الخادم المستلم هو أنها توفر المعلومات اللازمة لمساعدة المستلم في التحقق من التوقيع.
الحقل | المعنى | كيف يستخدمه المستقبلون |
|---|---|---|
v= | إصدار DKIM (دائمًا 1) | يؤكد تنسيق التوقيع |
a= | خوارزمية التجزئة + التوقيع (مثل، rsa-sha256) | يضمن أن المُصَدِّق يعيد إنشاء التوقيع بشكل صحيح |
c= | قواعد التحويل القياسية (الرأس/الجسم) | تطبيع المسافات البيضاء قبل التجزئة |
t= | الطابع الزمني لإنشاء التوقيع | يستخدم لفحص الحداثة ومنع تكرار المحاولات |
bh= | تجزئة الجسم | يعيد المستلم إنشاء هذا لتأكيد سلامة جسم الرسالة |
h= | قائمة الحقول الرئاسية الموقعة | يضمن أن الرؤوس المستخدمة في التوقيع متاحة وغير مُعدلة |
b= | توقيع DKIM الفعلي | يتحقق المستلم من هذا التوقيع مقابل المفتاح العام |
d= | النطاق المُوقع | يستخدم لتحديد المفتاح العام الخاص بالموقع |
s= | المحدد | يتم دمجه مع النطاق لتشكيل: selector._domainkey.domain |
i= | الهوية الموقعة | يجب أن تكون هي نفسها أو نطاق فرعي من d=، تحدد الكيان الموقّع |
تحقق من DKIM
بالإضافة إلى المتطلبات المذكورة بأن نطاق i= يجب أن يكون مماثلاً للنطاق d= أو نطاق فرعي له، فإن قيمتي d= و s= تُستخدمان من قبل المدقق للبحث عن مفتاح DKIM العام للموثق في نظام اسم النطاق DNS. المفتاح هو سجل TXT في DNS، ويجد دائمًا في موقع selector._domainkey.domain. لذا، في مثالنا هنا، مع s=notices و d=welcome.foo.com، يمكن العثور على مفتاح DKIM العام في DNS في notices._domainkey.welcome.foo.com، وقد يبدو شيء من هذا القبيل:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
يستخدم المدقق هذا المفتاح (قيمة p=) لإنتاج مجموعة خاصة به من التجزئات للرسالة؛ إذا تطابقت تلك التجزئات، فهذا يعني أن الرسالة لم تتغير أثناء النقل، وبالتالي يمكن أن تساهم الرسالة، وربما تستفيد من، أي سمعة موجودة للموثق للرسالة.
بالإضافة إلى المتطلبات المذكورة بأن نطاق i= يجب أن يكون مماثلاً للنطاق d= أو نطاق فرعي له، فإن قيمتي d= و s= تُستخدمان من قبل المدقق للبحث عن مفتاح DKIM العام للموثق في نظام اسم النطاق DNS. المفتاح هو سجل TXT في DNS، ويجد دائمًا في موقع selector._domainkey.domain. لذا، في مثالنا هنا، مع s=notices و d=welcome.foo.com، يمكن العثور على مفتاح DKIM العام في DNS في notices._domainkey.welcome.foo.com، وقد يبدو شيء من هذا القبيل:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
يستخدم المدقق هذا المفتاح (قيمة p=) لإنتاج مجموعة خاصة به من التجزئات للرسالة؛ إذا تطابقت تلك التجزئات، فهذا يعني أن الرسالة لم تتغير أثناء النقل، وبالتالي يمكن أن تساهم الرسالة، وربما تستفيد من، أي سمعة موجودة للموثق للرسالة.
بالإضافة إلى المتطلبات المذكورة بأن نطاق i= يجب أن يكون مماثلاً للنطاق d= أو نطاق فرعي له، فإن قيمتي d= و s= تُستخدمان من قبل المدقق للبحث عن مفتاح DKIM العام للموثق في نظام اسم النطاق DNS. المفتاح هو سجل TXT في DNS، ويجد دائمًا في موقع selector._domainkey.domain. لذا، في مثالنا هنا، مع s=notices و d=welcome.foo.com، يمكن العثور على مفتاح DKIM العام في DNS في notices._domainkey.welcome.foo.com، وقد يبدو شيء من هذا القبيل:
notices._domainkey.welcome.foo.com. descriptive text "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
يستخدم المدقق هذا المفتاح (قيمة p=) لإنتاج مجموعة خاصة به من التجزئات للرسالة؛ إذا تطابقت تلك التجزئات، فهذا يعني أن الرسالة لم تتغير أثناء النقل، وبالتالي يمكن أن تساهم الرسالة، وربما تستفيد من، أي سمعة موجودة للموثق للرسالة.
فشل التحقق واستكشاف الأخطاء وإصلاحها
ذكرت أعلاه أن فشل DKIM يمكن أن يكون من الصعب استكشافه، وسأشرح لماذا يكون الأمر كذلك هنا.
بعض حالات فشل التحقق من DKIM لها أسباب واضحة، مثل عدم توقيع الرسالة، أو عدم العثور على المفتاح العام لمجال التوقيع في DNS أو عدم كونه صحيحًا نحويًا، أو ربما تم تعديل الرسالة بوضوح أثناء النقل. عندما تحدث حالات الفشل من هذا النوع، يكون من السهل معرفة المشكلة وتوصية بحل. ومع ذلك، فإن الحالات الصعبة، والتي تؤدي إلى تجربة دعم أكثر إحباطًا، هي الحالات التي تم فيها توقيع الرسالة، والمفتاح العام موجود في DNS، ولم يتم تعديل الرسالة بوضوح، لكن المدقق يبلغ أن التوقيع فشل في التحقق.
السبب في أن هذه الأمور صعبة الاستكشاف هو أنه لا يوجد طريقة حقيقية لأي من الجانبين لإعادة إنتاج الظروف التي تم فيها توقيع الرسالة والتحقق منها. تحتوي الرسالة في رأس DKIM-Signature الخاص بها على التجزئات التي تم إنشاؤها بواسطة الموقّع في وقت التوقيع، ولكن المدقق على الأرجح ليس لديه وصول إلى بنية الموقّع التحتية لذا لا يمكنه محاولة إعادة إنتاج التوقيع تحت ظروف الموقّع. وبالمثل، من المحتمل أن الموقّع ليس لديه وصول إلى بنية المدقق التحتية لذا ليس لديه وسيلة لمحاولة التحقق من الرسالة بالطريقة التي فعلها المدقق.
تعد حالات الفشل مثل التي أصفها هنا نادرة الحدوث، وعادة ما لا تؤثر حالات فشل التحقق من DKIM بمفردها على مكانة التسليم. بينما يتعامل DKIM مع مصادقة الرسائل، تضمن تنفيذ تقنيات التحقق من البريد الإلكتروني الشاملة أنك ترسل إلى عناوين شرعية يمكنها فعلاً تلقي رسائلك ومصادقتها. لقد كانت تجربتي أن مثل هذه الحالات من الفشل تؤدي إلى المزيد من تذاكر الدعم أكثر من أي نوع آخر من مشاكل DKIM.
ذكرت أعلاه أن فشل DKIM يمكن أن يكون من الصعب استكشافه، وسأشرح لماذا يكون الأمر كذلك هنا.
بعض حالات فشل التحقق من DKIM لها أسباب واضحة، مثل عدم توقيع الرسالة، أو عدم العثور على المفتاح العام لمجال التوقيع في DNS أو عدم كونه صحيحًا نحويًا، أو ربما تم تعديل الرسالة بوضوح أثناء النقل. عندما تحدث حالات الفشل من هذا النوع، يكون من السهل معرفة المشكلة وتوصية بحل. ومع ذلك، فإن الحالات الصعبة، والتي تؤدي إلى تجربة دعم أكثر إحباطًا، هي الحالات التي تم فيها توقيع الرسالة، والمفتاح العام موجود في DNS، ولم يتم تعديل الرسالة بوضوح، لكن المدقق يبلغ أن التوقيع فشل في التحقق.
السبب في أن هذه الأمور صعبة الاستكشاف هو أنه لا يوجد طريقة حقيقية لأي من الجانبين لإعادة إنتاج الظروف التي تم فيها توقيع الرسالة والتحقق منها. تحتوي الرسالة في رأس DKIM-Signature الخاص بها على التجزئات التي تم إنشاؤها بواسطة الموقّع في وقت التوقيع، ولكن المدقق على الأرجح ليس لديه وصول إلى بنية الموقّع التحتية لذا لا يمكنه محاولة إعادة إنتاج التوقيع تحت ظروف الموقّع. وبالمثل، من المحتمل أن الموقّع ليس لديه وصول إلى بنية المدقق التحتية لذا ليس لديه وسيلة لمحاولة التحقق من الرسالة بالطريقة التي فعلها المدقق.
تعد حالات الفشل مثل التي أصفها هنا نادرة الحدوث، وعادة ما لا تؤثر حالات فشل التحقق من DKIM بمفردها على مكانة التسليم. بينما يتعامل DKIM مع مصادقة الرسائل، تضمن تنفيذ تقنيات التحقق من البريد الإلكتروني الشاملة أنك ترسل إلى عناوين شرعية يمكنها فعلاً تلقي رسائلك ومصادقتها. لقد كانت تجربتي أن مثل هذه الحالات من الفشل تؤدي إلى المزيد من تذاكر الدعم أكثر من أي نوع آخر من مشاكل DKIM.
ذكرت أعلاه أن فشل DKIM يمكن أن يكون من الصعب استكشافه، وسأشرح لماذا يكون الأمر كذلك هنا.
بعض حالات فشل التحقق من DKIM لها أسباب واضحة، مثل عدم توقيع الرسالة، أو عدم العثور على المفتاح العام لمجال التوقيع في DNS أو عدم كونه صحيحًا نحويًا، أو ربما تم تعديل الرسالة بوضوح أثناء النقل. عندما تحدث حالات الفشل من هذا النوع، يكون من السهل معرفة المشكلة وتوصية بحل. ومع ذلك، فإن الحالات الصعبة، والتي تؤدي إلى تجربة دعم أكثر إحباطًا، هي الحالات التي تم فيها توقيع الرسالة، والمفتاح العام موجود في DNS، ولم يتم تعديل الرسالة بوضوح، لكن المدقق يبلغ أن التوقيع فشل في التحقق.
السبب في أن هذه الأمور صعبة الاستكشاف هو أنه لا يوجد طريقة حقيقية لأي من الجانبين لإعادة إنتاج الظروف التي تم فيها توقيع الرسالة والتحقق منها. تحتوي الرسالة في رأس DKIM-Signature الخاص بها على التجزئات التي تم إنشاؤها بواسطة الموقّع في وقت التوقيع، ولكن المدقق على الأرجح ليس لديه وصول إلى بنية الموقّع التحتية لذا لا يمكنه محاولة إعادة إنتاج التوقيع تحت ظروف الموقّع. وبالمثل، من المحتمل أن الموقّع ليس لديه وصول إلى بنية المدقق التحتية لذا ليس لديه وسيلة لمحاولة التحقق من الرسالة بالطريقة التي فعلها المدقق.
تعد حالات الفشل مثل التي أصفها هنا نادرة الحدوث، وعادة ما لا تؤثر حالات فشل التحقق من DKIM بمفردها على مكانة التسليم. بينما يتعامل DKIM مع مصادقة الرسائل، تضمن تنفيذ تقنيات التحقق من البريد الإلكتروني الشاملة أنك ترسل إلى عناوين شرعية يمكنها فعلاً تلقي رسائلك ومصادقتها. لقد كانت تجربتي أن مثل هذه الحالات من الفشل تؤدي إلى المزيد من تذاكر الدعم أكثر من أي نوع آخر من مشاكل DKIM.
