كيف ينبغي لفريق المنتج تنفيذ توجيه البريد في Cloudflare بأمان؟

حدّد مهمة البريد الوارد وحدود المسؤولية

ابدأ بتدوين مهمة البريد الوارد بدقة: أي نطاق وأي أجزاء محلية من العناوين يجب أن تقبل البريد، ومن يملك كل وجهة، وهل ينبغي إعادة توجيه الرسالة أم معالجتها بالشيفرة أم إسقاطها، وكم يمكن الاحتفاظ بالأدلة التشغيلية. Cloudflare Email Routing طبقة توجيه للبريد الوارد. ولا تنشئ بذاتها تذكرة دعم، ولا تثبت هوية المُرسِل، ولا تثبت أن البريد المُعاد توجيهه وصل إلى إنسان، ولا تضمن موضع الرسالة في صندوق البريد لدى الوجهة. أبقِ حالات التطبيق اللاحقة هذه منفصلة. عيّن مالكًا تشغيليًا لـ DNS وقواعد التوجيه وشيفرة الـ Worker وتوثيق الوجهات والحوادث الأمنية والتراجع. استخدم أسماء مستعارة مخصصة مثل support@ أو invoices@ بدلًا من catch-all خلال الإطلاق الأول. فالمسار الضيق يقلّل الجمع غير المقصود للبريد، ويجعل نتائج الاختبار قابلة للتفسير، ويحدّ من أثر وجهة خاطئة أو فرع خاطئ في الـ Worker.

هيّئ النطاق دون معاملة DNS كخطوة تثبيت عمياء

تنص وثائق Cloudflare Email Service الحالية على أن النطاق يجب أن يستخدم Cloudflare DNS لـ Email Routing. ويمكن لمسار التهيئة أن يضيف سجلات MX لتوجيه البريد الوارد إضافةً إلى سجلات TXT المتعلقة بـ SPF وDKIM التي يصفها المنتج. راجع السجلات المقترحة بدقة قبل تطبيقها. واجرد أولًا سجلات MX وSPF وDKIM وDMARC الحالية وصناديق البريد وخدمات إعادة التوجيه ورموز التحقق وتفويضات النطاقات الفرعية. استبدال سجلات MX يغيّر وجهة جلسات SMTP الواردة الجديدة، لذا نسّق نافذة صيانة واحتفظ بالقيم السابقة كسجل للتراجع. تجنّب إنشاء عدة سجلات SPF من نوع TXT على اسم مالك واحد. بعد التغيير، استعلم من محلّلات DNS الموثوقة والعامة، ثم اختبر التسليم من حساب لا علاقة له بالوجهة. تقديرات انتشار DNS ليست دليلًا على أن كل مُرسِل يرى الآن الإجابة نفسها، ولوحة التحكم الخضراء لا تثبت نجاح إعادة التوجيه من طرف إلى طرف.

وثّق الوجهات قبل إنشاء مسارات فعّالة

توثّق Cloudflare عناوين الوجهات على أنها موارد على مستوى الحساب يجب توثيقها قبل أن تتمكن قواعد التوجيه من استخدامها. وخطوة التوثيق حدّ مهم لمكافحة إساءة الاستخدام: فهي تُظهر السيطرة على صندوق البريد في تلك اللحظة، لكنها لا تثبت تفويضًا تجاريًا مستمرًا أو عضوية صحيحة في الفريق. سجّل في نظامك الخاص المالك الطالب والغرض وتاريخ التوثيق وتاريخ المراجعة. فضّل وجهة يتحكم فيها الفريق على العنوان الشخصي لموظف. أزل وجهات المستخدمين الذين غادروا فورًا، وافحص القواعد التي تعتمد على عنوان ما قبل حذفه، لأن Cloudflare توثّق أن حذف وجهة يعطّل المسارات التي تستخدمها. عامِل رسائل التوثيق على أنها حساسة أمنيًا، ولا تنقر عليها تلقائيًا أو تعِد توجيهها إلى أتمتة غير موثوقة. وفي تغييرات بيئة الإنتاج، اشترط مراجعة من شخص ثانٍ ضمن إجراءات البنية التحتية المعتادة لديك حتى لو سمحت لوحة التحكم لمشغّل واحد بحفظ القاعدة.

