Catch-all للنطاق: التوجيه والمراجعة والمخاطر

تفعّل استقبال جميع عناوين النطاق عبر catch-all كي تصلك استفسارات العملاء حتى عند كتابة saels@ بدل sales@. هذا مفهوم. لكن داخل نطاق العناوين التي تشملها القاعدة، يتوقف خادمك عن رفض المستلمين المجهولين ويقبل رسائل إلى عناوين عشوائية، بما فيها اختبارات آلية للعناوين. قد ينتج عن إعداد غير مناسب رسائل مرتدة غير مرغوبة أو backscatter، وحلقات ردود تلقائية، ومشكلات تسليم عند إعادة التوجيه الخارجي. هذه مخاطر محتملة، وليست نتائج حتمية لكل قاعدة catch-all.

تتوقف أدلة كثيرة عند «فعّل catch-all ووجّه البريد إلى صندوق». وهنا يبدأ التخطيط الفعلي. يتناول هذا الدليل صناديق مراجعة منفصلة، والتوجيه بالتعبيرات النمطية في Postfix، ومنع الحلقات، ومشكلات المصادقة عند إعادة التوجيه. اقرأ أولًا دليل إعداد إعادة توجيه البريد إذا احتجت إلى الأساسيات؛ فالتركيز هنا على catch-all للنطاق.

ما هو catch-all للنطاق؟

هو قاعدة في خادم نقل البريد MTA تقبل الرسائل المرسلة إلى عناوين نطاقك التي لا تطابق مستلمًا معروفًا. يجب أن تشمل قائمة المستلمين الصالحين الصناديق والأسماء المستعارة والمجموعات وغيرها، لا الصناديق وحدها. بدل 550 User Unknown، قد يرد الخادم على فحص المستلم بـ250 OK ويوجه الرسالة إلى وجهة بديلة. قبول المستلم يختلف عن القبول النهائي بعد DATA. يغيّر catch-all مسار المستلم في مغلف SMTP، ولا يغيّر المصادقة بذاته؛ وقد تضيف إعادة التوجيه أو الإشعارات اللاحقة مخاطر أخرى.

المغلف والترويسة: لماذا يهم التمييز بينهما

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

تحدد RFC 5321 مغلف SMTP، بما فيه الأمران RCPT TO وMAIL FROM المتبادلان أثناء النقل. وتحدد RFC 5322 ترويسات الرسالة، ومنها To: وFrom: اللذان يعرضهما برنامج البريد.

يربط catch-all مستلم مغلف غير معروف بوجهة بديلة، وقد يترك الترويسات الظاهرة كما هي. لا يبطل هذا الربط المصادقة بمفرده. يفحص SPF عنوان IP المرسل وفق نطاق MAIL FROM أو HELO عندما ينطبق، ويتحقق DKIM تشفيريًا من الأجزاء الموقّعة من الترويسات والجسم. يتطلب DMARC نجاح فحص واحد على الأقل، SPF أو DKIM، مع المحاذاة لنطاق From الظاهر في الترويسة. وقد تؤثر إعادة توجيه خارجية إضافية في هذه الفحوص.

حالة الفشل عند إعادة التوجيه الخارجي

تضيف إعادة توجيه رسائل catch-all إلى Gmail أو Outlook.com محطة SMTP جديدة. وقد تفشل رسالة اجتازت المصادقة سابقًا في فحص لاحق:

1. المرسل الأصلي: client@bank.com (IP: 1.2.3.4)
2. يقبل خادمك typo@yourdomain.com ويعيد التوجيه إلى you@gmail.com
3. يرى Gmail اتصالًا من عنوان IP لخادمك، مع bank.com كنطاق مرسل المغلف
4. يفشل SPF في المثال لأن سجل SPF في bank.com لا يسمح بعنوان IP الخاص بك
5. إذا استخدم bank.com DMARC p=reject وغاب أيضًا DKIM صالح ومتوافق، فقد يرفض المستلم الرسالة. وقد يظهر خطأ SMTP أو إشعار بتعذر التسليم

فعّلت catch-all لتقليل الرسائل المفقودة، لكن إعادة التوجيه الإضافية قد تخلق مشكلة جديدة. إذا احتجت إليها، افحص SRS، أي مخطط إعادة كتابة المرسل، أو مزودًا يدعم إعادة الكتابة على الخادم. قد تتولى خدمة إعادة التوجيه بالأسماء المستعارة من TrekMail الموصوفة هذه المعالجة، بحسب المزايا والخطة الحالية. لا يضمن SRS وحده توافق DMARC أو التسليم.

ثلاثة مخاطر لـcatch-all على النطاق

