ال SPF تسمح آليات a وmx بالعناوين المكتشفة من خلال DNS . يمكنها تقليل صيانة العنوان يدويًا، ولكنها أيضًا تربط الإذن الصادر بالسجلات المحفوظة لوظائف أخرى. وبالتالي فإن ترحيل موقع الويب أو تغيير البريد الوارد يمكن أن يغير SPF دون أن يقوم أي شخص بتحرير ملف سجل SPF نفسها.
والسؤال الصحيح ليس ما إذا كانت هذه الآليات صالحة أم لا. يتعلق الأمر بما إذا كانت تبعية DNS تعبر عن سياسة الإرسال المقصودة أم لا.
ما يقيم في الواقع
تقوم الآلية بتحليل اسم الهدف المحدد إلى العناوين المناسبة لعائلة اتصال SMTP . يستخدم A لاتصال IPv4 وAAAA لـ IPv6 الأصلي؛ يتم التعامل مع IPv6 المعين بواسطة IPv4 على أنه IPv4 ضمن RFC 7208 §5. على الرغم من اسمه، لا يقتصر على IPv4 . إذا تم حذف الهدف، فسيتم استخدام مجال تقييم نظام التعرف على SPF الحالي.
مع a:mail.example.com، يمكن أن يمر العنوان المطابق ضمن المؤهل الافتراضي +. مع عارية a في example.com ، تصبح عناوين example.com ذات صلة. إذا كان هذا الاسم يشير إلى مضيف موقع ويب أو CDN، فاسأل عن سبب السماح لهذه العناوين بإرسال بريد للهوية التي تم تقييمها. تظهر الدلالات في RFC 7208 القسم 5.3.
ما يقيمه mx فعليًا
تقوم آلية mx باسترداد مضيفي MX للمجال المستهدف ثم عناوينهم. فهو يقارن عنوان IP المتصل بتلك العناوين التي تم حلها. سجلات MX تصف عادةً التوجيه الداخلي، لكن الخوادم الواردة ليست بالضرورة هي نفس الأنظمة التي ترسل البريد الصادر.
لا يستخدم SPF mx احتياطي SMTP الضمني-MX. إذا لم يكن لدى الهدف سجل MX ، فيجب ألا يتعامل نظام التعرف على هوية المرسل SPF مع سجلات A أو AAAA كمضيفي MX احتياطيين. وهذا التمييز واضح في RFC 7208 القسم 5.4.
مثال عملي: تبعيتين، أذونات مختلفة
بافتراض وجود سياسة SPF واحدة صالحة، وإجابات DNS ناجحة، وبادئات المضيف الافتراضية وعدم وجود خطأ سابق في التقييم، فإن هذه السياسة الاصطناعية هي v=spf1 a:out.example.com mx:example.com -all. افترض أن out.example.com يتحول إلى A 192.0.2.40 . MX الخاص بـ example.com هو inbound.example.com ، والذي سجل هو 198.51.100.12 .
اتصال من 192.0.2.40 يطابق أ. الاتصال من 198.51.100.12 يفتقد a، ثم يطابق mx. يفتقد الاتصال من 203.0.113.18 كليهما ويصل إلى الفشل. إذا تغير مضيف MX الوارد، فيمكن أن يتغير الإذن الثاني على الرغم من SPF سجل TXT تظل متطابقة.
بالنسبة لاتصال IPv6 ، قم بفحص إجابات AAAA ذات الصلة بدلاً من إعادة استخدام تتبع IPv4 . إذا كان الهدف غائبًا أو لم يُرجع أي عنوان قابل للتطبيق، فقم بالتمييز بين حالة عدم المطابقة وخطأ DNS ؛ لا تعتبر المهلة دليلاً على أن المضيف المقصود غير مصرح به.
مراجعة أعمال البحث والحدود الثانوية
تساهم كلتا الآليتين في الحد الأقصى لعدد المصطلحات العشرة المسببة لاستعلام DNS عند تقييمها. يحتوي توسيع MX أيضًا على حدود إضافية للاستعلام عن العنوان محددة في RFC 7208 §4.6.4. يمكن أن تفشل السياسة في تحقيق هذه الحدود حتى عندما يبدو العدد السطحي لمصطلحات المستوى الأعلى مقبولاً.
قم بالتقاط مجموعة إجابات MX وعمليات البحث اللاحقة عن العناوين في أدلة الاختبار. لا تعامل العشرة كضمانة بأن كل سجل يحتوي على عشر كلمات مرئية آمن. التبعيات العودية والتوسع و عمليات بحث فارغة بحاجة إلى تقييمهم الخاص.
قرر ما إذا كنت تريد الاحتفاظ بالتبعية
احتفظ بـ أو mx عندما يريد مالك النطاق عمدًا أن يحكم سجل DNS هذا إذن الإرسال وتفهم الفرق التشغيلية عملية الاقتران. ضع في اعتبارك آليات ip4/ip6 الصريحة للخروج المخصص المستقر، أو تضمين مدعوم من الموفر عندما يحتفظ الموفر بالبنية التحتية الصادرة.
قبل إزالة التبعية، حدد العناوين الشرعية التي تطابقها حاليًا. قد يكون mx الذي يبدو غير ضروري هو التفويض الوحيد للمرحل الذي نادرًا ما يستخدم. أنشئ البديل وقارن مجموعات الأذونات وتحقق من الرسائل التمثيلية قبل حذف المصطلح القديم.
الوجبات الجاهزة العملية
تقوم آلية أو mx بتحويل تغيير DNS آخر إلى تغيير إذن SPF . اجعل هذه العلاقة مقصودة ومرئية للمالكين المعنيين ومغطاة بالاختبارات.
سجل القرار وحدوده
احتفظ بصف تبعية لـ out.example.com وآخر لكل مضيف MX : مالك DNS ، وعائلة العنوان، والإجابة الملحوظة، والخدمة الشرعية التي تستخدمه. يجب أن يؤدي ترحيل الموفر الوارد إلى مراجعة صف MX حتى إذا لم يتغير TXT . نتائج العينة تحليلية. يجب أن يتضمن الدليل الحقيقي الطوابع الزمنية للإجابة والأخطاء النهائية بالإضافة إلى المطابقات.