أنشئ قواعد صريحة وافهم أولوية التنفيذ

تقرن قاعدة التوجيه نمط بريد إلكتروني إما بوجهة موثَّقة أو بـ Worker. توثّق Cloudflare ثلاثة إجراءات: الإرسال إلى بريد إلكتروني، والإرسال إلى Worker، والإسقاط. أنشئ مسارات الأجزاء المحلية الأكثر تحديدًا أولًا، واذكر مالكها في سجلات التغيير، وتأكّد من وجود قاعدة مقصودة واحدة فقط لكل نمط. وتحذّر الوثائق من أنه إذا استخدمت عدة قواعد النمط نفسه، فلن تعالج البريد الوارد إلا القاعدة المدرجة أولًا. لا تعتمد على الترتيب المرئي كقاعدة عمل غير رسمية؛ بل أزل الغموض. أبقِ قواعد الإسقاط مبرَّرة بدقة لأن الحذف هو عدم تسليم مقصود. لا تفعّل catch-all إلا بعد حصر عواقبه على الخصوصية وحجم البريد المزعج والأخطاء الإملائية والتخزين. فقد يجمع catch-all عناوين لم يقصد أحد إنشاءها، لذا ينبغي أن تكون له وجهة أو سياسة Worker مخصصة وتنبيهات ومسار تعطيل سريع، بدلًا من أن يرث بصمت صندوق بريد شخصيًا.

استخدم العناوين الفرعية عن قصد

توثّق Cloudflare دعمًا اختياريًا لعناوين علامة الجمع (plus addressing) متوافقًا مع RFC 5233. عند تفعيله، يمكن لبريد موجّه إلى عنوان مثل user+detail@example.com أن يطابق قاعدة user@example.com الأساسية مع الحفاظ على التفصيل في مستلِم الرسالة المعروض للـ Worker وفي السجلات. قد يدعم ذلك وسوم التوجيه أو معرّفات الاختبار أو الأسماء المستعارة لكل سير عمل، لكن التفصيل نص يتحكم فيه المُرسِل. فلا تعامله كهوية مستأجر مصادَق عليها أو تفويض أو سرّ. وحّد صيغته وضع له حدودًا قبل استخدامه كمفتاح في قاعدة البيانات أو بُعد في المقاييس أو اسم طابور. كما توثّق Cloudflare أن القاعدة الصريحة للعنوان الفرعي الكامل لها الأولوية على القاعدة الأساسية. اختبر الحالتين الصريحة والاحتياطية حتى لا تغيّر قاعدة محددة لاحقة سير عمل قائمًا بصمت. وتجنّب وضع بيانات شخصية أو سرية في وسوم علامة الجمع لأنها قد تظهر في الترويسات والسجلات والرسائل المُعاد توجيهها وتصديرات الدعم والتحليلات.

لا تختر Worker إلا لاحتياجات معالجة حقيقية

استخدم إعادة التوجيه المباشرة عندما يكون المطلوب ببساطة عنوانًا واحدًا إلى صندوق بريد موثَّق واحد. ووجّه إلى Worker عندما تحتاج إلى تفرّع مضبوط أو فحص للرسالة أو تخزين أو رفض أو ردود أو إعادة توجيه متعددة. يكشف معالج البريد في Cloudflare مُرسِل الظرف ومستلِمه والترويسات وتدفق MIME الخام وحجمه، وتوابع لإعادة التوجيه أو الرد أو الرفض. أبقِ المعالج صغيرًا: تحقّق من سياسة المستلِم أولًا، وطبّق حدود الرسالة والتحليل، وأجرِ الاستدعاءات الخارجية عبر طوابير محدودة زمنيًا متى أمكن، وحدّد النتيجة لكل خطأ. الترويسات والمواضيع وأسماء العرض والمرفقات والروابط وحدود MIME يتحكم فيها المهاجم. لا تسجّل النصوص الخام أو العناوين الكاملة افتراضيًا. وإن لزم تخزين المحتوى، فشفّره، وقيّد الوصول إليه بحسب المستأجر والمهمة، وحدّد آلية حذفه، وافحص المرفقات خارج مسار التوجيه المتزامن. ولا يجوز أن يؤدي استثناء في التحليل إلى إعادة توجيه أو رد غير مقصودين.

