وصفات
إعدادات وتسلسلات أوامر كاملة لحالات البريد الشائعة.
كل وصفة كتلة نطاق كاملة مع الأوامر المرافقة لها. استبدل example.com بنطاقك.
تبدأ كل وصفة بالطريقة نفسها: mailctl plan لقراءة ما سيتغيّر، ثم mailctl apply.
صناديق بريد حقيقية على Purelymail
صناديق بريد تسجّل الدخول إليها، مع اسم بديل والتقاط شامل، وسياسة DMARC تبدأ بالإبلاغ فقط.
version: 1
cloudflare:
accountId: ${CLOUDFLARE_ACCOUNT_ID}
domains:
- name: example.com
mail:
provider: purelymail
mailboxes:
- address: contact@example.com # credential generated and reported once
aliases:
- match: info
to: [contact@example.com]
catchAll:
to: [contact@example.com]
deliverability:
dmarc:
policy: none
rua: mailto:contact@example.com
تحتاج إلى CLOUDFLARE_API_TOKEN وCLOUDFLARE_ACCOUNT_ID وPURELYMAIL_API_TOKEN.
ويعتمد مكان بيانات الاعتماد المولّدة على الجهاز:
-
macOS
-
Linux وCI
يحفظها apply في سلسلة المفاتيح (Keychain). اقرأها من هناك:
$ security find-generic-password -s mailctl -a contact@example.com -w
لا توجد سلسلة مفاتيح، فاطلب من apply ملفًا. يُنشأ بصلاحيات 0600 ويجب ألا يكون
موجودًا مسبقًا:
$ mailctl apply -secrets-out creds.txt
راجع Purelymail قبل أن تختار عناوين فيها نقطة.
حوّل نطاقًا إلى صندوق وارد لديك مسبقًا
بلا صندوق بريد تدفع ثمنه: يحوّل Cloudflare Email Routing البريد إلى عنوان قائم.
domains:
- name: example.com
mail:
provider: cfrouting
aliases:
- match: hello
to: [someone@gmail.com]
catchAll:
to: [someone@gmail.com]
يرسل Cloudflare إلى كل وجهة رابط تأكيد بالبريد. إلى أن ينقره صاحبها، يبلّغ plan
بأن الوجهة غير مؤكَّدة. راجع
التوجيه والإرسال عبر Cloudflare.
استقبل على Purelymail، وأرسل من تطبيق عبر Cloudflare
domains:
- name: example.com
mail:
provider: [purelymail, cfsending]
mailboxes:
- address: contact@example.com
تُدمج متطلبات SPF للمزوّدَين في سجل TXT الوحيد الذي يسمح به RFC 7208.
Microsoft 365
domains:
- name: example.com
mail:
provider: ms365
ms365:
license: BUSINESS_BASIC
usageLocation: DE
mailboxes:
- address: a.person@example.com
displayName: A Person
توقّع أن تشغّل apply ثلاث مرات: الأولى تضيف النطاق إلى المستأجر، والثانية تنشر
DNS وتتحقق منه، والثالثة تنشئ صناديق البريد. يخبرك plan بالمرحلة التي أنت فيها.
راجع Microsoft 365 لتسجيل التطبيق.
تبنَّ نطاقًا لديه بريد مسبقًا
ابدأ مما هو موجود بدل كتابة YAML يدويًا:
$ mailctl import -domain example.com -provider purelymail >> import.yaml
لا يغيّر import شيئًا. راجع الكتلة، وانقلها إلى إعدادك، ثم شغّل mailctl plan.
الخطة التي تقول No changes. تعني أن الإعداد يصف النطاق بدقة. السجلات التي
تتعارض مع ما يريده المزوّد تُفشل الخطة؛ اقرأها، ثم مرّر -replace-dns إن كان
استبدالها صحيحًا.
أضف صندوق بريد
$ mailctl mailbox add new.person@example.com
يعدّل هذا الأمر الإعداد مع الإبقاء على تعليقاتك، ثم يطبّق. أضف -edit-only للتوقف
بعد التعديل ومراجعته بـ mailctl plan أولًا.
احذف صندوق بريد
حذف صندوق البريد يتلف بريده، لذا يتطلب خطوتين عمدًا:
-
mailctl mailbox rm old.person@example.comيحذفه من الإعداد فقط. -
mailctl apply -prune -prune-mailboxesيحذفه لدى المزوّد، بعد سؤال يطلب منك كتابة اسم النطاق.
أعد تعيين بيانات الاعتماد
$ mailctl mailbox passwd contact@example.com
يولّد mailctl بيانات اعتماد جديدة ويبلّغ عنها مرة واحدة، إلى سلسلة المفاتيح على
macOS. مرّر -password-env NAME لتعيين قيمة اخترتها أنت.
شدّد قابلية التسليم مع الوقت
فعّل السياسات بهذا الترتيب، وانتظر بين الخطوات ريثما تصل التقارير:
-
اجعل البريد يعمل، وتأكد من ذلك بـ
mailctl audit. -
DMARC بـ
policy: noneمع عنوانrua، وtlsRpt. -
اقرأ التقارير وأصلح ما تكشفه.
-
DMARC بـ
quarantine، ثمreject. -
MTA-STS بـ
mode: testingمعdeploy: true. -
بعد أسبوع هادئ، MTA-STS بـ
mode: enforce.
راجع ترتيب معقول لمعرفة السبب.
افحص كل شيء من المتصفح
$ mailctl ui
شغّل خطة وتدقيقًا من لوحة التحكم. راجع صفحة الإدارة.
شغّل من CI
يعطي plan -json قائمة الإجراءات بصيغة JSON لنص برمجي. ويطبّق apply -plan خطة
محفوظة بالضبط، ويرفض إن تغيّرت الحالة الحية منذ حفظها:
$ mailctl plan -json > plan.json
$ mailctl apply -plan plan.json -secrets-out creds.txt
لا توجد سلسلة مفاتيح في CI، لذا يكتب -secrets-out بيانات الاعتماد المولّدة في
ملف جديد بصلاحيات 0600. أبقِ هذا الملف خارج المخرجات والسجلات.
عدّل هذه الصفحة آخر تحديث