كيف يعمل

لا تُخزَّن أي حالة بين التشغيلات. ملف الإعداد والمزوّدون هم مصادر الحقيقة الوحيدة، فلا شيء ينحرف أو يُقفل أو يحتاج إلى إصلاح.

تُنفَّذ الإجراءات داخل النطاق بترتيب ثابت:

لهذا يتوقف أول apply عادة برسالة "DNS ownership checks did not pass": نُشرت السجلات قبل لحظة ولم تنتشر بعد. انتظر، وشغّل apply مرة أخرى، فتُتخطّى الإجراءات المكتملة.

لكل سجل يريده mailctl دور: MX أو SPF أو DKIM أو DMARC أو الملكية أو MTA-STS أو TLS-RPT أو BIMI. والدور يحدد أي السجلات القائمة يُعدّ تعارضًا.

يوقف التعارض الخطة بخطأ يذكر السجل. مرّر -replace-dns لاستبداله بدل ذلك. لا يُكتب فوق أي شيء افتراضيًا.

قد يقترح مزوّدان على نطاق واحد محتوى مختلفًا لسجل يجب أن يكون فريدًا، مثل DMARC. هذا خطأ في الإعداد يبلّغ عنه plan وaudit كلاهما، بدل سباق على أيهما يفوز.

apply بلا وسائط يخطّط من جديد وينفّذ النتيجة، فيعمل دائمًا على الحالة الحالية. وapply -plan saved.json ينفّذ خطة حُفظت سابقًا بـ plan -json، ويرفض إن تغيّرت الحالة الحية منذ إعدادها. استخدم الصيغة الثانية حين يراجع شخص الخطة ويطبّقها شيء آخر.

كل إجراء آمن التكرار. إعادة التشغيل بعد تطبيق جزئي تنفّذ ما تبقّى فقط. والنطاق المتقارب كليًا يبلّغ No changes.

بعض التغييرات لا يمكن إجراؤها عبر واجهة المزوّد. تظهر في الخطة بوسم MANUAL مع المكان الذي تُجرى فيه، مثل مركز إدارة Microsoft 365. لا ينفّذها apply أبدًا، والخطة التي لم يتبقَّ فيها إلا إجراءات يدوية تُعدّ متقاربة.

يسأل plan المزوّدين عمّا يحتفظون به. أما audit فيسأل الإنترنت: يحلّ السجلات المنشورة عبر محلّل حقيقي ويجلب سياسة MTA-STS عبر HTTPS. واجهة المزوّد تبلّغ بما طلبته، وaudit يبلّغ بما سيراه الخادم المستقبِل. شغّله بعد أن يأخذ DNS وقته في الانتشار.

للمساهمين، كل خطوة تعيش في حزمة واحدة تحت internal/: