مفاتيح المجال التي تم تحديد البريد الإلكتروني بها

📅 آخر تحديث: ٤ أغسطس ٢٠٢٦
✍️ نُشر في: ٤ أغسطس ٢٠٢٦
📷 يحتوي على 1 صور
الموسوعة الحرة

مجموعة بروتوكولات الإنترنت
طبقة التطبيق
طبقة النقل
طبقة الانترنت
طبقة الارتباط
  • ف
  • ت
  • هـ

يعد DomainKeys Identified Mail ( DKIM ) طريقة مصادقة بريد إلكتروني مصممة للكشف عن عناوين المرسل المزورة في البريد الإلكتروني ( انتحال البريد الإلكتروني )، وهي تقنية تستخدم غالبًا في التصيد الاحتيالي والبريد الإلكتروني العشوائي .

يسمح DKIM للمستقبل بالتحقق من أن البريد الإلكتروني الذي ادعى أنه جاء من نطاق معين قد تم تفويضه بالفعل من قبل مالك هذا النطاق. [1] ويحقق ذلك من خلال إرفاق توقيع رقمي مرتبط باسم نطاق بكل رسالة بريد إلكتروني صادرة. يمكن لنظام المستلم التحقق من ذلك من خلال البحث عن المفتاح العام للمرسل المنشور في DNS . يضمن التوقيع الصحيح أيضًا عدم تعديل بعض أجزاء البريد الإلكتروني (ربما بما في ذلك المرفقات ) منذ إرفاق التوقيع. [2] عادةً، لا تكون توقيعات DKIM مرئية للمستخدمين النهائيين، ويتم إرفاقها أو التحقق منها بواسطة البنية التحتية بدلاً من مؤلفي الرسالة والمستلمين.

DKIM هو معيار إنترنت . [3] تم تعريفه في RFC 6376، المؤرخ سبتمبر 2011، مع التحديثات في RFC 8301 وRFC 8463.

ملخص

تنشأ الحاجة إلى التحقق من صحة البريد الإلكتروني لأن العناوين والمحتوى المزيفين يتم إنشاؤهما بسهولة بخلاف ذلك - ويستخدمان على نطاق واسع في البريد العشوائي والتصيد الاحتيالي وغير ذلك من عمليات الاحتيال القائمة على البريد الإلكتروني. [4] على سبيل المثال، قد يرسل المحتال رسالة يدعي أنها من sender@example.com ، بهدف إقناع المستلم بقبول البريد الإلكتروني وقراءته - ومن الصعب على المستلمين تحديد ما إذا كانوا يثقون في هذه الرسالة أم لا. يتعين على مسؤولي النظام أيضًا التعامل مع الشكاوى المتعلقة بالبريد الإلكتروني الضار الذي يبدو أنه نشأ من أنظمتهم، لكنه لم يكن كذلك. [5]

يوفر DKIM القدرة على توقيع رسالة، ويسمح للموقّع ( المؤسسة المؤلفة ) بالتواصل بشأن البريد الإلكتروني الذي يعتبره شرعيًا. ولا يمنع أو يكشف بشكل مباشر عن السلوك المسيء.

يوفر DKIM أيضًا عملية للتحقق من صحة الرسالة الموقعة. تعمل وحدات التحقق عادةً نيابةً عن مؤسسة المستقبل ، ربما في كل قفزة .

كل هذا مستقل عن جوانب توجيه بروتوكول نقل البريد البسيط (SMTP)، حيث يعمل على رسالة RFC 5322 - رأس وجسم البريد المنقول - وليس "مغلف" SMTP المحدد في RFC 5321. وبالتالي، تنجو توقيعات DKIM من النقل الأساسي عبر وكلاء نقل الرسائل المتعددين .

التفاصيل الفنية

التوقيع

يمكن أن تكون منظمة التوقيع معالجًا مباشرًا للرسالة، مثل المؤلف أو وكيل إرسال البريد أو الموقع أو وسيطًا آخر على طول مسار النقل، أو معالجًا غير مباشر مثل خدمة مستقلة تقدم المساعدة إلى معالج مباشر.

تقوم وحدات التوقيع بإدراج DKIM-Signature:حقل رأس واحد أو أكثر، ربما نيابة عن منظمة المؤلف أو مزود الخدمة الأصلي. تسمح المواصفات للموقعين باختيار حقول الرأس التي يوقعون عليها، ولكن From:يجب توقيع الحقل دائمًا. [6] [7] يتكون حقل الرأس الناتج من قائمة من tag=valueالأجزاء كما في المثال أدناه: 

توقيع DKIM:  v=1؛  a=rsa-sha256؛  d= example.net ؛  s=brisbane؛
      c=relaxed/simple؛  q=dns/txt؛ i=foo@eng.example.net ؛
 t=1117574938؛ x=1118006938؛ l=200؛
 h=from:to:subject:date:keywords:keywords؛
 z=From: foo@eng.example.net |To: joe@example.com |
 Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700؛
 bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=؛
 ب=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
 VoG4ZHRNiYzR

حيث يتم استخدام العلامات التالية:

  • v (مطلوب)، الإصدار
  • أ (مطلوب) خوارزمية التوقيع
  • د (مطلوب)، معرف نطاق التوقيع (SDID)
  • s (مطلوب)، محدد
  • ج (اختياري)، خوارزميات التطبيع للرأس والنص
  • q (اختياري)، طريقة الاستعلام الافتراضية
  • i (اختياري)، معرف العميل أو المستخدم (AUID)
  • t (موصى به)، ختم زمني للتوقيع
  • x (مستحسن)، وقت انتهاء الصلاحية
  • ل (اختياري)، طول الجسم
  • h (مطلوب)، حقول الرأس - قائمة بالملفات التي تم توقيعها
  • z (اختياري)، حقول الرأس - نسخة من حقول الرأس والقيم المحددة
  • bh (مطلوب)، حشيش الجسم
  • ب (مطلوب)، توقيع العناوين والنص

