تقييد التعليمات بتوقيع بوابة SpamTitan
تنشر TitanHQ تكوينًا محددًا DKIM في إجراء بوابة SpamTitan. تتبع هذه المقالة حدود المنتج تلك. لا يفترض أن SpamTitan Cloud، أو Skellig، أو النشر الوارد فقط، أو كل إصدار خدمة مُدارة يعرض نفس عناصر التحكم. تأكد من الإصدار المثبت والإمكانيات المرخصة والمسار الصادر الفعلي قبل الموافقة على تغيير التوقيع. لا يعد المجال المدرج لتلقي البريد، في حد ذاته، دليلاً على أن الرسائل الصادرة تعبر البوابة أو تتلقى توقيع مجال العميل.
ال إجراءات البوابة يحتوي على خطوات توقيع DKIM ومناقشة منفصلة لسجل سياسة DomainKeys القديمة. هذا الخليط هو حدود التنفيذ الهامة. يمكن شرح سير عمل مفتاح التوقيع الحديث من المصدر، لكن خطوة السياسة القديمة تتطلب تأكيد المنتج الحالي. لا تقم بتحويل مصطلحات DomainKeys القديمة بصمت إلى ملف DMARC شرط أو ادعاء بأن نشر سياسة o= ينشئ حماية حديثة للمجال.
تحديد ترحيل المجال وملكية المفتاح
التنقل الموثق هو إعداد النظام، وترحيل البريد، DKIM . تسرد الصفحة مرحلات المجال. قم بتحرير المجال المقصود وافتح علامة التبويب DOMAIN KEY. الإجراء يطلب أ محدد الاسم الذي يميز هذا المفتاح عن مفاتيح المجال الأخرى. اختر تصنيفًا من خلال عملية التسمية المعتمدة للمؤسسة وتحقق من الاستخدام الحالي قبل نشره. التسمية التي يمكن التنبؤ بها ليست سرا، ولكن إعادة استخدام محدد مشغول يمكن أن يحل محل التبعية التي لا يزال مرسل آخر بحاجة إليها.
يصف المصدر إنشاء زوج مفاتيح جديد ويقدم أيضًا حقل مفتاح خاص موجود. لا يطلب هذا الدليل أو يجمع أو يوصي بنسخ مفتاح خاص في تذكرة أو مستند مشترك. يعد إنشاء المفتاح أو استيراده إجراءً إداريًا معتمدًا منفصلاً. يسرد الدليل 1024 بت و 2048 بت الخيارات ويوصي بالاختيار الأطول. تأكيد التكوين المدعوم ومتطلبات التشفير الحالية للمنتج المنشور؛ لا تقم بالرجوع إلى الإصدار السابق لمجرد أن محرر DNS يعرض قيمة عامة طويلة بشكل غير ملائم.
انشر المفتاح العام الذي تم إنشاؤه دون نسخ المثال
بعد الإنشاء، يقوم المصدر بتوجيه المسؤول إلى علامة التبويب OPTIONS ومواد DNS TXT . انشر المفتاح العام الفعلي بالاسم المتكون من المحدد المحدد _domainkey ومجال التوقيع. المفتاح العام الكبير المطبوع في الوثائق هو عبارة عن رسم توضيحي، وليس سجلاً قابلاً لإعادة الاستخدام. قم بتسجيل المالك المختار وإشارة مضبوطة إلى القيمة العامة الصادرة في طلب التغيير. لا توجد مواد خاصة تنتمي إلى DNS العام.
يناقش TitanHQ إزالة التنسيق الدخيل من شاشة العرض المنسوخة. قم بتفسير ذلك على أنه التعامل مع العرض التقديمي للمحرر، وليس التحرير التعسفي لوحدات البايت الرئيسية. RFC 6376 ، القسم 3.6.2.2 يحدد سجلات موارد TXT لتخزين المفاتيح. قد تعرض أداة DNS عدة سلاسل مقتبسة ضمن سلسلة واحدة سجل TXT; يختلف عن السجلات المتنافسة المتعددة أو علامات الاقتباس الحرفية المدرجة في القيمة. اطلب من مسؤول DNS التحقق من السجل المنطقي الفعلي واسم المالك الكامل بدلاً من قبول لقطة شاشة لمربع الإدخال كدليل نهائي.
احتفظ بالسياسة القديمة ووضع الاختبار منفصلين عن DMARC
يصف إجراء الموفر أيضًا سجل TXT في _domainkey متبوعًا بالمجال، بقيم o=- أو o=~ ، ضمن سجلات السياسة. فإنه يستدعي هذا النهج DomainKeys بشكل صريح. هذا ليس موقع سياسة DMARC ولا يعد بديلاً للمفتاح العام لمحدد DKIM . نظرًا لأن الإجراء يجمع بين هذه العناصر التاريخية، تأكد مما إذا كانت خطوة السياسة هذه قابلة للتطبيق على إصدار البوابة الحالي بالضبط قبل إضافتها. احتفظ بالسؤال الذي لم يتم حله في سجل الإصدار بدلاً من اختراع متطلب حديث.
يصف الدليل بشكل منفصل علامة اختبار DKIM ، t=y, في السجل الرئيسي. لا تخلط بين ذلك وبين تعليمات وضع نشر DMARC في وضع الاختبار أو مع إثبات أن المستلمين سيقبلون كل البريد. DKIM و DMARC ومعالجة جهاز الاستقبال المحلي لها دلالات مميزة. RFC 9989 ، القسم 4.4 يشرح تنسيق مطلوب بين هوية المصادقة المارة ومجال المؤلف. إن بيان السياسة القديم الذي ينص على توقيع البريد لا يثبت صحة توقيع معين أو محاذاته.
تحقق قبل التمكين وخطط للتناوب بشكل متعمد
يستخدم سير عمل OPTIONS الخاص بـ TitanHQ ميزة التحقق لاسترداد سجل DNS TXT ومقارنته بالمعلومات التي تم تكوينها للبوابة. بمجرد نجاح عملية التحقق، يؤدي تمكين إلى تنشيط توقيع DKIM للنطاق. التعامل مع هذه كنقاط تفتيش منفصلة. لا يثبت المفتاح المنشور تمكين التوقيع، في حين أن خيار التوقيع المحدد لا يمكن أن يؤدي إلى التحقق من صحة السجل العام المفقود أو غير المتطابق. الحفاظ على نتيجة التحقق ووقتها دون وصفها بأنها اختبار قبول المتلقي.
توصي الوثائق بالتناوب الدوري للمفاتيح. تحتاج خطة التناوب العملية إلى أكثر من مجرد فاصل زمني للتقويم: تحديد المحددات النشطة، والمفاتيح التي تم إنشاؤها، والرسائل الموضوعة في قائمة الانتظار، والتخزين المؤقت DNS ، والمشغلين المعتمدين، وشروط التراجع. لا تقم بحذف السجل العام السابق لمجرد إنشاء مفتاح بديل. تحديد ما يتداخل مع احتياجات مسار البريد الفعلي، والاحتفاظ بالأدلة الداعمة لهذا القرار. لم تقم هذه المخطوطة بقياس عمر قائمة الانتظار أو اختبار سلوك انتقال المنتج المثبت، لذا تظل تفاصيل التنفيذ مفتوحة.
تحقق من الرسالة الصادرة النهائية بدلاً من تسمية التصفية
وينبغي لعملية القبول المعتمدة بشكل منفصل أن تميز عبور البوابة والتوقيع والتحقق من الصحة والمواءمة. راجع حقلي التوقيع d= وs= ومجال المؤلف المرئي ونتائج مصادقة المتلقي الموثوق. RFC 6376 ، القسم 3.5 يحدد حقول التوقيع. تحقق من فئات الرسائل التي قد تتخذ مسارات مختلفة، مثل بريد صندوق البريد العادي وإشعارات التطبيقات وحركة المرور المعاد توجيهها. حقيقة أن الرسالة الواردة قد تم فحصها بواسطة SpamTitan لا تقول شيئًا قاطعًا حول كيفية توقيع رسالة التطبيق الصادرة.
SPF هي مراجعة منفصلة. RFC 7208 ، الأقسام 2.4 و4.6.4 وصف لها البريد من الهوية وحدود التقييم المعتمدة على DNS. لا يوفر هذا المصدر تضمين نظام التعرف على هوية المرسل SPF الصادر عالميًا لكل عملية نشر لـ SpamTitan، لذلك لم يتم اختراع أي منها هنا. احصل على البنية التحتية الفعلية للإرسال المعتمد وراجع سياسة واحدة كاملة لتلك الهوية. يظل نجاح المصادقة مختلفًا عن وضع البريد الوارد أو أمان المحتوى أو موافقة المستلم على طلب الدفع.
التشخيص الخيالي وورقة عمل القبول الفارغة
تنشر شركة هندسية خيالية، Alder Instruments، مفتاح محدد جديدًا ولكنها تترك التوقيع معطلاً أثناء انتظار نافذة الصيانة. تشير قائمة التحقق الداخلية الخاصة بها إلى اكتمال DKIM نظرًا لنجاح عملية التحقق. وجدت مراجعة لاحقة أن قائمة التحقق تخلط بين اتفاقية DNS والتوقيع النشط. يتمثل التصحيح المقترح في فصل الموافقة على التمكين وحالة التكوين المرصودة وأدلة المتلقي المستقبلية. ليس المقصود نشر مفتاح مثال التوثيق أو إضافة سجل سياسة قديم كبديل. لا يوجد نظام فعلي أو رسالة أو بحث DNS وراء هذا السيناريو.
- منتج البوابة وإصدارها ومسارها الصادر وترحيل المجال: ______
- ملكية المحدد والتبعيات الموجودة: ______
- مرجع القيمة/المالك العام الذي تم إنشاؤه وتغيير DNS المعتمد: ______
- قرار حفظ المفتاح الخاص، بدون مواد سرية: ______
- قرار تطبيق سياسة DomainKeys القديمة: ______
- التحقق من النتيجة والموافقة اللاحقة/الحالة: ______
- تداخل التدوير والتراجع والاحتفاظ بالمحدد السابق: ______
- توقيع الرسالة المستلمة الموثوق بها وأدلة المحاذاة: ______
- الاستثناءات المتبقية والمراجع ومالك الإصدار: ______
تظل أدلة التنفيذ الأصلية، وقابلية تطبيق المصدر الحالي، ومراجعة الموضوع البشري، وقبول مسار الإنتاج، وإمكانية الوصول المرئي، وإصدار المالك مفتوحة. لم يتم إنشاء أي مفتاح أو تغيير الإعداد أو نشر سجل DNS أو إرسال رسالة. لا يمكن وضع علامة على متطلبات التنفيذ الأوسع للكتالوج على أنها مكتملة من سير العمل المستندي هذا وحده.