الملخص

  • يحدد l= اختياريًا عدد octets من نص الرسالة بعد canonicalization التي تدخل في hash الخاص بـ DKIM؛ وما يتبع الحد لا يتحقق منه ذلك التوقيع حتى لو نجح.
  • يرسم h= نطاقًا آخر للرؤوس، وهو قائمة مرتبة لا مجرد مجموعة أسماء. عند تكرار الحقل، تحدد قاعدة الاختيار أي نسخة كانت داخل التوقيع.
  • يحتفظ الإيصال القابل لإعادة الفحص بالرسالة الخام، والتوقيع المحدد، وcanonicalization، وخريطة الرؤوس، وأطوال وhash البادئة والذيل، ومفتاح DNS المرصود، وأداة التحقق، وحد الثقة في Authentication-Results.

انتهى الفحص ولم تنته الرسالة

لنفترض أن النظام سجل dkim=pass، وأن طول النص بعد canonicalization بلغ 18,200 octets، بينما حمل التوقيع l=13,600. النتيجة صحيحة داخل أول 13,600 octets. أما 4,600 الباقية فلم تفشل في الفحص؛ بل لم تكن جزءًا منه.

قد تكون تلك اللاحقة تعليمات أضافتها قائمة بريد، أو علامة من نظام أرشفة، أو امتدادًا غيّر بنية MIME، أو نصًا أُدرج لجذب عين القارئ بعيدًا عن الأصل. لا يصنف pass هذه الاحتمالات، ولا يمنح الذيل سلامة مستعارة من البادئة.

تعرّف RFC 6376 هذا السلوك بوضوح. إذا غاب l= شمل hash النص الكامل بعد canonicalization. وإذا حضر، شمل عدد octets المحدد من البداية. وكل data بعد الحد غير validated بواسطة DKIM. أما l=0 فيترك body كله unsigned.

يجوز لأداة التحقق تطبيق سياسة أشد ورفض الرسالة ذات التغطية الجزئية. لكن القرار المحلي ليس إعادة تعريف للحساب. يجب أن يسجل النظام نتيجتين: هل صح التوقيع ضمن نطاقه، وماذا قررت السياسة بشأن ذلك النطاق.

وترتبط شخصية Murray Kucherawy بالموضوع بحدود الوثيقة نفسها. تسمي RFC 6376 كلًا من Dave Crocker وTony Hansen وMurray S. Kucherawy معًا؛ فلا تسند DKIM إلى مخترع وحيد. وتسمي RFC 8601 Kucherawy مؤلفًا. عند التقاط ملفه الرسمي في 2 سبتمبر 2026، عرض جدول RFC عدد 34 فيما بقي النص الذاتي عند 33. حتى المصدر الرسمي يحتاج اسم الحقل ووقت الالتقاط.

يبدأ العد بعد canonicalization

لا يمثل l= موضعًا داخل ملف .eml الخام. يطبق DKIM أولًا طريقة body canonicalization المحددة في c=. ويتعامل simple وrelaxed بصورة مختلفة مع الفراغات ونهايات الأسطر والأسطر الفارغة الأخيرة. لذلك فإن طرح l= من حجم الملف قد يعطي ذيلًا غير صحيح.

تسير إعادة الإنتاج في ترتيب ثابت: حفظ الرسالة الخام؛ اختيار instance واحدة محددة من DKIM-Signature؛ استخراج a= وc= وd= وs= وh= وl= وbh=؛ إجراء canonicalization؛ قياس الناتج؛ قطع البادئة عند الحد؛ مقارنة body hash؛ ثم فحص توقيع الرؤوس بالمفتاح العام المرصود.

يسجل الإيصال ثلاثة أطوال وثلاثة hashes: النص الكامل بعد canonicalization، والبادئة الموقعة، واللاحقة غير الموقعة. وجود لاحقة موجبة يثبت اختلاف النطاق فقط. وإذا لم يوجد l=، يسجل الإيصال تغطية كاملة بدل اختراع قيمة لم تظهر.

وللمفتاح زمن مشاهدة. يحدد d= نطاق التوقيع وs= سجل selector في DNS. قد تتغير الإجابة بعد rotation أو revocation. يلزم حفظ المفتاح الذي استُخدم ووقت lookup وresolver والأخطاء، ولا يذكر DNSSEC إلا إذا قيس فعلًا.

الهامش نفسه يخدم القائمة والمهاجم

صُمم l= لحاجة تشغيلية. تضيف قوائم البريد عادة تعليمات إلغاء الاشتراك أو تعريف القائمة إلى نهاية النص. توقيع body كامل ينكسر بهذه الإضافة؛ أما البادئة المحدودة فتسمح للمتلقي بالتعرف إلى الجزء الأصلي واتخاذ قرار محلي بشأن الزائد.

لكن الحد لا يعرف نية من يستخدم المساحة. تحذر RFC 6376 من أن وسيطًا ضارًا قد يضيف محتوى لمصلحته. ويمكن لتغيير MIME أو HTML parsing المتساهل أو العبث بكشف النسخ المكررة أن يجعل اللاحقة تبدو كأنها استبدلت الأصل في عين المستلم.