نفّذ مسار قرار صريحًا واحدًا

ينبغي للمعالج الآمن أن يحسب إجراءً معتمدًا قبل تنفيذ أي آثار جانبية. على سبيل المثال، اربط مستلِم الظرف الدقيق بسير عمل مضبوط، وارفض المستلِمين غير المعروفين، وأضف إلى الطابور سجل بيانات وصفية محدودًا، ثم أعِد التوجيه فقط إلى وجهة موثَّقة مختارة من الإعدادات. لا تقبل أبدًا وجهة مأخوذة من ترويسة الرسالة أو موضوعها أو وسم علامة الجمع أو نصها. وعند إعادة التوجيه إلى عدة وجهات، تنص وثائق الحدود في Cloudflare على أن الـ Worker يجب أن يستدعي forward مرة لكل وجهة موثَّقة؛ فقرّر ما إذا كان النجاح الجزئي مقبولًا وسجّل كل محاولة على حدة. استخدم معرّف ربط داخليًا ثابتًا بدلًا من محتوى المستلِم في السجلات. وإذا كان المعالج قد يرد، فاتبع قيود الرد الحالية في Cloudflare وأضف حماية من الحلقات. الرد ليس إقرارًا من فريق بشري. وإذا كان الاستقبال المتين في التطبيق مطلوبًا، فخزّن التذكرة أو الحدث قبل إرسال رد تلقائي، وطابِق الإخفاقات الغامضة بدلًا من الوعد بأن العمل قد أُنشئ.

عامِل إعادة التوجيه والردود كنتائج محدودة بنطاق أدلتها

الاستدعاء الناجح لتابع في الـ Worker دليل على عملية المنصة، لا على النتيجة النهائية لدى المستخدم. يعرّف SMTP النقل بين الأنظمة، بينما تبقى التصفية اللاحقة وإعادة التوجيه والحجر الصحي وقواعد صندوق البريد والقراءة البشرية خارج تلك القفزة. نمذج حالات مثل: استلمتها Cloudflare، واستُدعي الـ Worker، وجرت محاولة الإجراء، وقَبِل خادم الوجهة، وتأخّرت أو فشلت، وأُنشئ سجل التطبيق، كلًّا على حدة. ولا تصنّفها جميعًا على أنها سُلِّمت. احتفظ بسجلات منظّمة ومقلَّلة البيانات حفاظًا على الخصوصية تتضمّن هوية القاعدة ومراجعة الـ Worker والإجراء والطابع الزمني ومعرّف الربط والنتيجة الإجمالية؛ ولا تخزّن العناوين الكاملة أو المحتوى إلا حيث تبرّر ذلك حاجة تشغيلية موثَّقة. أطلق تنبيهات عند إخفاقات الاستدعاء، وحالات الرفض بسبب الحجم، والحجم غير الطبيعي لـ catch-all، وأنماط المُرسِلين المتكررة، وإخفاقات الوجهات، والتغيرات المفاجئة في حركة البريد. أرسل رسائل اختبار مضبوطة كعيّنات باستمرار، لكن لا تستخدم أبدًا محتوى عملاء حقيقيًا كبيانات اختبار للمراقبة.

احترم حدود المنصة الحالية وأنماط الإخفاق