تشمل المخاطر المهمة backscatter وما يسببه للسمعة، وحلقات الردود التلقائية، وفشل التسليم بسبب SPF أو DMARC عند إعادة التوجيه الخارجي. افحص الثلاثة قبل تغيير الإعداد. معالجة نقطة واحدة فقط قد تخلق مشكلة في نقطة أخرى. المقارنة بين مهمة من خمس دقائق وأسبوع من الإصلاح للتنبيه إلى المخاطر، لا لتحديد مدة العمل.

1. Backscatter: خطر على السمعة

قد يحدث backscatter عندما يقبل خادمك رسالة catch-all نهائيًا بـ250 OK، ثم يصنفها مرشح البريد المزعج كمشكلة بعد انتهاء جلسة SMTP. إذا أنشأ الخادم إشعارًا بتعذر التسليم إلى MAIL FROM، فقد يصيب عنوانًا مزورًا لشخص لا علاقة له بالرسالة. عندها ترسل إشعارات غير مرغوبة إلى أشخاص لم يكتبوا إليك. قد يضر ذلك بسمعة عنوان IP ويسهم في قوائم الحظر؛ لكن الإدراج خلال أيام قليلة ليس حتميًا.

ارفض المستلمين غير المقبولين أثناء اتصال SMTP متى أمكن، قبل قبول الرسالة نهائيًا بـ250 OK. أما رسائل catch-all المقبولة عمدًا فيمكن عزلها للمراجعة. تجنب الإشعارات غير المطلوبة إلى مرسلين قد تكون عناوينهم مزورة. لا يعني ذلك تعطيل كل إشعارات تعذر التسليم المشروعة أو إسقاط رسائل مشروعة بصمت.

2. حلقات الردود (خطأ Exchange 5.4.14)

يوجه catch-all المستلمين المجهولين إلى صندوق بديل مفعّل فيه رد غياب. يرسل ناشر بريد مزعج إلى random@yourdomain.com، فتصل الرسالة إلى الصندوق. يذهب الرد التلقائي إلى مرسل مزور ثم يرتد. إذا عاد إلى random@yourdomain.com وأُعيدت معالجته، فقد تنشأ حلقة بحسب التوجيه والحماية المتاحة. قد يبلغ Exchange عندها عن 550 5.4.14 Hop count exceeded - possible mail loop.

راجع منع الردود التلقائية لرسائل catch-all. تُعد X-Auto-Response-Suppress: All أداة تحكم مهمة خصوصًا في Exchange، وليست ضمانًا عامًا. يتوقف تأثيرها في ردود الغياب وإيصالات التسليم وإيصالات القراءة على البرنامج المستقبل. اختبر الحماية من الحلقات وسلوك الردود الفعلي.

3. هجمات جمع عناوين البريد (DHA)

إذا رد كل عنوان في نطاقك بـ250 OK، يستطيع المهاجمون اختبار آلاف التركيبات آليًا، مثل admin@ وhr@ وceo@ وinvoice@. يؤكد catch-all العام قبول SMTP لهذه العناوين، لا وجود صناديق فعلية. وقد يشجع ذلك إرسال البريد المزعج إلى النطاق، وربما لسنوات، لكنه لا يثبت صلاحية العناوين ولا يحدد مدة الهجمات.

يمكن لأنماط عناوين محددة بدل catch-all عام تقليص نطاق القبول. تشرح الاستراتيجية 2 هذا النهج.

الاستراتيجية 1: صندوق منفصل للمراجعة

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

منطق الإعداد:

1. القبول: يقبل الخادم *@domain.com ضمن نطاق catch-all المحدد
2. التحديد: المستلم ليس صندوقًا أو اسمًا مستعارًا أو مجموعة أو مستلمًا صالحًا آخر
3. الفصل: التوجيه إلى صندوق مشترك مخصص مثل catchall_sink@domain.com
4. منع الردود: في بيئة Microsoft مناسبة، ضبط Spam Confidence Level على 9 وتطبيق X-Auto-Response-Suppress: All؛ ثم التحقق من الإجراءات الفعلية

راجع الصندوق، مثلًا أسبوعيًا. تُنقل الرسائل المشروعة بعد الفحص إلى الصندوق الصحيح، وتبقى البقية معزولة وفق سياسة المراجعة والاحتفاظ. خطط لحدود التخزين والمسؤولية وتواتر المراجعة. هذه بنية ممكنة لتقليل المخاطر، وليست الإعداد الوحيد المقبول أو حماية للسمعة بلا شروط.

قاعدة نقل في Microsoft 365 / Exchange Online

