[ SPF ]

سجلات SPF المتعددة: دمج الأذونات دون الاحتفاظ بالمرسلين القدامى

استبدل سجلات SPF المنافسة بسياسة واحدة تمت مراجعتها، مع الحفاظ على المرسلين الشرعيين مع إزالة الأذونات القديمة أو العامة.

بواسطة فريق البحث EmailAuth

[النقاط الرئيسية]

  • لا يتم دمج السجلات المحددة المتعددة بواسطة أجهزة الاستقبال.
  • الحفاظ فقط على الأذونات المبررة والأمر المتعمد.
  • التحقق من DNS والمسارات التمثيلية دون اختراع النتائج.
في هذه الصفحة

اثنين SPF لا يتم دمج السياسات التي تحمل نفس اسم DNS في قائمة أكبر للمرسلين المعتمدين. متى سجل SPF يؤدي التحديد إلى إرجاع أكثر من سجل قابل للتطبيق، وينتهي التقييم بـ permerror تحت RFC 7208 §4.5. الإصلاح عبارة عن سياسة واحدة متماسكة، وليس إدخال TXT ثالثًا.

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

تأكيد ما هو مكرر فعلا

استفسار سجلات TXT في المجال المحدد المستخدم لفحص نظام التعرف على SPF . سجلات TXT الأخرى، مثل الرموز المميزة للتحقق من النطاق، ليست سجلات نظام التعرف على SPF تلقائيًا ويجب عدم حذفها كجزء من هذا الإصلاح. التمييز بين سجلات الموارد المتعددة وسلاسل الأحرف المتعددة المقتبسة ضمن سجل TXT واحد. تحت RFC 7208 §3.3، السلاسل الموجودة داخل سجل واحد متسلسلة؛ سجلات SPF منفصلة ليست كذلك.

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

إعادة بناء مجموعة المرسل المقصودة

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

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

بناء سياسة واحدة مرتبة

الحفاظ على التراخيص المختارة وسياسة نهائية واحدة مقصودة. لا تقم بتسلسل السجلات بأكملها، وترك ثانية v=spf1 رمز أو الجميع آلية في الوسط. تحت RFC 7208 §5.1، في وقت مبكر الجميع يطابق كل المصدر المتبقي، لذلك لا يمكن الوصول إلى الآليات اللاحقة.

حالة البداية التوضيحية: سجل واحد هو v=spf1 ip4:192.0.2.10 -all; آخر هو v=spf1 ip4:198.51.100.20 ~all. إذا كان كلا عنواني التوثيق فقط يمثلان المرسلين الحاليين المؤكدين، فإن السياسة المدمجة المحتملة تكون كذلك v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 ~all. يتطلب اختيار المؤهل النهائي مراجعة التوجيه الخاصة به. إذا تم تقاعد المرسل الثاني، فإن دمجه سيحافظ على السلطة غير الضرورية.

قم بتقييم السياسة الكاملة، بما في ذلك عمليات التضمين وعمليات إعادة التوجيه المتداخلة. تحت RFC 7208 §4.6.4، يفرض RFC 7208 حدًا يبلغ عشرة مصطلحات تسبب البحث أثناء التقييم؛ حساب عبارات التضمين المرئية فقط غير كافٍ. صريح IP4 و IP6 الآليات نفسها لا تستهلك ميزانية هذا المصطلح، ولكن استبدال التضمينات المُدارة بقوائم IP المنسوخة ينشئ التزامًا بالصيانة.

نشر دون حالة غامضة لفترة طويلة

تفضيل تحديث مجموعة سجلات DNS الذرية عندما يدعمها الموفر: استبدل السياسات المنافسة بالسجل الفردي المعتمد في تغيير واحد. إذا كانت الواجهة تتطلب تعديلات منفصلة، ​​فخطط للتسلسل واعترف بالمخاطر العابرة المتمثلة في فقدان السياسة أو تكرارها. لا تقم بإنشاء سجل SPF إضافي "مؤقت" واتركه للنشر.

تحقق من الإجابات الموثوقة، ثم الإجابات العودية ذات الصلة. تحتفظ الإجابات القديمة المخزنة مؤقتًا بفترات الحداثة السابقة؛ RFC 8767 §4 يسمح أيضًا باستخدام الإجابات القديمة المؤهلة بعد انتهاء الصلاحية. TTL ليس موعدًا نهائيًا مضمونًا للإلغاء العالمي. أرسل رسائل تمثيلية من كل خدمة تم الاحتفاظ بها وقم بتأكيد الهوية التي تم تقييمها والنتيجة لدى مستلم موثوق به. اختبر مصدرًا لا مثيل له تحت سيطرتك أيضًا، لذلك لا يمكن الخلط بين التمريرة العامة العرضية على أنها نجاح.

احتفظ بأدلة التنظيف

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

سجل القرار وحدوده

بالنسبة لمثال العنوانين، يجب أن تحتفظ ورقة عمل الإذن بكل قرار للمالك والمطابقة المتوقعة بشكل منفصل عن المؤهل النهائي. لا يزال المثال المدمج ~all يُرجع softfail لعنوان غير متطابق؛ إنها ليست توصية لإضعاف سياسة -all . تغيير هذا المؤهل يحتاج إلى قرار واضح. لم يتم إجراء أي تحديث DNS أو اختبار التسليم لهذا الرسم التوضيحي.