توثّق Cloudflare حاليًا حدودًا لـ Email Routing تشمل 200 قاعدة توجيه لكل نطاق، و200 عنوان وجهة لكل حساب، وحدًا لحجم الرسالة الواردة يبلغ 25 MiB، وحدود المعالج والذاكرة القياسية في Workers للرسائل الموجّهة عبر Worker. عامِل هذه القيم على أنها وثائق المزوّد الحالية، لا ثوابت دائمة. اقرأ صفحة الحدود المباشرة أثناء التخطيط، وأطلق تنبيهًا قبل الاقتراب من أي سقف بوقت كافٍ. قد تستنفد رسائل MIME الكبيرة الذاكرة أو المعالج حتى دون سقف الحجم الخام للمنصة إذا فُكّ ترميزها دون حذر. عالج المحتوى غير الضروري كتدفق أو ارفضه، وضع سقفًا لعدد المرفقات، وضع التحليل المكلف خلف عمل غير متزامن محدود. وقد تؤدي إعادة تسمية Worker إلى كسر ربطه بالتوجيه وفقًا لوثائق التوجيه في Cloudflare، لذا أدرج فحص المسارات ضمن التحقق من النشر. ينبغي أن تظهر الاستدعاءات الفاشلة في سجلات Workers، لكن السجلات وحدها لا تتيح إعادة التشغيل. قرّر ما إذا كان ينبغي للمُرسِل إعادة المحاولة عبر SMTP، وما إذا كان المشغّل يستطيع إعادة تشغيل مهمة التطبيق بأمان، وكيف تُمنع السجلات المكررة في المراحل اللاحقة.

اختبر الإطلاق والتراجع كتغيير واحد

أنشئ أولًا مسارًا تجريبيًا أو منخفض المخاطر. أرسل رسائل مضبوطة من حساب مختلف عن الوجهة الموثَّقة، تغطي النص العادي والمحتوى متعدد الأجزاء والمرفقات المتوقعة وعناوين علامة الجمع والأجزاء المحلية غير المعروفة والمدخلات المشوّهة عمدًا ضمن حدود آمنة. تحقّق من إجابات DNS وإعدادات لوحة التحكم ومراجعة الـ Worker ونتيجة إعادة التوجيه والسجل اللاحق وسلوك الخصوصية. ثم اختبر المسارات السلبية: وجهة غير موثَّقة، وقاعدة معطّلة، واستثناء في الـ Worker، ورسالة كبيرة الحجم، وتسليم متكرر، وقاعدة كانت ستقع لولا ذلك في catch-all. سجّل الأدلة المتوقعة لكل مرحلة. وقبل توسيع حركة البريد، تمرّن على تعطيل القاعدة، واستعادة سجلات MX السابقة إن لزم، وفصل الـ Worker، وإبلاغ المعنيين بالبريد المتأخر أو المرفوض. تراجع عند فقدان توجيه غير مفسَّر، أو كشف بيانات بين المستأجرين، أو تسرّب المحتوى، أو ردود غير متوقعة، أو تخزين غير محدود، أو إخفاق مستمر في الـ Worker. احتفظ بلقطات الإعدادات ونتائج الاختبار دون الاحتفاظ بمحتوى الرسائل أطول من اللازم.

كيف ينسجم SendHQ

يدعم SendHQ البريد الوارد. يغطي هذا الدليل Cloudflare Email Routing؛ اتبع وثائق كل خدمة لإعدادها وحدودها الخاصة.

الأسئلة الشائعة

المصادر

• Route emails — Cloudflare
• قواعد توجيه البريد والعناوين — Cloudflare
• Workers API للبريد الموجَّه — Cloudflare
• حدود Cloudflare Email Service — Cloudflare
• RFC 5321: بروتوكول نقل البريد البسيط (SMTP) — محرّر RFC
• RFC 5233: Sieve Email Filtering: Subaddress Extension — مرجع RFC Editor