يمكن أن يصبح المجال ذو السمعة الطيبة أو خدمة الإرسال المشتركة جزءًا من مسار رسالة مسيء. والسؤال المفيد ليس ما إذا كانت البنية التحتية جديرة بالثقة بشكل عام. هو ما إذا كانت هذه الرسالة بالذات مخولة باستخدام الهوية الموثقة. المصادقة والترخيص التجاري يجيبان على أسئلة مختلفة.
تحديد السلطة التي سيتم إعادة استخدامها
قد تقوم علبة البريد المخترقة بالإرسال عبر المسار المعتمد العادي الخاص بها. يمكن لترخيص الشبكة الواسع للغاية أن يعترف بمصدر غير مقصود. قد يقوم المرحل بالتوقيع على رسالة بعد قبولها بموجب قاعدة قبول غير محددة بشكل كافٍ. ولهذه الآليات أصحاب وطرق علاج مختلفة. لا تدمجها في ادعاء واحد غير مبرر بسرقة السمعة.
يفحص بحث BreakSPF الأصلي المسموح به SPF التكوينات والبنية التحتية المشتركة. نموذج التهديد الخاص به يجعل الوصول إلى شبكة المصدر شرطًا مركزيًا. وهذه حدود للنشر، وليست دليلاً على أن المهاجم يمكنه تزوير أي منها توقيع DKIM. ورقة BreakSPF، القسم الثالث. تعامل مع قياسات الورقة على أنها بحث تاريخي، وليس جردًا حاليًا للخدمات الضعيفة.
بناء نموذج تهديد دقيق
اكتب المجال المحمي والمعرف المعتمد ومجموعة المصدر المسموح بها وقدرة المهاجم وقرار المتلقي بشكل منفصل. في السيناريو المحدود هنا، يأذن Brand.test 192.0.2.0/24 لـ SPF . يستخدم التطبيق المعتمد 192.0.2.10 ، بينما يمكن للمستأجر الافتراضي غير المقصود أن ينشأ من 192.0.2.99 . يقع كلا العنوانين في النطاق المنشور. ما إذا كان وصول المستأجر هذا موجودًا في خدمة حقيقية يتطلب دليلاً منفصلاً.
يتحقق نظام التعرف على هوية SPF من ترخيص المصدر للتعرف على هويته التي تم تقييمها. ولا يحدد هوية الإنسان الذي يقف وراء عنوان IP مشترك. إذا كانت هوية SPF المارة تتوافق أيضًا مع مجال المؤلف، فيمكن أن يكون هذا المسار مرضيًا DMARC بدون DKIM. RFC 7208 و RFC 9989. وبالتالي، يمكن للتقييم الناجح أن يكشف عن منح قدر كبير جدًا من السلطة، بدلاً من تجاهل المتلقي لقاعدة المرور.
قارن بين ثلاث حالات ترخيص كتابي
افترض أنه مرئي من alerts@brand.test ، غير فارغ البريد من bounce@brand.test ، ولا يوجد توقيع DKIM ، وتقييم DMARC مؤهل. قارن افتراضيا سجلات SPF v=spf1 ip4:192.0.2.0/24 -all and v=spf1 ip4:192.0.2.10/32 -all. No other mechanisms exist in these examples.
- المصدر المعتمد 192.0.2.10 : متضمن بواسطة بادئتي الشبكة؛ يمر نظام التعرف على SPF ويتوافق مع Brand.test، وبالتالي فإن الرسالة التوضيحية تمر عبر DMARC في كلتا الحالتين.
- مصدر غير مقصود 192.0.2.99 : متضمن في /24 ولكن ليس /32؛ يمر SPF فقط تحت السجل الواسع. مع عدم وجود توقيع DKIM ، يتم تمرير نتيجة DMARC المنصوص عليها تحت /24 وتفشل تحت /32.
- المصدر الخارجي 198.51.100.10 : متضمن بدون أي بادئة؛ -all عوائد SPF تفشل في كلتا الحالتين. مع عدم وجود توقيع DKIM ، تفشل نتيجة DMARC المنصوص عليها في كليهما.
هذه مكتوبة البادئة العضوية و تنسيق الخصومات، وليس محلل SPF قيد التشغيل، أو مراقبة DNS أو إعادة إنتاج BreakSPF. يُفترض التحكم في المصدر، ولم يتم إثباته. لم يتم اختبار أي رسالة خارجية أو خدمة مباشرة. تقنية البروتوكولات المتقاطعة الخاصة بالورقة تقع خارج هذا المثال التعليمي.
يمكن لآلية محاذاة تمرير واحدة أن تلبي شرط مرور DMARC للرسالة. هذا لا يجعل نشر نظام التعرف على هوية المرسل (SPF) فقط مناسبًا: يتطلب القسم 7.4 من RFC9989 DKIM صالحًا لنشر المجالات p=reject، ويتناول القسم 8 المشاركة الكاملة. هذه واجبات نشر منفصلة، وليست بوابة مرور إضافية لكل رسالة.
إصلاح الحدود المسؤولة
قبل تضييق نطاق سجل نظام التعرف على SPF الحقيقي، قم بجرد كل مرسل شرعي واتبع التكوين المدعوم من قبل الموفر. لا يكون المصدر المخصص مفيدًا إلا إذا كان حصريًا ويتم صيانته بالفعل. التأكد من أن خدمة الإرسال تلزم العملاء بهوياتهم المسموح بها؛ التحقق من تكوين DKIM وإزالة السلطة القديمة من خلال التحكم في التغيير.
مراقبة حالات الفشل الخاصة بالمسار بعد التغيير، والاحتفاظ بخطة الاسترداد وتوثيق المرسلين غير المعروفين. لا تستبدل سجلاً واسع النطاق بقائمة عناوين IP التي تم تخمينها من هذا المثال. الدرس المستفاد هو التوفيق بين الترخيص والملكية الفعلية للخدمة، وليس نسخ DNS التجريبي إلى الإنتاج.