الأكثر صلة هي b للتوقيع الرقمي الفعلي لمحتويات (العناوين والنص) لرسالة البريد، و bh لتجزئة النص (محدود اختياريًا بأول ثماني بتات من النص)، و d لنطاق التوقيع، و s للمحدد.

يمكن تضمين معرف العميل أو المستخدم (AUID) اختياريًا. ويكون التنسيق عبارة عن عنوان بريد إلكتروني مع جزء محلي اختياري. ويجب أن يكون النطاق مساويًا لنطاق التوقيع أو نطاقًا فرعيًا له. ويتم ترك دلالات معرف العميل أو المستخدم (AUID) غير محددة عمدًا، ويمكن استخدامه بواسطة نطاق التوقيع لإنشاء مجال مسؤولية أكثر دقة.

يساهم كل من الرأس والنص في التوقيع. أولاً، يتم تجزئة نص الرسالة، دائمًا من البداية، وربما يتم اقتطاعه إلى طول معين l (قد يكون صفرًا). ثانيًا، يتم تجزئة حقول الرأس المحددة، بالترتيب المحدد بواسطة h . تتم مطابقة أسماء الحقول المتكررة من أسفل الرأس إلى أعلى، وهو الترتيب الذي Received:يتم به إدراج الحقول في الرأس. يتطابق الحقل غير الموجود مع السلسلة الفارغة، بحيث يؤدي إضافة حقل بهذا الاسم إلى كسر التوقيع. تتم إضافة DKIM-Signature:حقل التوقيع الذي يتم إنشاؤه، مع bh يساوي تجزئة النص المحسوب و b يساوي السلسلة الفارغة، ضمناً إلى التجزئة الثانية، على الرغم من عدم ظهور اسمه في h - إذا ظهر، فإنه يشير إلى توقيع آخر موجود مسبقًا. لكلا التجزئتين، يتم إضفاء الطابع القانوني على النص وفقًا لخوارزميات c ذات الصلة. النتيجة، بعد التشفير بالمفتاح الخاص للموقع والترميز باستخدام Base64، هي b .

بالإضافة إلى قائمة حقول الرأس المدرجة في h ، قد يتم توفير قائمة بحقول الرأس (بما في ذلك اسم الحقل والقيمة) الموجودة في وقت التوقيع في z . لا يلزم أن تتطابق هذه القائمة مع قائمة الرؤوس في h .

من المفترض أن يتم اختيار الخوارزميات والحقول وطول النص لضمان تحديد واضح للرسالة مع السماح للتوقيعات بالبقاء على قيد الحياة في ظل التغييرات التي لا مفر منها والتي ستحدث أثناء النقل. لا يوجد أي ضمان لسلامة البيانات من البداية إلى النهاية. [2]

تَحَقّق

يستخدم خادم SMTP المتلقي الذي يرغب في التحقق اسم المجال والمحدد لإجراء بحث DNS. [8] على سبيل المثال، بالنظر إلى توقيع المثال أعلاه: يعطي علامة d مجال المؤلف الذي سيتم التحقق منه، example.net  ؛ يعطي علامة s المحدد، brisbane . السلسلة _domainkey هي جزء ثابت من المواصفات. هذا يعطي سجل مورد TXT الذي سيتم البحث عنه على النحو التالي:

brisbane._domainkey.example.net

لاحظ أن المحدد واسم المجال يمكن أن يكونا UTF-8 في البريد الإلكتروني الدولي. [9] في هذه الحالة يجب ترميز الملصق وفقًا لـ IDNA قبل البحث. البيانات المسترجعة من استعلام هذا السجل هي أيضًا قائمة بأزواج العلامة والقيمة. وهي تتضمن المفتاح العام للمجال ، إلى جانب رموز استخدام المفتاح الأخرى والأعلام (على سبيل المثال من سطر الأوامر: nslookup -q=TXT brisbane._domainkey.example.net) كما في هذا المثال: 

"k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDDmzRmJRQxLEuyYiyMg4suA2Sy
MwR5MGHpP9diNT1hRiwUd/mZp1ro7kIDTKS8ttkI6z6eTRW9e9dDOxzSxNuXmume60Cjbu08gOyhPG3
"GfWdg7QkdN6kR4V75MFlw624VY35DaXBvnlTJTgRg/EW72O1DiYVThkyCgpSYS8nmEQIDAQAB"

يمكن أيضًا استخدام سجل CNAME للإشارة إلى سجل TXT مختلف، على سبيل المثال عندما ترسل مؤسسة بريدًا إلكترونيًا نيابة عن مؤسسة أخرى.

يمكن للمستقبل استخدام المفتاح العام (قيمة علامة p ) للتحقق من صحة التوقيع على قيمة التجزئة في حقل الرأس، ومقارنتها بقيمة التجزئة لرسالة البريد (الرؤوس والنص) التي تم استلامها. إذا تطابقت القيمتان، فهذا يثبت تشفيريًا أن البريد تم توقيعه بواسطة المجال المشار إليه ولم يتم العبث به أثناء النقل.

لا يؤدي فشل التحقق من التوقيع إلى إجبار المرسل على رفض الرسالة. وبدلاً من ذلك، يجب توفير الأسباب الدقيقة التي تجعل من المستحيل إثبات صحة الرسالة للعمليات اللاحقة والمستقبلية. وقد تتضمن الطرق المستخدمة في هذا الصدد إرسال رسالة FBL ، أو إضافة Authentication-Results:حقل رأس إلى الرسالة كما هو موضح في RFC 7001.

براءة اختراع

كانت DomainKeys مشمولة ببراءة الاختراع الأمريكية رقم 6,986,049 ، والتي انتهت صلاحيتها الآن. قامت Yahoo! بترخيص مطالبات براءات الاختراع الخاصة بها بموجب نظام ترخيص مزدوج: اتفاقية ترخيص براءات اختراع DomainKeys v1.2 ، [10] أو رخصة جنو العمومية العامة v2.0 (ولا يوجد إصدار آخر) . [11] [12]

العلاقة مع SPF و DMARC

