التحقق من صحة 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=.
يبحث عن المفتاح العام في:
يعيد توليد الترويسات وهاشات الجسم.
يقارنها بقيمتي bh= و b= في البريد الإلكتروني.
إذا تطابقت، تمر الرسالة بنجاح عبر DKIM.
ما الذي يسبب فشل بروتوكول DKIM؟
تم تعديل الرسالة أثناء النقل (حتى تغييرات المسافات البيضاء إذا كنت تستخدم التوحيد الدقيق)
مفتاح عام غير صحيح أو مفقود في DNS
أخطاء تنسيق DNS
إزالة أو تدوير المحدد بشكل غير صحيح
هويات غير متطابقة (i= يجب أن يكون نفس النطاق أو نطاقًا فرعيًا لـ d=)
لماذا يمكن أن يكون من الصعب تتبع فشل DKIM؟
نظرًا لأن الموقع والموثق يعملان في بيئات مختلفة تمامًا — لا يمكن لأي من الجانبين إعادة بناء شروط التجزئة أو حالة التوقيع الخاصة بالجانب الآخر.
هذا يجعل إخفاقات عدم تطابق التجزئة المبهمة أكثر إحباطًا للتشخيص.
هل يعني فشل DKIM أن البريد الإلكتروني سينتهي في البريد العشوائي؟
ليس بالضرورة.
DKIM هو مجرد إشارة واحدة. إذا كان لدى النطاق سمعة قوية ويمر بفحوصات أخرى (SPF، محاذاة DMARC، معدلات الشكاوى المنخفضة)، فإن إخفاقات DKIM المعزولة عادة لا تؤثر على وصول الرسائل إلى البريد الوارد بمفردها.
لماذا تستخدم DKIM على الإطلاق؟
يحمي سلامة الرسائل
يبني سمعة النطاق
يمكن من مواءمة DMARC
يساعد مزودي صناديق البريد على التمييز بين المرسلين الشرعيين والمحتالين
يعتبر DKIM ممارسة مثلى لجميع مرسلي البريد الإلكتروني الجادين.
عندما نتحدث عن "مصادقة البريد الإلكتروني"، فإننا نشير إلى تقنية تمنح متلقي الرسالة بعض المستوى من اليقين بأن الرسالة بالفعل قد نشأت من المصدر المزعوم للرسالة. الفكرة وراء مثل هذه التقنيات هي تحقيق بعض مستوى الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد والاحتيال، وهو البريد الذي يمكن أن يضر بثقة المستلم في تلقي البريد الإلكتروني. ومع ذلك، فإن فعل إرسال رسائل بريد إلكتروني موثقة لا يؤكد أن البريد جيد أو مطلوب؛ يعني فقط أن البريد هو من نوع يُمكن فيه إنشاء سمعة للحزب الموثق بشكل موثوق واستخدامه في قرارات قبول البريد الإلكتروني وتحديد موقعه.
هناك نوعان من مصادقة البريد الإلكتروني المستخدمة اليوم:
إطار سياسة المرسل (SPF)
البريد المستخدَم بالمفاتيح المجالية (DKIM)
في منشور اليوم، أنا أغطي ما هو DKIM وكيف يعمل.
نظرة عامة على DKIM
على عكس نظيره في المصادقة SPF، الذي يوفر طريقة للنطاق لتفويض مضيف لإرسال البريد نيابة عنه، DKIM يوفر وسيلة لكيان (نطاق، منظمة، شخص، إلخ) لتحمل مسؤولية رسالة، بشكل مستقل عن الكيان الذي أرسل الرسالة بالفعل. بينما في كثير من الحالات سيكون الكيان المسؤول والكيان المرسل متطابقين، أو على الأقل مرتبطين بشكل وثيق، مع DKIM لا يوجد شرط بأن يكون الأمر كذلك.
أهدافي لك في هذه المشاركة هي أن تتعلم وتفهم المفاهيم التالية حول DKIM:
DKIM هو مصادقة "معتمدة على المحتوى"، على عكس SPF "معتمدة على المسار".
يؤكد الكيان المسؤول على مسؤوليته عن طريق "توقيع" الرسالة بزوج من التجزئات التشفيرية التي يتم إدراجها في رأس الرسالة.
يتم التحقق من صحة DKIM بواسطة النطاق المستقبل الذي يحاول إنشاء نفس التجزئين.
لا يمكن إكمال التحقق من صحة DKIM في كثير من الحالات حتى يتم نقل الرسالة بالكامل من قبل الخادم المرسل.
يمكن أن تكون فشل التحقق من الصحة صعبة التشخيص.
المصادقة القائمة على "المحتوى"
التوقيع والتحقق من DKIM
المنظمات التي ترغب في توقيع البريد باستخدام DKIM ستبدأ أولاً بتوليد مفتاحين تشفيريين. يتم الاحتفاظ بأحد المفاتيح سريًا ومتاحًا للخادم المرسل لتوقيع البريد، والآخر يجب نشره في DNS لاستخدامه من قبل النطاقات المستقبلة في محاولات التحقق من صحة التوقيع. الطرق المستخدمة لتوليد هذه المفاتيح وتثبيتها تعتمد على النظام الأساسي وهي خارج نطاق هذا المنشور، على الرغم من أنني سأصف لاحقًا كيفية نشر مفتاح DKIM العام في DNS.
رأس توقيع DKIM
لبدء فهمنا لـ DKIM، دعونا نلقي نظرة أولًا على ترويسة DKIM-Signature:
ترويسة DKIM-Signature هي سلسلة من أزواج القيم والمفاتيح، بعضها ذو اهتمام للقارئ أكثر من الآخر، لكنني سأصف جميعها هنا.
أولًا، سننظر إلى تلك التي تهم القارئ بدرجة أقل:
v=1; – يحدد إصدار DKIM (1 هو القيمة الصالحة الوحيدة)
a=rsa-sha256; – الخوارزمية المستخدمة في إنشاء تجزئات التشفير
c=relaxed/relaxed; – هناك مجموعتان من القواعد المتعلقة بإزالة المسافات في الترويسات والجسم التي يمكن تطبيقها عند إنشاء التجزئات في توقيع DKIM؛ تسمى هذه القواعد “canonicalization rules” (ومن هنا جاء المفتاح c) وتكون مجموعات القواعد إما “relaxed” أو “strict”.
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= من التوقيع.
السبب في أن هذه الأجزاء تهم الخادم المستلم هو أنها توفر المعلومات اللازمة لمساعدة المستلم على التحقق من صحة التوقيعات.
التحقق من صحة 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، وقد يشبه ذلك شيئًا مثل:
يستخدم المدقق ذلك المفتاح (الأجزاء p=) لإنتاج مجموعته الخاصة من الهاشات للرسالة؛ إذا كانت تلك الهاشات تتطابق، فهذا يعني أن الرسالة لم تُعدل أثناء النقل، وبالتالي يمكن للرسالة أن تسهم في، وربما تستفيد من، أية سمعة وُضعت للمرسل للرسالة.
فشل التحقق واستكشاف الأخطاء وإصلاحها
ذكرت أعلاه أن فشل DKIM يمكن أن يكون من الصعب حله، وسأشرح هنا لماذا الأمر كذلك.
بعض حالات فشل تحقق DKIM لها أسباب واضحة، مثل عدم توقيع الرسالة، أو عدم العثور على المفتاح العام لنطاق التوقيع في DNS أو عدم كونه صحيحًا نحويًا، أو ربما تم تعديل الرسالة بشكل واضح أثناء النقل. عندما تحدث هذه الأنواع من الفشل، يكون من السهل معرفة المشكلة وتوصية بحل. أما الحالات الصعبة، والتي تؤدي إلى تجربة دعم محبطة، فهي الحالات التي تم فيها توقيع الرسالة، ويوجد المفتاح العام في DNS، ولم يتم تعديل الرسالة بشكل واضح، ولكن المصدق يبلغ أن التوقيع فشل في التحقق.
السبب في أن هذه الحالات صعبة الحل هو أنه لا يوجد طريقة حقيقية لأي من الطرفين لإعادة إنتاج الظروف التي تم فيها توقيع الرسالة والتحقق منها. تحتوي الرسالة في ترويسة توقيع-DKIM الخاص بها على الهاشات التي تم إنشاؤها من قبل الموقع وقت التوقيع، لكن المصدق على الأرجح لا يمكنه الوصول إلى بنية الموقع التحتية وبالتالي لا يمكنه محاولة إعادة إنتاج التوقيع في ظل ظروف الموقع. وبالمثل، على الأرجح أن الموقع لا يمكنه الوصول إلى بنية المصدق التحتية وبالتالي ليس لديه وسيلة لمحاولة التحقق من الرسالة بالطريقة التي فعلها المصدق.
الأخطاء التي أصفها هنا نادرة الحدوث، وفشل تحقق DKIM في حد ذاته عادةً لا يؤثر على وضعية التسليم. بينما يتعامل DKIM مع توثيق الرسائل، تطبيق أساليب تحقق البريدي الشامل يضمن أنك ترسل إلى عناوين مشروعة يمكنها فعليًا استلام وتوثيق رسائلك. لقد كانت تجربتي أن مثل هذه الأخطاء تولد المزيد من طلبات الدعم أكثر من أي نوع آخر من قضايا DKIM.