الخطأ الأول هو وصف كل footer بأنه هجوم. والخطأ الثاني هو تمديد توقيع البادئة إليه. يفصل التحقيق المنطقتين، ويحدد الوسيط، ويقارن التحويل بوظيفته المعلنة، ويعيد بناء MIME tree، ويراقب الجزء الذي عرضه العميل فعلًا.

تمنع أولوية running code عند Heng Lu استخدام سلطة النص كبديل عن أثر التنفيذ. تحدد RFC عمليات bytes، لكن الرسالة الملتقطة وإصدار verifier وأثر renderer هي التي تبين ما حُسب وما رآه القارئ.

h= يختار نسخًا مرتبة من الرؤوس

تغطية body بالكامل لا تعني توقيع كل header. يحتوي h= قائمة مرتبة بأسماء الحقول. إذا تكرر الاسم، يختار DKIM النسخ من الأسفل إلى الأعلى وفق ترتيب الظهور في القائمة. اختزالها إلى مجموعة يفقد جواب السؤال: أي Subject أو From شمله التوقيع؟

يجب تضمين From. وتوصي RFC 6376 بشدة بتغطية Date وSubject وReply-To وSender وحقول MIME المؤثرة في العرض أو المعالجة. ومع l= يصبح Content-Type بالغ الأهمية؛ فتغييره خارج التوقيع قد يجعل البادئة نفسها تظهر كمحتوى مختلف.

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

توقيع النطاق لا يثبت صاحب النص أو سلامته

يعني DKIM pass أن توقيعًا محددًا صح بالمفتاح المنشور تحت domain وselector، وعلى المادة التي اختارها. لا يعني أن الشخص الظاهر في From كتب الرسالة، أو أن استعمال المفتاح كان مصرحًا به داخليًا، أو أن الادعاءات صحيحة، أو أن attachment آمن، أو أن البريد سيسلم.

تقصر RFC 5585 الأثر على عدم تعديل الرسالة أو الجزء الموقع بعد التوقيع، وتفصل ذلك عن trust. وتطلب RFC 5863 اعتبار ما داخل scope وحده authentic، وتذكر l= مثالًا. أما RFC 8301 فتحدث algorithms وأحجام المفاتيح. المفتاح المقبول ضروري لكنه لا يوسع بادئة قصيرة.

ويختلف DMARC عن هذا السؤال. فهو يفحص alignment بين SPF أو DKIM وبين نطاق From المرئي، ويقدم إشارة policy. لا يغير h= أو l=. يجب أن تبقى validity وalignment وreputation وcontent safety وdisposition وrendering أعمدة منفصلة.

لا تثق في Authentication-Results بلا منتج موثوق

تقرأ أنظمة كثيرة Authentication-Results بدل إعادة DKIM. تحدد RFC 8601 هذه القناة بين producer وconsumer داخل trust boundary إداري، لكن الحقل لا يحمل دائمًا حماية سلامة مستقلة.

يقبل المستهلك قيم authserv-id المضبوطة لديه. وعند الدخول، يجب حذف أو تعطيل الحقول الخارجية التي تدعي أنها صادرة من الداخل قبل إضافة النتيجة المحلية. يستطيع أي مرسل كتابة dkim=pass؛ ولا تصبح العبارة قياسًا إلا إذا أثبتت بنية الاستقبال من أدخلها.

يحفظ السجل الحقل الخام وموقعه والمنتج وقاعدة الثقة والتوقيع الذي يصفه. فإذا ضغط gateway عدة توقيعات في pass مجهول، ضاع الربط مع d= وs= وh= وl=. كما تبقى method result منفصلة عن قرار القبول أو الرفض.

ledger صغير لنطاق قابل للمراجعة

تبدأ المواصفة الدنيا برسالة خام ذات hash، ثم كل DKIM-Signature بترتيبها الأصلي، مع d= وs= وi= إن وجد وa= وc= وh= وl= وbh= وقيمة التوقيع والأوقات المتاحة.

وتضيف مفتاح DNS المرصود ووقته، وطريقة canonicalization القابلة للإعادة، ونسخ الرؤوس المختارة، وأطوال وhash المناطق الثلاث، وبرنامج verifier وإصداره ونتيجته وسببه. ويوثق قسم مستقل منتج Authentication-Results وحد الثقة.

ثم يأتي العرض: MIME tree، والجزء المختار، وإصدار renderer، وهل اعتمد العرض الرئيسي على bytes بعد l=. يمكن حفظ identifiers وrender hash بما يحمي الخصوصية بدل الاحتفاظ بشاشة المستخدم كلها.

يوزع مبدأ agency الأدوار: مؤلفو المعيار يحددون syntax؛ أمين المفتاح يختار scope؛ الوسيط يحول؛ verifier يحسب؛ النطاق الإداري يضمن قناة النتيجة؛ والعميل يعرض. لا يملك أحد منهم سلطة إصدار حكم نيابة عن البقية.

والخلاصة الدقيقة هي: تحقق هذا التوقيع بهذا المفتاح المرصود من هذه الرؤوس المرتبة وأول N octets من النص بعد canonicalization؛ بقي هذا الذيل خارج النطاق؛ سجل verifier موثوق النتيجة؛ وعرض هذا العميل هذه الأجزاء. أما الكاتب البشري والسلامة والنية فتحتاج أدلة أخرى.

المصادر