في الأساس، يوفر كل من DKIM و SPF مقاييس مختلفة لمصداقية البريد الإلكتروني. يوفر DMARC القدرة للمؤسسة على نشر سياسة تحدد الآلية (DKIM أو SPF أو كليهما) المستخدمة عند إرسال البريد الإلكتروني من هذا المجال؛ وكيفية التحقق من الحقل From:المعروض للمستخدمين النهائيين؛ وكيف ينبغي للمستقبل التعامل مع حالات الفشل - وآلية إعداد التقارير للإجراءات التي يتم تنفيذها بموجب هذه السياسات. [13]

المزايا

الميزة الأساسية لهذا النظام بالنسبة لمتلقي البريد الإلكتروني هي أنه يسمح للنطاق الموقع بتحديد تدفق البريد الإلكتروني الشرعي بشكل موثوق، وبالتالي السماح للقوائم السوداء والقوائم البيضاء القائمة على النطاق بأن تكون أكثر فعالية. [14] ومن المرجح أيضًا أن يجعل هذا من السهل اكتشاف أنواع معينة من هجمات التصيد الاحتيالي .

هناك بعض الحوافز لمرسلي البريد لتوقيع البريد الإلكتروني الصادر:

  • إنه يسمح بتقليل كبير في عمل مكتب إساءة الاستخدام للمجالات التي تدعم DKIM إذا استخدم مستلمو البريد الإلكتروني نظام DKIM لتحديد رسائل البريد الإلكتروني المزورة التي تدعي أنها من هذا المجال.
  • يمكن لمالك المجال بعد ذلك أن يركز طاقات فريقه المعني بإساءة الاستخدام على المستخدمين الذين يقومون بالفعل باستخدام هذا المجال بشكل غير مناسب.

استخدم مع تصفية البريد العشوائي

DKIM هي طريقة لتصنيف الرسائل، ولا تقوم هي نفسها بتصفية أو تحديد البريد العشوائي. ومع ذلك، فإن الاستخدام الواسع النطاق لـ DKIM يمكن أن يمنع مرسلي البريد العشوائي من تزوير عنوان المصدر لرسائلهم، وهي التقنية التي يستخدمونها بشكل شائع اليوم. إذا أُجبر مرسلي البريد العشوائي على إظهار نطاق المصدر الصحيح، يمكن أن تعمل تقنيات التصفية الأخرى بشكل أكثر فعالية. على وجه الخصوص، يمكن أن يغذي نطاق المصدر نظام السمعة لتحديد البريد العشوائي بشكل أفضل. وعلى العكس من ذلك، يمكن أن يجعل DKIM من السهل تحديد البريد المعروف أنه ليس بريدًا عشوائيًا ولا يحتاج إلى تصفيته. إذا كان نظام الاستقبال يحتوي على قائمة بيضاء بمجالات الإرسال الجيدة المعروفة، إما يتم صيانتها محليًا أو من جهات خارجية مصدقة، فيمكنه تخطي التصفية على البريد الموقّع من تلك المجالات، وربما تصفية البريد المتبقي بشكل أكثر عدوانية. [14]

مكافحة التصيد الاحتيالي

يمكن أن يكون DKIM مفيدًا كتقنية لمكافحة التصيد الاحتيالي . يمكن لمرسلي البريد في المجالات التي تتعرض لصيد احتيالي كثيف توقيع بريدهم لإظهار أنه أصلي. يمكن للمستلمين اعتبار عدم وجود توقيع صالح على البريد من تلك المجالات مؤشرًا على أن البريد مزور على الأرجح. تظل أفضل طريقة لتحديد مجموعة المجالات التي تستحق هذه الدرجة من التدقيق سؤالًا مفتوحًا. اعتادت DKIM أن تحتوي على ميزة اختيارية تسمى ADSP والتي تتيح للمؤلفين الذين يوقعون على جميع بريدهم تحديد هويتهم الذاتية، ولكن تم تخفيض رتبتها إلى حالة تاريخية في نوفمبر 2013. [15] بدلاً من ذلك، يمكن استخدام DMARC لنفس الغرض [16] وتسمح للمجالات بنشر التقنيات (بما في ذلك SPF وDKIM) التي تستخدمها، مما يسهل على المستلم اتخاذ قرار مستنير بشأن ما إذا كان بريد معين بريدًا عشوائيًا أم لا. [17] على سبيل المثال، باستخدام DMARC، تنشر كل من eBay و PayPal سياسات مفادها أن جميع رسائل البريد الخاصة بهما مصدقة، وتطلب من أي نظام استقبال، مثل Gmail ، رفض أي بريد غير مصدقة. [18]

التوافق

نظرًا لأنه يتم تنفيذه باستخدام سجلات DNS وحقل رأس RFC 5322 مضاف، فإن DKIM متوافق مع البنية الأساسية الحالية للبريد الإلكتروني. وبشكل خاص، فهو شفاف لأنظمة البريد الإلكتروني الحالية التي تفتقر إلى دعم DKIM. [19]

يتوافق نهج التصميم هذا أيضًا مع خدمات أخرى ذات صلة، مثل معايير حماية المحتوى S/MIME و OpenPGP . يتوافق DKIM مع معيار DNSSEC ومع SPF .

تكاليف الحساب

تتطلب DKIM إنشاء مجموعات اختبار تشفيرية لكل رسالة يتم إرسالها عبر خادم بريد، مما يؤدي إلى زيادة في التكلفة الحسابية غير المطلوبة لتسليم البريد الإلكتروني. هذه التكلفة الحسابية الإضافية هي السمة المميزة للطوابع البريدية الرقمية، مما يجعل إرسال البريد العشوائي بكميات كبيرة أكثر تكلفة (حسابيًا). [20] قد يبدو هذا الجانب من DKIM مشابهًا لـ hashcash ، باستثناء أن التحقق من جانب المتلقي يتطلب قدرًا ضئيلًا من العمل، في حين تتطلب خوارزمية hashcash النموذجية المزيد من العمل. [ بحاجة لمصدر ]

عدم قابلية الإنكار

