تخصيص عندما نتحدث عن "مصادقة البريد الإلكتروني" ، فإننا نشير إلى تقنية توفر لمتلقي الرسالة مستوى معين من التأكد بأن الرسالة نشأت بالفعل من المصدر المزعوم للرسالة.
عندما نتحدث عن "مصادقة البريد الإلكتروني"، فإننا نشير إلى تقنية توفر للمستلم بعض المستوى من اليقين بأن الرسالة نشأت بالفعل من المصدر المزعوم للرسالة. الفكرة وراء هذه التقنيات هي تحقيق بعض الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد الاحتيالي والتزوير، البريد الذي قد يقوض ثقة المستلم في تلقي البريد الإلكتروني. ومع ذلك، فإن إرسال بريد إلكتروني مصادق عليه لا يؤكد أن البريد الإلكتروني جيد أو مرغوب فيه؛ إنه يعني فقط أن البريد الإلكتروني هو من تلك النوعية التي يمكن بناء سمعة موثوقة للحزب المُصادق عليه واستخدامها في قرارات قبول البريد الإلكتروني وتنسيبها.
هناك شكلان من المصادقة للبريد الإلكتروني يستخدمان اليوم:
إطار عمل سياسة المرسل (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; 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= في التوقيع.
السبب في أن هذه الأجزاء تهم الخادم المستقبِل هو أنها توفر المعلومات اللازمة لمساعدة المستقبِل على التحقق من صحة التوقيعات.
التحقق من صحة 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. نص وصفي "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
يستخدم المدقق هذا المفتاح (الأجزاء p=) لإنتاج مجموعته الخاصة من التجزئات للرسالة؛ إذا تتطابق تلك التجزئات، فهذا يعني أن الرسالة لم تتغير أثناء النقل، لذا يمكن للرسالة أن تساهم في، وربما تستفيد من، السمعة الموجودة للمرسل.
فشل التحقق واستكشاف الأخطاء وإصلاحها
ذكرت أعلاه أن حالات الفشل في DKIM قد تكون صعبة في التشخيص، وسأشرح لماذا هذا كذلك هنا.
بعض حالات الفشل في التحقق من صحة DKIM لها أسباب واضحة، مثل عدم توقيع الرسالة، أو عدم العثور على المفتاح العام لنطاق التوقيع في نظام أسماء النطاقات (DNS) أو عدم كونه صحيحًا نحويًا، أو ربما تم تغيير الرسالة بشكل واضح أثناء الانتقال. عندما تحدث مثل هذه الإخفاقات، يكون من السهل معرفة المشكلة والتوصية بحل. ومع ذلك، فإن الحالات الصعبة، وتلك التي تؤدي إلى تجربة دعم محبطة أكثر، هي الحالات التي تم توقيع الرسالة فيها، والمفتاح العام موجود في DNS، ولم يتم تغيير الرسالة بشكل واضح، لكن المصدق يبلغ عن فشل التوقيع في التحقق.
السبب الذي يجعل من الصعب تشخيص هذه الحالات هو أنه لا توجد وسيلة حقيقية لأي من الطرفين لإعادة إنتاج الظروف التي تم فيها توقيع الرسالة والتحقق منها. يحتوي العنوان الخاص بتوقيع DKIM في الرسالة على الهاشات التي أنشأها الموقع في وقت التوقيع، ولكن من المحتمل أن لا يكون لدى المصدق الوصول إلى البنية التحتية للموقع وبالتالي لا يمكنه محاولة إعادة إنتاج التوقيع تحت ظروف الموقع. وبالمثل، من المحتمل أن لا يكون لدى الموقع الوصول إلى البنية التحتية للمصدق وبالتالي لا يوجد لديه طريقة لمحاولة التحقق من الرسالة بالطريقة التي قام بها المصدق.
الإخفاقات مثل تلك التي أصفها هنا نادرة الحدوث، وعادة لا يكون لحالات الفشل في التحقق من صحة DKIM بمفردها تأثير على وضع التسليم. لقد كان من تجربتي أن مثل هذه الإخفاقات تتسبب في طلبات دعم أكثر من أي نوع آخر من مشكلات DKIM.
