التحقق من صحة DKIM: ممارسة مثلى لمصادقة البريد الإلكتروني
Bird
08/04/2017
البريد الإلكتروني
1 min read
النقاط الرئيسية
DKIM (DomainKeys Identified Mail) هو طريقة مصادقة بريد إلكتروني قائمة على المحتوى تتحقق مما إذا تم تغيير الرسالة بعد توقيعها.
على عكس SPF، الذي يتحقق من صحة المسار المرسل، يتحقق DKIM من محتوى الرسالة نفسه باستخدام التوقيعات التشفيرية.
يستخدم DKIM مفتاحين: مفتاح خاص لتوقيع الرسائل الصادرة ومفتاح عام منشور في DNS لتمكين المستلمين من التحقق من التوقيعات.
تتضمن توقيع DKIM تجزئات لكل من الرؤوس والجسم، ومحددات، وطوابع زمنية وحقول الهوية — جميعها يجب على المستلم اعادة انتاجها والتحقق منها.
يعتمد DKIM على استلام الرسالة بشكل كامل أولاً للتحقق منها، مما يعني أن الفشل يمكن أن يحدث في وقت متأخر من العملية.
في أحيان كثيرة، يكون من الصعب معالجة المشاكل المتعلقة بفشل عملية التحقق من DKIM لأن المرسلين والمستلمين لا يمكنهم انتاج بيئات التوقيع/التحقق الخاصة ببعضهم البعض.
حتى عندما يفشل DKIM، فإنه عادةً لا يسبب بشكل مباشر مشاكل في الوصول إلى البريد الوارد بمفرده إلا إذا تم دمجه مع إشارات سمعة سلبية أخرى.
أبرز الأسئلة والأجوبة
ما الذي يفعله DKIM بالفعل؟
يقوم DKIM بإرفاق توقيع تشفير للبريد الإلكتروني، مما يتيح للخادم المستلم التأكد مما إذا كان محتوى الرسالة قد تم تعديله بعد إرسالها.
كيف يختلف DKIM عن SPF؟
SPF يحقق من من يُسمح له بإرسال البريد لاسم النطاق (مبني على المسار).
DKIM يحقق مما إذا كان المحتوى سليماً (مبني على المحتوى).
كلاهما يخدم أغراضًا مختلفة ويكملان بعضهما البعض.
ما هو داخل رأس توقيع DKIM؟
الحقول الرئيسية تشمل:
v= النسخة
a= الخوارزمية
c= قواعد التصميم المعياري
d= النطاق الموقع
s= المحدد
h= الرؤوس المشمولة في التوقيع
bh= تجزئة الجسم
b= بيانات التوقيع الفعلية
تساهم كل جزء في كيفية التحقق من التوقيع.
كيف يقوم خادم الاستلام بالتحقق من صحة DKIM؟
يستخرج القيمتين d= و s=.
يبحث عن المفتاح العام في:
selector._domainkey.domain
يعيد توليد الترويسات وهاشات الجسم.
يقارنها بقيمتي bh= و b= في البريد الإلكتروني.
إذا تطابقت، تمر الرسالة بنجاح عبر DKIM.
ما الذي يسبب فشل بروتوكول DKIM؟
تم تعديل الرسالة أثناء النقل (حتى تغييرات المسافات البيضاء إذا كنت تستخدم التوحيد الدقيق)
مفتاح عام غير صحيح أو مفقود في DNS
أخطاء تنسيق DNS
إزالة أو تدوير المحدد بشكل غير صحيح
هويات غير متطابقة (i= يجب أن يكون نفس النطاق أو نطاقًا فرعيًا لـ d=)
لماذا يمكن أن يكون من الصعب تتبع فشل DKIM؟
نظرًا لأن الموقع والموثق يعملان في بيئات مختلفة تمامًا — لا يمكن لأي من الجانبين إعادة بناء شروط التجزئة أو حالة التوقيع الخاصة بالجانب الآخر.
هذا يجعل إخفاقات عدم تطابق التجزئة المبهمة أكثر إحباطًا للتشخيص.
هل يعني فشل DKIM أن البريد الإلكتروني سينتهي في البريد العشوائي؟
ليس بالضرورة.
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= | نطاق التوقيع | يستخدم لتحديد مفتاح DNS العام للموقع |
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= | نطاق التوقيع | يستخدم لتحديد مفتاح DNS العام للموقع |
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= | نطاق التوقيع | يستخدم لتحديد مفتاح DNS العام للموقع |
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 على التهشير الذي تم توليده من قبل الموقع في وقت التوقيع، لكن من المرجح أن المراقب ليس لديه إمكانية الوصول إلى بنية الموقع الأساسية وبالتالي لا يمكنه محاولة إعادة إنتاج التوقيع تحت ظروف الموقع. وبالمثل، من المرجح أن الموقع ليس لديه إمكانية الوصول إلى البنية الأساسية للمراقب وبالتالي ليس لديه طريقة لمحاولة التحقق من الرسالة بالطريقة التي قام بها المراقب.
الإخفاقات مثل التي أصفها هنا هي حالات نادرة، وفشل التحقق من DKIM بمفرده عادةً لا يؤثر على مكان تسليم الرسائل. بينما DKIM يتعامل مع مصادقة الرسائل، تطبيق تقنيات تحقق البريد الإلكتروني الشاملة يضمن أنك ترسل إلى عناوين شرعية يمكنها فعليًا تلقي ومصادقة رسائلك. كانت تجربتي أن مثل هذه الإخفاقات تؤدي إلى مزيد من تذاكر الدعم أكثر من أي نوع آخر من مشكلات DKIM.
ذكرت أعلاه أن فشل DKIM يمكن أن يكون من الصعب حله، وسأشرح هنا السبب في ذلك.
بعض إخفاقات التحقق من DKIM لها أسباب واضحة، مثل أن الرسالة لم يتم توقيعها، أو أن المفتاح العام للنطاق الذي قام بالتوقيع لم يتم العثور عليه في DNS أو لم يكن صحيحًا نحويًا، أو ربما تم تغيير الرسالة بشكل واضح أثناء الإرسال. عندما تحدث هذه الأنواع من الإخفاقات، يكون من السهل معرفة المشكلة وتقديم توصية للحل. لكن الحالات الصعبة، والتي تؤدي إلى أكثر حالات الدعم إحباطًا، هي الحالات التي تم فيها توقيع الرسالة، ووجود المفتاح العام في DNS، ولم يتم تعديل الرسالة بوضوح، لكن المراقب أبلغ أن التوقيع فشل في التحقق.
السبب في أن هذه الحالات صعبة في الحل هو أنه لا يوجد طريقة حقيقية لأي جانب لإعادة إنتاج الظروف التي تم فيها توقيع الرسالة والتحقق منها. تحتوي الرسالة في ترويسة توقيع DKIM على التهشير الذي تم توليده من قبل الموقع في وقت التوقيع، لكن من المرجح أن المراقب ليس لديه إمكانية الوصول إلى بنية الموقع الأساسية وبالتالي لا يمكنه محاولة إعادة إنتاج التوقيع تحت ظروف الموقع. وبالمثل، من المرجح أن الموقع ليس لديه إمكانية الوصول إلى البنية الأساسية للمراقب وبالتالي ليس لديه طريقة لمحاولة التحقق من الرسالة بالطريقة التي قام بها المراقب.
الإخفاقات مثل التي أصفها هنا هي حالات نادرة، وفشل التحقق من DKIM بمفرده عادةً لا يؤثر على مكان تسليم الرسائل. بينما DKIM يتعامل مع مصادقة الرسائل، تطبيق تقنيات تحقق البريد الإلكتروني الشاملة يضمن أنك ترسل إلى عناوين شرعية يمكنها فعليًا تلقي ومصادقة رسائلك. كانت تجربتي أن مثل هذه الإخفاقات تؤدي إلى مزيد من تذاكر الدعم أكثر من أي نوع آخر من مشكلات DKIM.
ذكرت أعلاه أن فشل DKIM يمكن أن يكون من الصعب حله، وسأشرح هنا السبب في ذلك.
بعض إخفاقات التحقق من DKIM لها أسباب واضحة، مثل أن الرسالة لم يتم توقيعها، أو أن المفتاح العام للنطاق الذي قام بالتوقيع لم يتم العثور عليه في DNS أو لم يكن صحيحًا نحويًا، أو ربما تم تغيير الرسالة بشكل واضح أثناء الإرسال. عندما تحدث هذه الأنواع من الإخفاقات، يكون من السهل معرفة المشكلة وتقديم توصية للحل. لكن الحالات الصعبة، والتي تؤدي إلى أكثر حالات الدعم إحباطًا، هي الحالات التي تم فيها توقيع الرسالة، ووجود المفتاح العام في DNS، ولم يتم تعديل الرسالة بوضوح، لكن المراقب أبلغ أن التوقيع فشل في التحقق.
السبب في أن هذه الحالات صعبة في الحل هو أنه لا يوجد طريقة حقيقية لأي جانب لإعادة إنتاج الظروف التي تم فيها توقيع الرسالة والتحقق منها. تحتوي الرسالة في ترويسة توقيع DKIM على التهشير الذي تم توليده من قبل الموقع في وقت التوقيع، لكن من المرجح أن المراقب ليس لديه إمكانية الوصول إلى بنية الموقع الأساسية وبالتالي لا يمكنه محاولة إعادة إنتاج التوقيع تحت ظروف الموقع. وبالمثل، من المرجح أن الموقع ليس لديه إمكانية الوصول إلى البنية الأساسية للمراقب وبالتالي ليس لديه طريقة لمحاولة التحقق من الرسالة بالطريقة التي قام بها المراقب.
الإخفاقات مثل التي أصفها هنا هي حالات نادرة، وفشل التحقق من DKIM بمفرده عادةً لا يؤثر على مكان تسليم الرسائل. بينما DKIM يتعامل مع مصادقة الرسائل، تطبيق تقنيات تحقق البريد الإلكتروني الشاملة يضمن أنك ترسل إلى عناوين شرعية يمكنها فعليًا تلقي ومصادقة رسائلك. كانت تجربتي أن مثل هذه الإخفاقات تؤدي إلى مزيد من تذاكر الدعم أكثر من أي نوع آخر من مشكلات DKIM.
