يمكن أن تحتوي الرسالة على صلاحية توقيع DKIM في حين أن حقول إلغاء الاشتراك الخاصة به غير موقعة. وهذه فجوة ذات معنى: فالمتلقي الذي يتحقق من الرسالة لم يتحقق بالضرورة من إجراء إلغاء الاشتراك المعلن عنه. فحص تغطية التوقيع، وليس فقط عامة DKIM تسمية المرور.
حدد موقع التوقيع الذي يحمي العملية
يتطلب RFC 8058 تغطية توقيع DKIM صالحًا واحدًا على الأقل List-Unsubscribe List-Unsubscribe-Post . يجب أن يظهر كلا الحقلين في علامة h= لهذا التوقيع الصالح. يعد التوقيع المطلوب المفقود سببًا لعدم قيام المتلقي بتقديم إلغاء الاشتراك بنقرة واحدة بموجب المواصفات. RFC 8058 القسم 4.
قد تحمل الرسالة توقيعات متعددة. لا تجمع بين صلاحية أحدهما وتغطية رأس الآخر واستدعاء الزوج كافيًا. تحديد توقيع واحد صالح يغطي الحقول المطلوبة، ثم الاحتفاظ بالموقع الخاص به، محدد ونتيجة التحقق. وهذا منفصل عن التحقق من التوقيع الذي يساهم فيه DMARC تنسيق.
ضع الرؤوس قبل خطوة التوقيع ذات الصلة
قم بتعيين مسار بناء الرسالة: قالب التطبيق، ومعالجة القائمة، وتحويلات البوابة، والمُوقع، والمسار النهائي للخارج. إذا قامت إحدى الخدمات بإضافة حقول إلغاء الاشتراك بعد التوقيع، فقد يظل التوقيع السابق صالحًا دون تغطيتها. الحل هو وضع الحقول قبل التوقيع المناسب أو التأكد من أن التوقيع الصالح لاحقًا يغطيها.
اقرأ الرسالة المرسلة النهائية. يحدد RFC 6376 قواعد اختيار القائمة والرأس h=، بما في ذلك كيفية التعامل مع أسماء الحقول المتكررة. إن البحث عن سلسلة عن "إلغاء الاشتراك في القائمة" في أي مكان في الرسالة لا يعد اختبارًا للتغطية. تتطلب الحقول والتحويلات المكررة فحصًا دقيقًا لإدخال التوقيع الفعلي. RFC 6376 الأقسام 3.5 و5.4.
التمييز بين التغييرات الموقعة وغير الموقعة
تخيل رسالة اختبارية خاضعة للرقابة يغطي توقيعها الصحيح كلا حقلي إلغاء الاشتراك. يؤدي تغيير عنوان URI الموقع إلى قيمة مختلفة إلى تغيير الإدخال الموقع؛ وفي ظل التحقق العادي DKIM ، لم يعد التوقيع الأصلي يتحقق من صحة هذا الإدخال الذي تم تغييره. وعلى النقيض من ذلك، يمكن أن يظل التوقيع الذي يحذف كلا الحقلين صالحًا بعد تغيير تلك القيم غير الموقعة. وهذا ما يفسر سبب عدم قدرة المرور العام على مصادقة كل حقل.
هذه توقعات قائمة على البروتوكول، وليست تجهيزات تشفير يتم تنفيذها. يحتاج اختبار الطفرة المعتمد الفعلي إلى وحدات البايت الأصلية الدقيقة والتوقيع المحدد ومفتاح التحقق الصحيح. يوضح مفتاح الاختبار الذي تم إدخاله فقط علاقة التشفير الخاصة بهذا الاختبار، وليس مصدر DNS العام أو نتيجة الاستلام التاريخية. الحفاظ على الأصل وتحوير نسخة منفصلة.
تحقق من المسار الموقع بالكامل
بعد إصلاح التغطية، قم بإعادة إرسال رسالة اختبار معتمدة عبر المسار المقصود وتحقق من الجانب المتلقي. يمكن لإعادة كتابة الارتباط أو عمليات تحرير البوابة أو معالج القائمة الأحدث تغيير الحقل المغطى. احتفظ بعينات ما قبل التحويل والعينات النهائية عندما يكون ذلك ممكنًا حتى يتمكن المالك من تحديد المرحلة الأولى التي يتباعد فيها التحقق.
تجنب حل المشكلة بمجرد إزالة الحقول من h=. يمكن أن يؤدي ذلك إلى تسهيل الحفاظ على التوقيع مع ترك متطلبات RFC 8058 غير مستوفاة. إذا كان يجب على البوابة تحويل الإجراء، فقم بتنسيق حدود التوقيع النهائية وتأكد من أن URI المحول لا يزال يعيّن المستلم والقائمة الصحيحة.
أكمل الفحص التشغيلي
تغطية التوقيع تصادق على الحقول المعلن عنها؛ ولا يثبت أن نقطة النهاية تنفذ المنع المطلوب. استخدم اشتراكًا متحكمًا فيه لاختبار POST واستبعاد الإرسال التالي بشكل منفصل. وعلى العكس من ذلك، لا تقوم نقطة النهاية العاملة بإصلاح تغطية التوقيع المفقودة.
يجب أن يحدد سجل الإغلاق توقيع التغطية الصالح والرسالة النهائية الدقيقة ونطاق نقطة النهاية ونتيجة المنع الملحوظة. احتفظ بعرض واجهة مستخدم الموفر كملاحظة منفصلة بدلاً من النتيجة الموعودة للتوقيع الصحيح.
الاحتفاظ بسجل إغلاق خاص بالتوقيع
قم بتسجيل الرسالة النهائية، والموقع، والمحدد، والحقول المغطاة، ونتائج التحقق لهذا التوقيع المحدد. تسجيل نتائج نقطة النهاية والقمع بشكل منفصل. إذا قامت بوابة لاحقة بتغيير الحقول، فقم بإصلاح حدود التوقيع بدلاً من إسقاط التغطية المطلوبة.