غالبًا ما يبدأ مخزون البريد الإلكتروني الخاص بشركة برمجيات بمنصة التسويق الخاصة بها وينتهي مبكرًا جدًا. يمكن أن يعتمد الوصول بدون كلمة مرور وردود الدعم والفواتير وتحديثات الحالة على البائعين المنفصلين وبيانات الاعتماد والمجالات. كما أنها تفشل في لحظات مختلفة. تعد حالة البريد الإلكتروني التي تعتمد على نفس التطبيق غير المتاح الذي من المفترض أن تصفه مشكلة تبعية تشغيلية حتى عندما تكون DKIM التكوين صحيح.
خريطة الخدمة خلف المرسل
أنشئ صفوفًا لأحداث المنتج ومحادثات الدعم وإشعارات الفوترة وصفحة الحالة. لكل منها، قم بتسجيل المالك، ومستأجر البائع، والمشغل، ومن المجال، وهوية المغلف، ومجال DKIM و محددومعالجة الرد واسترداد جهة الاتصال. تتبع التطبيق أو الشخص الذي يمكنه بدء الإرسال. حدد التبعيات على قاعدة بيانات الإنتاج وموفر الهوية ومخزن الأسرار وخط أنابيب النشر، ثم حدد ما هو المقبول للاتصالات الطارئة.
لا توافق على عنوان IP لأنه ينتمي إلى موفر سحابي مألوف. لا تثبت البنية الأساسية المشتركة أن مستأجر الشركة هو من أرسل الرسالة. قم بتوصيل الملاحظة بحساب معتمد وتكوين المجال المدعوم والمالك المسؤول. احتفظ بحركة المرور غير المؤكدة على أنها لم يتم حلها حتى تدعم الأدلة الإسناد.
تعريف القبول حسب سير العمل
يجب أن يبدأ اختبار حدث المنتج داخل المنتج، واختبار الدعم داخل نظام الدعم، واختبار الفوترة داخل صندوق الحماية المعتمد الخاص به. للحصول على تحديثات الحالة، قم بمراجعة ناشر الحادث المعين وتحقق مما إذا كان هذا الشخص يمكنه العمل أثناء فشل الخدمة الأساسية. قم بتأكيد مسار الرد المقصود حتى لا يجيب العملاء على عنوان غير مراقب بشكل غير متوقع.
RFC 9989 يدعم تقييم استخدام النطاق المتوافق، وليس مدى توفر التطبيق أو صحة الفاتورة. يمكن التحقق من التوقيع من المجال الخاص بالبائع أثناء الفشل في تحقيق الهدف تنسيق علاقة. ولذلك، يجب أن تصاحب نتائج المصادقة اختبار قبول سير العمل، بدلاً من أن تحل محله.
لا تدع بريد المنتج يخفي مسار الحالة
لنفترض أن مسارات المنتج والدعم والفوترة تستخدم نطاقات DKIM d= المطابقة لمجالات "من" الخاصة بها، في حين أن status.software.example هو المجال "من" لإشعار الحالة و provider.example.net هو الموقّع عليه. حتى مع افتراض وجود تشفير صالح، فإن الأخير يفشل في محاذاة DKIM الصارمة. تأكد من تكوين الهوية المدعومة لموفر الحالة بدلاً من تغيير بريد الفواتير غير ذي الصلة. هذه الهويات افتراضية، ولم يتم توفير عينات موقعة أو نتائج التحقق الفعلية.
محاذاة التوقيع الواحد ليست كاملة DMARC الحكم: تقييم التوقيعات المحاذاة الصالحة الأخرى و SPF حسب الاقتضاء بموجب RFC 9989 الأقسام 4.4 و5.3.5. ل p=reject النشر، يتطلب القسمان 7.4 و8 DKIM صالحًا بدلاً من الاعتماد فقط على نظام التعرف على SPF . لا يثبت نجاح التوقيع أو المحاذاة أن ناشر الحالة يمكنه العمل أثناء انقطاع الخدمة. لم يتم إجراء أي منصة حية أو اختبار التشفير.
اختبر تبعية الحادث، وليس DNS فقط
قم بإجراء تمرين معتمد حيث يكون مشغل المنتج العادي غير متاح ويتبع ناشر حادث النسخ الاحتياطي المسار الموثق. لا تقم بمقاطعة الإنتاج عمدًا لمجرد اختبار هذا الدليل. قم بتسجيل بيانات الاعتماد والحسابات والأنظمة الضرورية، وما إذا كان المستلم الخاضع للرقابة قد تلقى التحديث وما أبلغت به حدود الاستلام. إذا كان الإجراء الاحتياطي يتطلب موفر هوية غير متاح، فقم بتسجيل هذا القيد وأعد التصميم مع مالك الأمان بدلاً من ارتجال كلمة مرور مشتركة.
لتوقيع التغييرات، اتبع تعليمات البائع الحالية واحتفظ بأدلة التراجع. قم بإزالة التراخيص القديمة فقط بعد التأكد من عدم استخدام أي منتج أو دعم أو سير عمل الفوترة المحتفظ بها. يمكن أن تختفي الإيصالات ذات الحجم المنخفض ورسائل الحوادث غير المتكررة من نوافذ المراقبة القصيرة دون أن تصبح قديمة.
اجعل المخزون جزءًا من التحكم في التغيير
يلزم مراجعة المسار عندما يقوم فريق بإضافة مورد إعلام، أو تغيير عنوان "من"، أو نقل قائمة انتظار الدعم، أو استبدال خدمة الحالة. إعادة اختبار التدفقات المتأثرة والحفاظ على تواريخ الأدلة. اكتمال المخزون فقط إلى نطاقه المعلن؛ يمكن لميزات المنتج الجديدة إضافة مرسلين جدد. أغلق كل عملية ترحيل باستخدام اختبار وافق عليه المالك وإجراء استرداد قابل للاستخدام، وليس متوسطًا على مستوى النطاق.