تخصيص عندما نتحدث عن "مصادقة البريد الإلكتروني" ، فإننا نشير إلى تقنية توفر لمتلقي الرسالة مستوى معين من التأكد بأن الرسالة نشأت بالفعل من المصدر المزعوم للرسالة.
عندما نتحدث عن "مصادقة البريد الإلكتروني"، فإننا نشير إلى تقنية تمنح متلقي الرسالة بعض المستوى من اليقين بأن الرسالة بالفعل قد نشأت من المصدر المزعوم للرسالة. الفكرة وراء مثل هذه التقنيات هي تحقيق بعض مستوى الدفاع ضد البريد الإلكتروني الاحتيالي، مثل التصيد والاحتيال، وهو البريد الذي يمكن أن يضر بثقة المستلم في تلقي البريد الإلكتروني. ومع ذلك، فإن فعل إرسال رسائل بريد إلكتروني موثقة لا يؤكد أن البريد جيد أو مطلوب؛ يعني فقط أن البريد هو من نوع يُمكن فيه إنشاء سمعة للحزب الموثق بشكل موثوق واستخدامه في قرارات قبول البريد الإلكتروني وتحديد موقعه.
هناك نوعان من مصادقة البريد الإلكتروني المستخدمة اليوم:
إطار سياسة المرسل (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 مع توثيق الرسائل، تطبيق أساليب تحقق البريدي الشامل يضمن أنك ترسل إلى عناوين مشروعة يمكنها فعليًا استلام وتوثيق رسائلك. لقد كانت تجربتي أن مثل هذه الأخطاء تولد المزيد من طلبات الدعم أكثر من أي نوع آخر من قضايا DKIM.