تمنع ميزة عدم الإنكار في DKIM المرسلين (مثل مرسلي البريد العشوائي) من إنكار إرسال بريد إلكتروني بشكل موثوق. وقد أثبتت فائدتها لمصادر وسائل الإعلام الإخبارية مثل WikiLeaks ، والتي تمكنت من الاستفادة من توقيعات نص DKIM لإثبات أن رسائل البريد الإلكتروني المسربة كانت أصلية ولم يتم العبث بها. [21]

يعتبر الكثيرون أن عدم التنصل ميزة غير مرغوب فيها في DKIM، مفروضة بسبب سلوكيات مثل تلك التي تم وصفها للتو. في الواقع، يوفر بروتوكول DKIM انتهاء الصلاحية. هناك علامة x اختيارية على كل توقيع، والتي تحدد وقت انتهاء الصلاحية الرسمي؛ ومع ذلك، يمكن للمحققين تجاهلها. بالإضافة إلى ذلك، يمكن لمالكي النطاق إلغاء مفتاح عام عن طريق إزالة بياناته التشفيرية من السجل، وبالتالي منع التحقق من التوقيع ما لم يحفظ شخص ما بيانات المفتاح العام مسبقًا. غالبًا ما يُنصح بتدوير مفتاح DKIM فقط لتقليل تأثير المفاتيح المخترقة. ومع ذلك، من أجل تعطيل عدم التنصل بشكل نهائي، يمكن نشر المفاتيح السرية منتهية الصلاحية، وبالتالي السماح للجميع بإنتاج توقيعات مزيفة، وبالتالي إبطال أهمية التوقيعات الأصلية. [22] [23] [24]

نقاط الضعف

يحدد RFC نفسه عددًا من متجهات الهجوم المحتملة. [25]

لا تشتمل توقيعات DKIM على مغلف الرسالة، الذي يحتوي على مسار العودة ومستقبلي الرسالة. ونظرًا لأن DKIM لا يحاول الحماية من العناوين الخاطئة، فإن هذا لا يؤثر على فائدته.

وقد أثيرت العديد من المخاوف وتم دحضها في عام 2013 في وقت التوحيد القياسي. [26]

إن أحد المخاوف التي تواجه أي حل تشفيري هو إساءة استخدام إعادة تشغيل الرسائل ، والتي تتجاوز التقنيات التي تحد حاليًا من مستوى إساءة الاستخدام من المجالات الأكبر. [ التوضيح مطلوب ] يمكن استنتاج إعادة التشغيل باستخدام مفاتيح عامة لكل رسالة، وتتبع استعلامات DNS لهذه المفاتيح وتصفية العدد الكبير من الاستعلامات بسبب إرسال البريد الإلكتروني إلى قوائم بريدية كبيرة أو الاستعلامات الضارة من قبل الجهات الفاعلة السيئة.

لمقارنة الطرق المختلفة التي تعالج هذه المشكلة أيضًا، راجع مصادقة البريد الإلكتروني .

إعادة التوجيه التعسفي

كما ذكرنا أعلاه، فإن المصادقة ليست مثل منع إساءة الاستخدام. يمكن لمستخدم بريد إلكتروني ضار من مجال حسن السمعة أن يؤلف رسالة سيئة ويوقعها DKIM ويرسلها من ذلك المجال إلى أي صندوق بريد يمكنه من استرجاعها كملف، وذلك للحصول على نسخة موقعة من الرسالة. إن استخدام علامة l في التوقيعات يجعل تعديل مثل هذه الرسائل أسهل. يمكن بعد ذلك إعادة توجيه النسخة الموقعة إلى مليون مستلم، على سبيل المثال من خلال شبكة روبوتية ، دون سيطرة. يمكن لمزود البريد الإلكتروني الذي وقع على الرسالة حظر المستخدم المخالف، لكنه لا يستطيع إيقاف انتشار الرسائل الموقعة بالفعل. يمكن تقييد صلاحية التوقيعات في مثل هذه الرسائل من خلال تضمين علامة وقت انتهاء الصلاحية دائمًا في التوقيعات، أو بإلغاء مفتاح عام بشكل دوري أو عند إشعار بحادث. لا يمكن تقييد فعالية السيناريو من خلال تصفية البريد الصادر، لأن هذا يعني القدرة على اكتشاف ما إذا كانت الرسالة قد تكون مفيدة لمرسلي البريد العشوائي. [27]

تعديل المحتوى

يتميز DKIM حاليًا بخوارزميتين للقياس القياسي ، بسيطة ومريحة ، ولا يتعرف أي منهما على MIME . [28] يمكن لخوادم البريد التحويل بشكل شرعي إلى مجموعة أحرف مختلفة، وغالبًا ما توثق ذلك بحقول الرأس. بالإضافة إلى ذلك، يتعين على الخوادم في ظروف معينة إعادة كتابة بنية MIME، وبالتالي تغيير المقدمة والخاتمة وحدود الكيان، وأي منها يكسر توقيعات DKIM. فقط رسائل النص العادي المكتوبة بتنسيق us-ascii ، بشرط عدم توقيع حقول رأس MIME، [29] تتمتع بالمتانة التي تتطلبها السلامة الشاملة. X-MIME-Autoconverted:

نظم مشروع OpenDKIM عملية جمع بيانات شملت 21 خادم بريد وملايين الرسائل. وتم التحقق بنجاح من 92.3% من التوقيعات التي تمت ملاحظتها، وهو معدل نجاح ينخفض ​​قليلاً (90.5%) عندما يتم النظر فقط في حركة قائمة البريد. [30]

التعليقات التوضيحية من خلال قوائم البريد

