مفتاح النطاق الفرعي قد يزكّي اسم النطاق الأب

الخلاصة

• أضافت مراجعة DKIM2 المؤرخة في 1 نوفمبر سجل سياسة للنطاق لم يكن في مراجعة 27 أكتوبر.
• يستطيع الأب نشر strict ليمنع النطاق الفرعي الموقّع من جعل عنوان From الذي يستخدم اسم الأب «Authentic». غياب العلامة يبقي السماح قائماً في فحص المسودة.
• يوضع السجل عند _domainkey الخاص بالأب المعني، ولا ترثه مستويات DNS الأخرى. الفشل المؤقت في جلبه يعطي TEMPERROR.

منحتَ المتعهد ملحقاً، فحمل ختم المبنى كله

تفوض شركة mail.example.com إلى جهة ترسل البريد نيابة عنها. تدير تلك الجهة مفتاح توقيع الفرع. في المراجعة 09، يمكن لهذا التوقيع أن يسهم في اعتبار From الظاهر باسم example.com أصيلاً. يشرح واضعو المسودة أنهم يحافظون على عرف قائم في DKIM1 كي لا تتعطل التفويضات القديمة. لم تضم المراجعة 08 سجل السياسة الجديد أو فحص المطابقة الصاعدة.

تضع الفقرة 3.8 حق الرفض بيد الأب. ينشر TXT في _domainkey.example.com يبدأ بـv=DKIM1، وقد يحمل ضمن قائمة f= العلامة strict. عندئذ لا يُسمح للأفرع بجعل From الذي يستخدم example.com أصيلاً. إذا غابت العلامة أو غابت القائمة أو لم يوجد سجل أصلاً، تبقى الأفرع مأذونة في الفحص المقترح. الكلام عن نتيجة «Authentic» في DKIM2 قيد الصياغة، وليس حكماً على رسائل DKIM1 التي وصلت سابقاً.

تبدأ الفقرة 7 بمقارنة نطاق From مع d= في التوقيع المناسب. إن لم يتطابقا، تعكس جهة المقارنة. هذه المحاولة الثانية تصعد من فرع موقّع إلى اسم الأب الظاهر؛ وهنا يوقفها strict المنشور لدى الأب. توقيع الأب نفسه لا يحتاج ذلك الصعود. ولا تمتد سياسة الأب تلقائياً إلى فرع آخر، كما لا تحكم سياسة الفرع اسم الأب.

تفرّق المسودة أيضاً بين حالتي خلل: تعدد سجلات السياسة الصالحة يعطي PERMERROR، وتعذر الجلب مؤقتاً من DNS يعطي TEMPERROR. تحويل أي منهما إلى إذن صامت يهدم وظيفة السجل. تعرض صفحة IETF المراجعة بوصفها مسودة مجموعة عمل في حالة I-D Exists، ولا تقدم المصادر المفحوصة سجلاً لتشغيل متوافق لهذا القفل.