الإعداد التالي مثال تصوري، وليس تغييرًا افتراضيًا لكل مستأجر M365. يعطّل نوع النطاق Internal Relay ميزة Directory Based Edge Blocking (DBEB)، لكنه لا ينشئ catch-all بمفرده. استخدمه فقط مع بنية مفوّضة وموصل إلى خادم بريدك المقصود لمعالجة المستلمين الآخرين، لا عندما يُستضاف جميع المستلمين هنا فقط. راجع قائمة المستلمين الصالحين كاملة؛ فالعضوية في مجموعة وحدها لا تحدد المستلمين المجهولين. افحص مسارات الإرجاع ومنع الحلقات، ولا تغيّر الأمان والتوجيه إلا بتفويض. قد تراعي قاعدة نقل ما يلي:

خطط لقاعدة النقل واختبرها قبل الانتقال إلى Internal Relay. يعتمد الترتيب والصلاحية وسلوك القبول على الإعداد الفعلي. تأكد من استمرار عمل المسارات والضوابط أثناء التغيير بدل تخفيف التحقق من المستلمين دون مراجعة.

الاستراتيجية 2: أنماط محددة باستخدام Postfix PCRE

تلتقط الأنماط المحددة عناوين معينة دون فتح النطاق لأي مستلم. تحدد تعبيرات نمطية للمتغيرات المتوقعة. يعتمد الرفض الفعلي للعناوين غير المطابقة أيضًا على التحقق من المستلمين وتصنيف النطاق والخرائط الأخرى. قد يقلل النهج العناوين المقبولة أثناء الاختبارات، لكنه لا يضمن حظر نسبة محددة من الهجمات.

يمكنك في Postfix استخدام خريطة أسماء مستعارة افتراضية مع PCRE (Perl Compatible Regular Expression) إذا كان دعمها مثبتًا. الأنماط التالية أمثلة تحتاج إلى اختبار المطابقات المرغوبة وغير المرغوبة والتحقق من فئات المستلمين؛ فعدم تطابق الخريطة لا يضمن الرفض بمفرده:

# /etc/postfix/virtual_pcre

# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/    sales-team@yourdomain.com

# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/   support@yourdomain.com

# No wildcard below = hard 550 reject for everything else

يُضبط التكامل في /etc/postfix/main.cf. انتبه: استبدال الإعداد بالتعيين التالي قد يزيل خرائط أسماء مستعارة قائمة. احتفظ بنسخة احتياطية، وادمج الخريطة الجديدة مع القديمة، وافحص الترتيب والأنماط والتحقق من المستلمين:

virtual_alias_maps = pcre:/etc/postfix/virtual_pcre

بعد تغيير مصرح به والتحقق من الإعداد، يمكنك إعادة التحميل: postfix reload

لتوسيع التغطية، أضف أنماطًا محافظة لعناوين شائعة بدل catch-all عام:

/^(info|contact|hello|team)@yourdomain\.com$/    info@yourdomain.com

تلتقط بذلك متغيرات مختارة وتحد من قبول العناوين العشوائية، بشرط إعداد بقية التحقق من المستلمين بصورة مناسبة.

متى يكون catch-all للنطاق مناسبًا

يناسب catch-all مهام محددة وواضحة الحدود. غالبًا ما تكون الأمثلة الثلاثة التالية مؤقتة؛ وتوجد استخدامات مبررة أخرى مع ضوابط مناسبة. أما catch-all الدائم غير المخطط له فليس حلًا افتراضيًا جيدًا.

استخدامات مناسبة:

• عناوين حملات قصيرة العمر: تستخدم promo-jan@ وpromo-feb@ وpromo-mar@ ولا تريد إنشاء كل عنوان يدويًا
• تهيئة العملاء: استقبال الرسائل قبل اكتمال الإعداد الرسمي للعناوين
• ترحيل نظام قديم: لا تتوفر بعد قائمة كاملة بالعناوين النشطة، وتريد تقليل فقد الرسائل أثناء الانتقال

ينبغي أن تكون مدة catch-all محدودة في هذه الأمثلة الثلاثة. عندما تعرف العناوين الصالحة، أنشئ صناديق أو أسماء مستعارة مناسبة، ثم قيّم إمكان إيقافه. إذا كنت تختار بين اسم مستعار وصندوق كامل، فاقرأ المقارنة بين الاسم المستعار للنطاق وصندوق البريد. الفروق التشغيلية مهمة.

مبرر غير مناسب: استخدام catch-all فقط لأنك لا تريد دفع $6 لكل مستخدم شهريًا مقابل ثلاثة أسماء مستعارة. لا تتطلب الأسماء المستعارة تراخيص مستخدم منفصلة لدى كل مزود. افحص أولًا شروط الخطة الفعلية. إخفاء مشكلة سعر بتوجيه معقد دون حاجة قد يخلق بعد ستة أشهر عملًا أكثر من فائدته.