قد تتفاقم المشاكل عندما يقوم برنامج التصفية أو إعادة التوجيه بإجراء تغييرات على الرسالة. بدون احتياطات محددة ينفذها المرسل، فإن إضافة التذييل التي يتم تشغيلها بواسطة معظم قوائم البريد والعديد من حلول مكافحة الفيروسات المركزية ستكسر توقيع DKIM. أحد الحلول الممكنة للتخفيف من المشكلة هو التوقيع فقط على عدد معين من بايتات نص الرسالة. يتم الإشارة إلى ذلك بواسطة علامة l في رأس توقيع DKIM . لا يتم أخذ أي شيء يضاف بعد الطول المحدد لنص الرسالة في الاعتبار أثناء حساب توقيع DKIM. لن يعمل هذا مع رسائل MIME. [31]

هناك حل آخر يتمثل في إدراج المرسلين المعروفين في القائمة البيضاء؛ على سبيل المثال، بواسطة SPF . ولحل آخر، تم اقتراح أن يتحقق المرسلون من التوقيع، ويعدلون البريد الإلكتروني، ثم يعيدون توقيع الرسالة باستخدام رأس Sender: [32] ومع ذلك، فإن هذا الحل ينطوي على مخاطر مع الرسائل الموقعة من جهات خارجية المعاد توجيهها والتي يتم استلامها في أجهزة استقبال SMTP التي تدعم بروتوكول RFC 5617 ADSP . وبالتالي، في الممارسة العملية، لا يزال يتعين على الخادم المستقبل إدراج تدفقات الرسائل المعروفة في القائمة البيضاء .

سلسلة الاستلام المعتمدة (ARC) هي نظام مصادقة بريد إلكتروني مصمم للسماح لخادم بريد وسيط مثل قائمة بريدية أو خدمة إعادة توجيه بتوقيع نتائج المصادقة الأصلية للبريد الإلكتروني. يسمح هذا لخدمة الاستلام بالتحقق من صحة البريد الإلكتروني عندما يتم إبطال سجلات SPF و DKIM للبريد الإلكتروني بواسطة معالجة خادم وسيط. [33] تم تعريف ARC في RFC 8617، المنشور في يوليو 2019، على أنه "تجريبي". [34]

ثغرة المفتاح القصير

في أكتوبر 2012، أفاد موقع Wired أن عالم الرياضيات Zach Harris اكتشف وأثبت وجود ثغرة في انتحال مصدر البريد الإلكتروني باستخدام مفاتيح DKIM قصيرة للنطاق google.comالمؤسسي، فضلاً عن العديد من النطاقات البارزة الأخرى. وذكر أن المصادقة باستخدام مفاتيح 384 بت يمكن حسابها في أقل من 24 ساعة "على الكمبيوتر المحمول الخاص بي"، ومفاتيح 512 بت، في حوالي 72 ساعة باستخدام موارد الحوسبة السحابية. وجد Harris أن العديد من المؤسسات توقع البريد الإلكتروني بمثل هذه المفاتيح القصيرة؛ فقام بتحليلها جميعًا وأبلغ المؤسسات بالثغرة. وذكر أنه يمكن حساب مفاتيح 768 بت مع الوصول إلى كميات كبيرة جدًا من قوة الحوسبة، لذلك يقترح أن يستخدم توقيع DKIM أطوال مفاتيح أكبر من 1024.

صرحت مجلة Wired أن هاريس أفاد، وأكدت جوجل، أنهم بدأوا في استخدام مفاتيح أطول جديدة بعد فترة وجيزة من كشفه. وفقًا لـ RFC 6376، يجب أن يكون الطرف المتلقي قادرًا على التحقق من صحة التوقيعات باستخدام مفاتيح تتراوح من 512 بت إلى 2048 بت، وبالتالي فإن استخدام مفاتيح أقصر من 512 بت قد يكون غير متوافق ويجب تجنبه. تنص RFC 6376 أيضًا على أنه يجب على الموقعين استخدام مفاتيح لا تقل عن 1024 بت للمفاتيح طويلة العمر، على الرغم من عدم تحديد طول العمر هناك. [35]

تاريخ

نتج DKIM في عام 2004 عن دمج جهدين مماثلين، "مفاتيح المجال المحسنة" من Yahoo و"البريد الإلكتروني المحدد" من Cisco . [36] [37] كان هذا الدمج هو الأساس لسلسلة من مواصفات مسار معايير IETF ووثائق الدعم التي أسفرت في النهاية عن STD 76، حاليًا RFC 6376. [38] اقترحت Cisco "البريد الإلكتروني المحدد" كمعيار مصادقة بريد قائم على التوقيع، [39] [40] بينما صممت Yahoo DomainKeys [41] [42] للتحقق من نطاق DNS لمرسل البريد الإلكتروني وسلامة الرسالة .

تم دمج جوانب DomainKeys، جنبًا إلى جنب مع أجزاء من Identified Internet Mail، لإنشاء DomainKeys Identified Mail (DKIM). [41] [43] [44] تشمل مقدمي الخدمات الرائدين الذين ينفذون DKIM Yahoo و Gmail و AOL و FastMail . يجب أن تحمل أي رسالة بريدية من هذه المؤسسات توقيع DKIM. [41] [45] [46] [47]

جرت المناقشات حول مرور توقيعات DKIM عبر تدفقات البريد غير المباشر، رسميًا في مجموعة عمل DMARC، مباشرة بعد أن أحدثت التبنيات الأولى للبروتوكول الجديد فوضى في استخدام قائمة البريد العادية . ومع ذلك، لم يتم تمرير أي من تغييرات DKIM المقترحة. بدلاً من ذلك، تم تغيير برنامج قائمة البريد. [48] [ اقتباس غير ذي صلة ]

في عام 2017، تم إطلاق مجموعة عمل أخرى، تحديث تشفير DKIM (dcrup)، مع التقييد المحدد لمراجعة تقنيات التوقيع. [49] تم إصدار RFC 8301 في يناير 2018. يحظر SHA-1 ويقوم بتحديث أحجام المفاتيح (من 512-2048 إلى 1024-4096). [50] تم إصدار RFC 8463 في سبتمبر 2018. يضيف خوارزمية منحنى إهليلجي إلى RSA الحالية . نوع المفتاح المضاف قوي بشكل كافٍ مع وجود مفاتيح عامة قصيرة، يمكن نشرها بسهولة أكبر في DNS. [51]k=ed25519

