تغيير ~all ل -all يقوي البيان الذي يقدمه النطاق حول عنوان IP للإرسال لا مثيل له. ولا يحول مالك المجال إلى عامل تصفية بريد المستلم. يبدأ القرار المفيد بسؤالين: ما هي الاتصالات المشروعة التي تظل غير متطابقة، وماذا يحدث لتلك الرسائل في أنظمة الاستقبال المهمة؟
اقرأ النتيجة قبل الحكم على التسليم
SPF يتحقق مما إذا كان المضيف المتصل قد يستخدم هوية SMTP التي تم تقييمها. آلية إيجابية مطابقة تنتج تمريرة. إذا وصل التقييم ~allفإنه ينتج softfail ، وهو بيان مؤهل بأن المضيف ربما يكون غير مصرح به. الوصول -all ينتج فشل، بيان واضح بأنه غير مصرح به. "الفشل" هو اختصار شائع. تتم تسمية نتيجة البروتوكول يفشل.
RFC 7208 §8.4 و RFC 7208 §8.5 افصل هذا البيان عن التعامل معه. التخلص من الفشل هو السياسة المحلية لجهاز الاستقبال. بالنسبة softfail ، توصي RFC بعدم الرفض بناءً على تلك النتيجة فقط، مع السماح بإجراء تدقيق أكثر دقة. لا يعد أي من المؤهلين بوضع صندوق بريد وارد أو مجلد بريد عشوائي أو رفض SMTP عالمي. قد يرفض جهاز الاستقبال لأسباب غير ذات صلة حتى عندما يمر SPF .
يتم تقييم الآليات بالترتيب تحت RFC 7208 §4.6.2. لا يؤدي تغيير المؤهل الأخير إلى أي شيء بالنسبة للرسالة التي تتطابق بالفعل مع آلية إيجابية سابقة. واسعة للغاية IP4 يظل النطاق أو الخدمة واسعة جدًا بعد الإضافة -all.
فصل المرسلين المفقودين عن التسليم غير المباشر
أنشئ قائمة بخدمات إرسال SMTP الفعلية ومجالات المغلفات الخاصة بها وملاحظات المتلقي التمثيلية. يمكن لصندوق بريد الموظف وتطبيق الفوترة ومنصة التسويق استخدام نطاقات مغلفات مختلفة حتى عندما يبدو عنوان "من" المرئي متطابقًا. قم بتشخيص النطاق الموضح في نتيجة نظام التعرف على هوية المرسل SPF الخاص بالمستلم الموثوق به، وليس النطاق الذي يظهر على الشاشة فقط.
يؤدي إعادة التوجيه إلى تغيير عنوان IP المتصل. إذا تم الاحتفاظ بهوية المغلف الأصلية، فيمكن للمستلم النهائي رؤية رسالة شرعية من مضيف لم يأذن به المجال الأصلي. لا تعد إضافة كل معيد توجيه إلى سياسة نظام التعرف على هوية المرسل SPF الخاص بالمرسل الأصلي إصلاحًا قابلاً للتوسع وقد يسمح ببنية تحتية خارجة عن سيطرتك. تحقق من تصميم إعادة التوجيه وأدلة المصادقة الأخرى للرسالة. لا تقم بتصنيف كل فشل تم إعادة توجيهه كخدمة صادرة منسية. RFC 7208 §10.3 يناقش هذه الصعوبة المعمارية.
العمل من خلال مثال خاضع للرقابة
مثال توضيحي، باستخدام عناوين التوثيق فقط: v=spf1 ip4:192.0.2.10 ~all يسمح بالاتصال المباشر من 192.0.2.10 . يصل الاتصال من 198.51.100.20 إلى softfail . استبدال ~all مع -all يغير النتيجة الأخيرة إلى الفشل لكنه يترك النتيجة الأولى كمرور.
لنفترض الآن أن 198.51.100.20 يعيد توجيه البريد الذي تم إرساله في الأصل بواسطة 192.0.2.10 ويحتفظ بهوية المغلف الخاصة به. تتبع نتيجة SPF عند جهاز الاستقبال النهائي اتصال إعادة التوجيه، وليس الخطوة الأولى. وهذا سيناريو اختبار متوقع، وليس دليلاً على توقف الخدمة الأصلية عن الإرسال بشكل صحيح.
اتخاذ قرار سياسي قابل للعكس
قبل تغيير المؤهل، احتفظ بالمؤهل الموجود سجل TXT وTTL، والتحقق من ملكية المرسل، والاتفاق على الأدلة التي قد تؤدي إلى الاستعادة. اختبار المسارات المباشرة الحرجة والمسارات غير المباشرة المعروفة بشكل منفصل. قم بتسجيل عنوان IP المصدر والمجال الذي تم تقييمه ونتيجة نظام التعرف على هوية SPF ونتيجة التسليم النهائية لكل اختبار. قم بتضمين مصدر اختبار لا مثيل له تحت سيطرتك حتى يكون التأثير الفعلي للتغيير مرئيًا.
بعد النشر، تحقق من DNS الموثوق والإجابات المتكررة ذات الصلة، مما يسمح بالبيانات المخزنة مؤقتًا. التحقيق في حالات الفشل بدلاً من الرجوع ببساطة في كل مرة تتم فيها تصفية الرسالة. يحتاج المصدر المعتمد المفقود إلى تصحيح المخزون؛ تحتاج مشكلة إعادة التوجيه إلى قرار مدرك للمسار؛ لن يتم إصلاح رفض السمعة غير ذي الصلة عن طريق تغيير المؤهل النهائي.
أغلق بسجل يمكن الدفاع عنه
احتفظ بسبب المؤهل المختار بجانب مخزون المرسل الحالي. قم بمراجعتها عند تغيير الخدمات أو طرق التسليم. تكون الآلية النهائية المقيدة مفيدة فقط عندما تصف التفويضات السابقة حدود الإرسال الحقيقية للنطاق. يكتمل القرار عندما يتمكن المالك من شرح تغطية البريد المباشر ومقايضات البريد غير المباشر.
استخدم الأدلة لاتخاذ القرار
في السجل الاصطناعي، يظل 192.0.2.10 يمر بعد تغيير المؤهل؛ ينتقل 198.51.100.20 من softfail إلى الفشل فقط عند الوصول إلى الآلية النهائية. سجل التعامل مع جهاز الاستقبال بشكل منفصل. إذا كان عنوان IP الثاني عبارة عن معيد توجيه يحتفظ بالمغلف الأصلي، فتحقق من المسار غير المباشر قبل معاملته كمرسل معتمد مفقود. لم يتم تنفيذ أي تسليم مباشر أو تغيير في المؤهل.