mailctl
إعداد البريد الإلكتروني للنطاقات الخاصة بطريقة تصريحية.
ملف YAML واحد يصف سجلات DNS وصناديق البريد والأسماء البديلة والتوجيه وسياسة قابلية التسليم لكل نطاق تملكه.
يقرأ mailctl الحالة الحية من كل مزوّد، ويقارنها بذلك الملف، ويطبع خطة مرتّبة، ثم ينفّذ ما طبعه بالضبط. ملف Go تنفيذي واحد، بلا خدمة خلفية ولا ملف حالة ولا قفل.
$ mailctl plan
example.com
-----------
CREATE dns MX example.com -> mailserver.purelymail.com [purelymail]
CREATE dns TXT example.com -> v=spf1 include:_spf.purelymail.com ~all
CREATE dns CNAME purelymail1._domainkey.example.com
CREATE domain add example.com [purelymail]
CREATE mailbox create contact@example.com [purelymail]
9 actions
Run `mailctl apply` to make these changes.ما الذي يديره
-
النطاقات
يسجّل النطاق لدى مزوّد البريد ويُكمل التحقق من ملكيته. -
DNS
ينشر سجلات MX وSPF وDKIM وDMARC وMTA-STS وTLS-RPT وBIMI في Cloudflare، ويرفض الكتابة فوق سجلات لا يعرفها. -
صناديق البريد
ينشئ صناديق بريد حقيقية لدى المزوّد، ويولّد بيانات اعتماد حين لا تقدّمها، ويبلّغ عنها مرة واحدة فقط. -
قابلية التسليم
يدمج متطلبات SPF لكل المزوّدين في سجل TXT الوحيد الذي يسمح به RFC 7208، ويمكنه نشر Worker يقدّم سياسة MTA-STS.
المزوّدون
| المزوّد | الوارد | صناديق البريد | الأسماء البديلة | الالتقاط الشامل |
|---|---|---|---|---|
نعم |
نعم |
نعم |
نعم |
|
نعم |
نعم |
لا |
لا |
|
نعم |
— |
نعم |
نعم |
|
صادر |
— |
— |
— |
لا يدعم Microsoft 365 الأسماء البديلة والالتقاط الشامل لا لأن mailctl يرفض
تنفيذها: فواجهة Graph تعرض proxyAddresses للقراءة فقط ولا تقدّم أي واجهة
للالتقاط الشامل. يرفض mailctl هذه الكتل في الإعداد بخطأ يذكر مركز الإدارة، بدل
أن يقبلها ولا يفعل شيئًا.
ثلاث أفكار تحمل الأداة كلها
- الحالة المطلوبة
-
ملف YAML هو الوصف الوحيد لما يجب أن يوجد. لا يُخزَّن شيء في مكان آخر، فلا انحراف بين تصوّر mailctl للعالم والعالم نفسه.
- خطّط ثم طبّق
-
يقرأ
planالحالة الحية ويقارنها ويطبع قائمة مرتّبة من الإجراءات. لا يغيّر شيئًا، ولا يقوم بأي إدخال أو إخراج بعد بدء التخطيط. وينفّذapplyتلك القائمة بالضبط. ويعرضmailctl uiالخطة والتدقيق نفسيهما في المتصفح بدل الطرفية، للقراءة فقط في هذا الإصدار، ويعطيplan -jsonقائمة الإجراءات نفسها بصيغة JSON لاستخدامها في نص برمجي. - التكرار الآمن
-
تشغيل
applyمرتين يساوي تشغيله مرة واحدة. النطاق المتقارب يبلّغNo changes.، وهذا ما يجعل تشغيل الأداة من الطرفية آمنًا في أي وقت.
ما لا يفعله عمدًا
لا يتظاهر mailctl. حين لا تستطيع واجهة المزوّد التعبير عن شيء ما، يرفضه الإعداد
بخطأ يذكر الطريق اليدوي، بدل أن يقبل الإعداد ويتجاهله. فالإعداد المتجاهَل يبدو
كأنه نافذ، وهذا أسوأ من الخطأ: requireTwoFactorAuthentication المتجاهَل يبدو
تمامًا كمصادقة ثنائية مفروضة.
كل ما قد يُضيّع البريد صعب عمدًا: حذف صندوق بريد يتطلب -prune و
-prune-mailboxes، ثم تأكيدًا يطلب منك كتابة اسم النطاق.
إلى أين بعد ذلك
-
البدء السريع
نطاق واحد، من لا شيء إلى بريد يعمل، مع سبب توقّف أول تطبيق في منتصف الطريق. -
وصفات
إعدادات كاملة لحالات شائعة: صناديق بريد حقيقية، تحويل فقط، Microsoft 365، وتبنّي نطاق قائم. -
صفحة الإدارة
خطّط ودقّق من المتصفح، بالعربية أو الإنجليزية، دون أن يُطبَّق شيء من وراء ظهرك. -
كيف يعمل
المسار من الإعداد إلى الخطة المطبّقة، وترتيب تنفيذ الإجراءات، وكيف يُحكم على تعارضات DNS. -
الإعداد
كل مفتاح في الملف، وقواعد التحقق التي تلتقط الأخطاء الشائعة. -
الأوامر
كل أمر وخيار، ولماذا يعمل الحذف بالطريقة التي يعمل بها. -
بيانات الاعتماد
كيف تُعامَل الرموز وكلمات سر صناديق البريد المولّدة، والضمانات المحيطة بها. -
قابلية التسليم
SPF وDKIM وDMARC وMTA-STS وTLS-RPT وBIMI، وترتيب معقول لتفعيلها. -
استكشاف الأخطاء
الأخطاء التي يقع فيها الناس فعلًا، ومعنى كل منها.
المشروع
mailctl مفتوح المصدر بموجب رخصة MIT.
-
المساهمة: الأعراف التي تلتزم بها الشيفرة
-
الأمان: ضمانات التعامل مع بيانات الاعتماد، وكيفية الإبلاغ عن ثغرة بشكل خاص
-
خارطة الطريق: ما هو مخطط له، وما لن يُنفَّذ عمدًا، ولماذا
عدّل هذه الصفحة آخر تحديث