تطوير

تم تصميم DomainKeys الأصلي بواسطة Mark Delany من Yahoo! وتم تحسينه من خلال تعليقات من العديد من الآخرين منذ عام 2004. وقد تم تحديده في Historic RFC 4870، والذي حل محله Standards Track RFC 4871، DomainKeys Identified Mail (DKIM) Signatures؛ وقد تم نشر كليهما في مايو 2007. تم جمع عدد من التوضيحات والمفاهيم بعد ذلك وتم تحديدها في RFC 5672، أغسطس 2009، في شكل تصحيحات للمواصفات الحالية. في سبتمبر 2011، قام RFC 6376 بدمج وتحديث الوثيقتين الأخيرتين، مع الحفاظ على جوهر بروتوكول DKIM. كما أن توافق المفتاح العام مع DomainKeys السابقة ممكن أيضًا.

تم إنتاج DKIM في البداية بواسطة اتحاد صناعي غير رسمي وتم تقديمه بعد ذلك للتحسين والتوحيد القياسي من قبل مجموعة عمل DKIM التابعة لـ IETF ، برئاسة Barry Leiba وStephen Farrell، مع Eric Allman من sendmail و Jon Callas من PGP Corporation و Mark Delany وMiles Libbey من Yahoo! وJim Fenton وMichael Thomas من Cisco Systems كمؤلفين رئيسيين.

يتم تطوير الكود المصدر لمكتبة واحدة مشتركة بواسطة مشروع OpenDKIM ، بعد الإضافات الأخيرة للبروتوكول، والترخيص بموجب ترخيص BSD الجديد . [52]

التنفيذ

يتطلب موفرو البريد الإلكتروني بشكل متزايد من المرسلين تنفيذ مصادقة البريد الإلكتروني حتى يتمكنوا من تسليم البريد بنجاح إلى صناديق بريد المستخدمين.

في فبراير 2024، بدأت Google في مطالبة المرسلين بالجملة بمصادقة رسائل البريد الإلكتروني الخاصة بهم باستخدام DKIM لتسليم رسائل البريد الإلكتروني بنجاح إلى صناديق البريد المستضافة على Google. [53] [54]

على نحو مماثل، في فبراير 2024، بدأت شركة Yahoo في مطالبة المرسلين بالجملة بتنفيذ SPF وDKIM لتسليم رسائل البريد الإلكتروني إلى مستخدمي Yahoo بنجاح. [55]

انظر أيضا