TrekMail: إعداد مخطط بدل الحلول الالتفافية

توجد بعض إعدادات catch-all لأن الرسوم لكل مستخدم تجعل إدارة الصناديق الفعلية مكلفة. يستخدم نموذج TrekMail الموصوف تخزينًا مشتركًا وخططًا للحساب بسعر ثابت ضمن حدودها، بدل الرسوم لكل صندوق. لا يعني ذلك تسعيرًا عامًا لكل نطاق أو صناديق بلا حدود. افحص الأسعار والمزايا الحالية. قد تقلل خطة مناسبة الدافع المالي لاستخدام catch-all بدل أسماء مستعارة فعلية.

المثال التاريخي لخطة TrekMail Starter هو $3.50 شهريًا. افحص الأسعار والحدود والمزايا الحالية قبل إنشاء العناوين المطلوبة بدل فرز كل البريد عبر catch-all. في نموذج Nano الموصوف، تحتاج جميع الرسائل الصادرة، بما فيها الردود، إلى خادم SMTP خارجي خاص بك؛ أما الإرسال المُدار في الخطط المدفوعة فيعتمد على الصلاحيات الفعلية. يتطلب الترحيل وصولًا مفوّضًا إلى المصدر والتحقق من التوافق والنسخ والمزامنة النهائية، مع فحص جهات الاتصال والتقويمات على حدة. يتناول دليل إعداد البريد على نطاقك DNS وSPF وDKIM وDMARC والصناديق بترتيب مناسب.

قائمة تحقق قبل تفعيل catch-all

افحص جميع البنود قبل التفعيل. قد تؤدي الثغرات إلى عمل إضافي؛ ويعتمد أثرها على الإعداد والبريد الوارد:

1. التحقق من مستلمي SMTP مفعّل: رفض العناوين المجهولة خارج أنماط catch-all المقبولة عمدًا أثناء اتصال SMTP. وتجنب إشعارات غير مطلوبة إلى مرسلين قد تكون عناوينهم مزورة.
2. الردود التلقائية مضبوطة: تطبيق X-Auto-Response-Suppress: All على الرسائل المناسبة حيث يتوفر الدعم. اختبار ردود الغياب ومنع الحلقات؛ فالترويسة وحدها ليست ضمانًا.
3. صندوق المراجعة جاهز: صندوق مخصص لـcatch-all منفصل عن العمل اليومي، مع حدود سعة ومسؤول محدد.
4. تصنيف البريد المزعج مُراجع: تطبيق تصنيف حذر على الرسائل المرسلة إلى مستلمين مجهولين، ومراجعتها بانتظام وفق السياسة. عدم إسقاط البريد المشروع بصمت افتراضيًا.
5. SPF وDMARC مفحوصان: عند استخدام SRS، تحقق من أن SPF لنطاق مرسل المغلف المعاد كتابته فعلًا يسمح بعنوان IP المتصل. يتطلب DMARC نجاح واحد على الأقل من فحصي SPF وDKIM مع المحاذاة. قد ينجح DKIM السليم والمحاذي دون SRS، ولا يعيد SRS وحده المحاذاة إلى From الأصلي.
6. تفضيل أنماط PCRE المحددة: استخدام أنماط جزئية إذا دعمها MTA. عدم قبول عناوين عشوائية دون حاجة تجارية؛ واختبار بقية ضوابط المستلمين.
7. إشعارات تعذر التسليم مضبوطة: منع backscatter إلى مرسلين مزورين دون تعطيل الإشعارات المشروعة كلها. التعامل مع الرسائل المقبولة وفق سياسة المراجعة والاحتفاظ.

الخاتمة

يُعد catch-all للنطاق أداة مشروعة عندما تُخطط للمسارات وصندوق المراجعة والتحقق عبر SMTP والردود والإشعارات. قد يؤدي تفعيله دون ضوابط إلى backscatter وحلقات ومشكلات مصادقة عند إعادة التوجيه الخارجي. هذه المخاطر قابلة للفحص، لكن ليس كل استخدام محكومًا بالفشل خلال أسابيع قليلة. اضبط catch-all بصورة مقصودة أو لا تفعّله.

إذا استخدمت catch-all فقط لتجنب الرسوم لكل مستخدم، فراجع نموذج التكلفة أولًا. قد تتيح استضافة TrekMail ذات السعر الثابت الموصوفة الصناديق والأسماء المستعارة المطلوبة ضمن حدود الخطة. يصبح catch-all خيارًا واعيًا بدل حل التفافي. ابدأ تجربة مجانية، وافحص الشروط الحالية، وخطط للإعداد بعناية منذ البداية.