[ الوجبات الجاهزة ]

لا يتم دمج السجلات المحددة المتعددة بواسطة أجهزة الاستقبال. الحفاظ فقط على الأذونات المبررة والأمر المتعمد. التحقق من DNS والمسارات التمثيلية دون اختراع النتائج.

[ حسب الدور ]

ماذا يعني هذا بالنسبة لك

اختر دورك للخطوات العملية التالية.

تكنولوجيا المعلومات / مدير البريد

دمج الدلالات، وليس السلاسل.

يجب أن يستمر ترتيب السجل والمؤهلات والتبعيات العودية بعد عملية الدمج بشكل صحيح.

الخطوات التالية

  1. حفظ مجموعة السجلات الأصلية.
  2. اختبر كل خدمة محتجزة ومصدرًا لا مثيل له.

كبير مسؤولي أمن المعلومات / SecOps

مراجعة الثقة المحتفظ بها.

كل إضافة أو شبكة محفوظة هي قرار ترخيص.

الخطوات التالية

  1. تتطلب ملكية كل آلية.
  2. سجل لماذا لم يعد المرسلون الذين تمت إزالتهم بحاجة إلى الوصول.

المؤسس / غير التقنية

استخدم الحادث لتنظيف الملكية.

يجب أن يحدد الإصلاح خدمات الأعمال التي لا تزال تتمتع بالإذن، وليس مجرد إسكات المدقق.

الخطوات التالية

  1. الموافقة على تقاعد الخدمة مع المالكين.
  2. قم بتضمين المهام المرسلة بشكل متكرر في التحقق من الصحة.

[ الأسئلة الشائعة ]

الأسئلة المتداولة

هل يمكنني نشر سجل SPF منفصل لكل بائع؟

وليس بنفس اسم المالك تنتج سجلات SPF المتعددة المحددة permerror بدلاً من الأذونات المدمجة.

RFC 7208 §4.5

هل يجب أن أحذف كل سجل TXT آخر؟

لا، يمكن أن تظل سجلات التحقق غير ذات الصلة. تحديد سجلات SPF باستخدام قواعد اختيار البروتوكول.

RFC 7208 §4.5

هل هناك سلسلتان مقتبستان عبارة عن سجلين SPF ؟

ليس عندما تكون عبارة عن سلاسل أحرف داخل سجل مورد TXT واحد. محتوياتها متسلسلة بدون مسافات مدرجة.

RFC 7208 §3.3

هل يمكنني لصق كلا السياستين الكاملتين معًا؟

لا، احتفظ بعلامة إصدار واحدة، وقم بمراجعة ترتيب الآلية واختيار سياسة نهائية فعالة.

RFC 7208 §4.6 RFC 7208 §5.1

لماذا لا تحتفظ بكل ما هو قديم؟

فهو يحافظ على ترخيص البائع ويستهلك موارد التقييم حتى في حالة عدم الحاجة إلى الخدمة.

هل عشرة تضمينات مرئية تضمن الامتثال؟

لا، فالتقييم المتداخل والمصطلحات الأخرى المسببة للبحث يتم احتسابها أيضًا ضمن الحد الأقصى.

RFC 7208 §4.6.4

متى يتم التحقق من الإصلاح؟

بعد أن يقدم DNS سياسة واحدة قابلة للتطبيق ويتم تقييم الرسائل التمثيلية من المرسلين المحتفظ بهم كما هو متوقع.

ماذا لو لم يتمكن محرر DNS من التحديث ذريًا؟

قم بتخطيط وتوثيق الحالة المؤقتة، وتقليل الفاصل الزمني بين عمليات التحرير والتحقق من مجموعة السجلات الناتجة على الفور.

[ مصادر ]

مصادر

  1. RFC 7208

    الأقسام §2.4 · §3.3 · §4.5 · §4.6 · §4.6.4 · §5.1 · §4.1

  2. RFC 8767

    الأقسام §4

[ مسرد ]

مسرد

SPF
تقييم عنوان IP المتصل مقابل سياسة هوية SMTP ذات الصلة.

RFC 7208 §2.4

DNS TTL
فترة الحداثة العادية، وليست موعدًا نهائيًا مضمونًا للحذف أو الإلغاء؛ قد يستمر الاستخدام المؤهل للخدمة القديمة بعد انتهاء الصلاحية.

RFC 8767 §4

مصدر المؤسسة

لماذا كبار المؤسسات المالية والحكومات تقاعدوا من لوحات معلومات أمان البريد الإلكتروني الخاصة بهم.

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

EmailAuth هي منصة مصدر البريد الإلكتروني الوكيل. وكلاؤنا ينفذون p=reject، حافظ على محاذاة المرسلين الخارجيين وانقل نطاقاتك إلى كاملها RFC 9989 الامتثال، وهو معيار DMARC الجديد، مع إمكانية التدقيق البشري في الحلقة.

الحكومات المؤسسات الكبيرة المؤسسات المالية من المستوى الأول

SaaS · إيجار مخصص · Air-gapped محليًا · تشفير BYOK

قاعدة المعرفة