مراجع

  1. ^ توني هانسن؛ ديف كروكر؛ فيليب هالام بيكر (يوليو 2009). نظرة عامة على خدمة البريد المعرف بمفاتيح النطاق (DKIM). IETF . doi : 10.17487/RFC5585 . RFC 5585. تم الاسترجاع في 6 يناير 2016. يمكن للمستلمين الذين يتحققون بنجاح من التوقيع استخدام المعلومات حول المُوقِّع كجزء من برنامج للحد من البريد العشوائي أو التزييف أو التصيد الاحتيالي أو السلوكيات غير المرغوب فيها الأخرى. لا يحدد DKIM، في حد ذاته، أي إجراءات محددة من قِبل المستلم؛ بل إنه تقنية تمكينية للخدمات التي تفعل ذلك.
  2. ^ من قبل ديف كروكر؛ توني هانسن؛ موراي إس. كوتشراوي ، محررون (سبتمبر 2011). "سلامة البيانات". توقيعات البريد المعرف بمفاتيح النطاق (DKIM). IETF . القسم 1.5. doi : 10.17487/RFC6376 . RFC 6376. تم الاسترجاع في 6 يناير 2016. يؤكد التحقق من التوقيع أن المحتوى المشفر لم يتغير منذ توقيعه ولا يؤكد أي شيء آخر حول "حماية" سلامة الرسالة من البداية إلى النهاية.
  3. ^ كروكر، د.؛ هانسن، ت.؛ كوتشراوي، م. (سبتمبر 2011). "توقيعات البريد المحددة بمفاتيح المجال (DKIM)". محرر RFC . ISSN  2070-1721 . تم الاسترجاع في 30 مارس 2020 .
  4. ^ "DKIM: ما هو ولماذا هو مهم؟". postmarkapp.com . تم الاسترجاع في 19 فبراير 2022 .
  5. ^ جيسون ب. ستادتلاندر (16 يناير 2015). "انتحال البريد الإلكتروني: شرح (وكيفية حماية نفسك)". هافينغتون بوست . تم الاسترجاع في 11 يناير 2016 .
  6. ^ Dave Crocker; Tony Hansen; Murray S. Kucherawy, eds. (يوليو 2009). "تحديد حقول الرأس للتوقيع". DomainKeys Identified Mail (DKIM) Signatures. IETF . sec. 5.4. doi : 10.17487/RFC6376 . RFC 6376 . تم الاسترجاع في 6 يناير 2016 . يجب توقيع حقل رأس "From" (أي تضمينه في علامة "h=" لحقل رأس DKIM-Signature الناتج).
  7. ^ تستخدم وحدات التوقيع النصف الخاص من زوج المفاتيح للقيام بالتوقيع، وتنشر النصف العام في سجل DNS TXT كما هو موضح في قسم "التحقق" أدناه.
  8. ^ لاحظ أنه لا توجد هيئات تصديق ولا قوائم إلغاء تشارك في إدارة مفاتيح DKIM، وأن المحدد هو طريقة مباشرة للسماح للموقعين بإضافة وإزالة المفاتيح وقتما يشاؤون - التوقيعات طويلة الأمد لأغراض الأرشفة تقع خارج نطاق DKIM.
  9. ^ جون ليفين (يونيو 2019). "DKIM والبريد الدولي". مصادقة البريد الإلكتروني للبريد الدولي. IETF . القسم 5. doi : 10.17487/RFC8616 . RFC 8616.
  10. ^ "اتفاقية ترخيص براءة اختراع Yahoo! DomainKeys v1.1". SourceForge . 2006 . تم الاسترجاع في 30 مايو 2010 . اتفاقية ترخيص براءة اختراع Yahoo! DomainKeys v1.2
  11. ^ Levine, John R. (25 January 2010). "IPR disclosures, was Collecting re-chartering questions". قائمة بريدية ietf-dkim . Mutual Internet Practices Association. مؤرشف من الأصل في 14 سبتمبر 2016 . تم الاسترجاع في 30 مايو 2010 . يبدو لي أن الإشارة إلى GPL تغطي فقط مكتبة Sourceforge DK القديمة، والتي لا أعتقد أن أي شخص يستخدمها بعد الآن. براءة الاختراع، وهي المهمة، مغطاة برخصة منفصلة كتبتها Yahoo.
  12. ^ تشين، آندي (26 سبتمبر 2011). "بيان شركة ياهو بشأن حقوق الملكية الفكرية المتعلقة بـ RFC 6376". الكشف عن حقوق الملكية الفكرية . IETF . تم الاسترجاع في 3 أكتوبر 2011 .
  13. ^ "التاريخ". dmarc.org .
  14. ^ ab Falk, JD (17 مارس 2009). "البحث عن الحقيقة في DKIM". CircleID.
  15. ^ Barry Leiba (25 نوفمبر 2013). "تغيير حالة ADSP (RFC 5617) إلى تاريخي". IETF . تم الاسترجاع في 13 مارس 2015 .
  16. ^ "الأسئلة الشائعة - ويكي DMARC". تنص معايير DMARC في القسم 6.7، "اعتبارات تطبيق السياسة"، على أنه في حالة اكتشاف سياسة DMARC، يجب على المتلقي تجاهل السياسات المعلن عنها من خلال وسائل أخرى مثل SPF أو ADSP.
  17. ^ "إضافة سجل DMARC - مساعدة مسؤول Google Apps".
  18. ^ "حول DMARC - مساعدة مسؤول Google Apps". يمكن أن تكون سياستك صارمة أو متساهلة. على سبيل المثال، تنشر eBay وPayPal سياسة تتطلب مصادقة جميع رسائل البريد الخاصة بهما حتى تظهر في صندوق الوارد الخاص بشخص ما. وفقًا لسياستهما، ترفض Google جميع الرسائل من eBay أو PayPal التي لم يتم مصادقة رسائلها.
  19. ^ توني هانسن؛ ديف كروكر؛ فيليب هالام بيكر (يوليو 2009). نظرة عامة على خدمة DomainKeys Identified Mail (DKIM). IETF . doi : 10.17487/RFC5585 . RFC 5585. تم الاسترجاع في 1 يوليو 2013 .
  20. ^ Roic, Alessio (5 يوليو 2007). "ختم البريد: المساعدة في مكافحة البريد العشوائي" محفوظ في 17 يوليو 2011 على موقع Wayback Machine . مدونة Microsoft Office Outlook.
  21. ^ "DKIM Verification". www.wikileaks.org . 4 نوفمبر 2016 . تم الاسترجاع في 7 نوفمبر 2016 .
  22. ^ ماثيو د. جرين (16 نوفمبر 2020). "حسنًا يا جوجل: يرجى نشر مفاتيح DKIM السرية الخاصة بك". cryptographyengineering.com . جوجل.
  23. ^ إيان جاكسون (2022). "dkim-rotate - مبادئ التشغيل". manpages.ubuntu.com . أوبونتو.
  24. ^ "مفاتيح توقيع DKIM". iecc.com . 10 أبريل 2023 . تم الاسترجاع في 27 أبريل 2023 .
  25. ^ د. كروكر؛ ت. هانسن؛ م. كوتشراوي . "اعتبارات أمنية". توقيعات البريد المعرف بمفاتيح النطاق (DKIM). IETF . القسم 8. doi : 10.17487/RFC6376 . RFC 6376.
  26. ^ "تقرير IESG بشأن "استئناف القرار بإصدار RFC6376". IETF.org . IETF . تم الاسترجاع في 26 ديسمبر 2018 .
  27. ^ جيم فينتون (سبتمبر 2006). "إعادة تشغيل الرسالة المختارة". تحليل التهديدات التي تحفز البريد المحدد بمفاتيح النطاق (DKIM). IETF . القسم 4.1.4. doi : 10.17487/RFC4686 . RFC 4686. تم الاسترجاع في 10 يناير 2016 .
  28. ^ Ned Freed (بموافقة جون كلينسين ) (5 مارس 2010). "secdir review of draft-ietf-yam-rfc1652bis-03". قائمة بريدية YAM . IETF . تم الاسترجاع في 30 مايو 2010. اختارت مجموعة عمل DKIM البساطة في الشكل التقليدي بدلاً من الشكل التقليدي القوي في مواجهة تغييرات الترميز. كان هذا هو خيارهم الهندسي وقد نجحوا في ذلك.
  29. ^ يسمح RFC 2045 لقيمة المعلمة بأن تكون إما رمزًا أو سلسلة مقتبسة، على سبيل المثال في {{{1}}} يمكن إزالة علامات الاقتباس بشكل قانوني، مما يؤدي إلى كسر توقيعات DKIM.
  30. ^ Kucherawy, Murray (28 مارس 2011). "RFC4871 Implementation Report". IETF . تم الاسترجاع في 18 فبراير 2012 .
  31. ^ Murray S. Kucherawy (سبتمبر 2011). DomainKeys Identified Mail (DKIM) and Mailing Lists. IETF . doi : 10.17487/RFC6377 . RFC 6377 . تم الاسترجاع في 10 يناير 2016 .
  32. ^ Eric Allman; Mark Delany; Jim Fenton (August 2006). "Mailing List Manager Actions". ممارسات توقيع مرسل DKIM. IETF . sec. 5.1. ID draft-allman-dkim-ssp-02 . تم الاسترجاع في 10 يناير 2016 .
  33. ^ "نظرة عامة على سلسلة الاستلام المعتمدة" (PDF) . تم الاسترجاع في 15 يونيو 2017 .
  34. ^ K. Andersen؛ B. Long؛ S. Blank؛ M. Kucherawy . بروتوكول سلسلة الاستلام المعتمدة (ARC). IETF . doi : 10.17487/RFC8617/ . RFC 8617/.
  35. ^ زيتر، كيم (24 أكتوبر 2012). "كيف كشف بريد إلكتروني لموظف في شركة جوجل ثغرة أمنية ضخمة في الشبكة". Wired . تم الوصول إليه في 24 أكتوبر 2012.
  36. ^ "الأسئلة الشائعة حول DKIM". DKIM.org . 16 أكتوبر 2007. تم استرجاعه في 4 يناير 2016. تم إنتاج DKIM بواسطة اتحاد صناعي في عام 2004. وقد تم دمج وتحسين DomainKeys، من Yahoo! وIdentified Internet Mail، من Cisco .
  37. ^ جيم فينتون (15 يونيو 2009). "البريد المحدد بمفاتيح المجال (DKIM) ينمو بشكل ملحوظ". سيسكو . مؤرشف من الأصل في 24 ديسمبر 2014. تم الاسترجاع في 28 أكتوبر 2014 .
  38. ^ "STD 76, RFC 6376 on DomainKeys Identified Mail (DKIM) Signatures". IETF . 11 يوليو 2013 . تم الاسترجاع في 12 يوليو 2013 . تمت ترقية RFC 6376 إلى معيار الإنترنت.
  39. ^ "البريد الإلكتروني المحدد: نهج توقيع الرسائل عبر الشبكة لمكافحة الاحتيال عبر البريد الإلكتروني". 26 أبريل 2006. مؤرشف من الأصل في 27 أبريل 2006. تم الاسترجاع 4 يناير 2016 .
  40. ^ جيم فينتون؛ مايكل توماس (1 يونيو 2004). بريد إنترنت محدد. IETF . معرف draft-fenton-identified-mail-00 . تم الاسترجاع في 6 يناير 2016 .
  41. ^ abc Delany, Mark (22 May 2007). "One small step for email, one giant jump for Internet safety" Archived 14 March 2013 at the Wayback Machine . مدونة شركة ياهو!. يُنسب إلى ديلاني الفضل باعتباره كبير المهندسين المعماريين ومخترع DomainKeys.
  42. ^ "Yahoo تصدر مواصفات DomainKeys". DMNews.com . 19 مايو 2004.
  43. ^ RFC 4870 ("مصادقة البريد الإلكتروني المستندة إلى المجال باستخدام المفاتيح العامة المعلن عنها في DNS (مفاتيح المجال)"؛ تم إلغاؤها بواسطة RFC 4871).
  44. ^ RFC 6376 ("توقيعات البريد المعرف بمفاتيح المجال (DKIM))؛ يجعل RFC 4871 وRFC 5672 قديمين.
  45. ^ تايلور، براد (8 يوليو 2008). "مكافحة التصيد الاحتيالي باستخدام eBay وPayPal". مدونة Gmail.
  46. ^ "أواجه مشكلة في إرسال الرسائل في Gmail". إدخال تعليمات Gmail، الذي يشير إلى دعم DKIM عند الإرسال.
  47. ^ مولر، روب (13 أغسطس 2009). "كل رسائل البريد الإلكتروني الصادرة الآن تحمل توقيع DKIM" محفوظ في 6 أكتوبر 2011 على موقع Wayback Machine . مدونة Fastmail.
  48. ^ "تاريخ مجموعة DMARC". IETF .
  49. ^ "تحديث تشفير DKIM (dcrup)". IETF .
  50. ^ Scott Kitterman (يناير 2018). تحديث خوارزمية التشفير واستخدام المفتاح لـ DomainKeys Identified Mail (DKIM). IETF . doi : 10.17487/RFC8301 . RFC 8301.
  51. ^ جون ليفين (سبتمبر 2018). طريقة توقيع تشفيرية جديدة للبريد المحدد بمفاتيح المجال (DKIM). IETF . doi : 10.17487/RFC8463 . RFC 8463.
  52. ^ "OpenDKIM".
  53. ^ "حماية جديدة لـ Gmail لصندوق بريد أكثر أمانًا وأقل إزعاجًا". جوجل . 3 أكتوبر 2023.
  54. ^ "المتطلبات الجديدة لتسليم البريد الإلكتروني في Gmail - Valimail". www.valimail.com . 3 أكتوبر 2023.
  55. ^ "أفضل ممارسات المرسل". senders.yahooinc.com .

قراءة إضافية

  • تحليل التهديدات التي تحفز استخدام البريد المحدد بمفاتيح المجال (DKIM) وفقًا لمعيار RFC 4686
  • المعيار المقترح لتوقيعات البريد المحدد بمفاتيح المجال (DKIM) وفقًا لـ RFC 4871
  • ممارسات توقيع مجال المؤلف (ADSP) وفقًا لـ RFC 5617 - البريد المحدد بمفاتيح المجال (DKIM)
  • نظرة عامة على خدمة البريد المحدد بمفاتيح المجال (DKIM) وفقًا لـ RFC 5585
  • RFC 5672 RFC 4871 توقيعات البريد المعرف بمفاتيح المجال (DKIM) - تحديث
  • تطوير DKIM ونشره وتشغيله وفقًا لمعيار RFC 5863
  • مسودة معيار توقيعات البريد المعرف بمفاتيح المجال (DKIM) وفقًا لـ RFC 6376
  • RFC 6377 - البريد المحدد بمفاتيح المجال (DKIM) وقوائم البريد
  • تحديث خوارزمية التشفير واستخدام المفتاح RFC 8301 لبريد DomainKeys Identified Mail (DKIM)
  • RFC 8463 طريقة جديدة للتوقيع التشفيري للبريد المحدد بمفاتيح المجال (DKIM)
  • البريد المعرف بمفاتيح النطاق (DKIM)
Retrieved from "https://en.wikipedia.org/w/index.php?title=DomainKeys_Identified_Mail&oldid=1248823816"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate