إعادة توجيه البريد عبر SRS: SPF وDMARC والحدود

تضبط إعادة توجيه contact@yourdomain.com إلى Gmail. تعمل لمدة أسبوع، ثم لا تصل بعض رسائل العملاء. قد تعرض السجلات 550 5.7.1 Unauthenticated email أو 550 5.7.26 This message does not have authentication information. تحتاج هذه الأخطاء إلى فحص، ولا تثبت وحدها خللًا في SRS. تعالج إعادة توجيه البريد عبر SRS مشكلة شائعة: يفتح خادمك اتصال SMTP جديدًا، بينما يبقى المرسل الأصلي في المغلف. إذا لم يسمح نطاقه بعنوان IP الخاص بك، فقد يفشل SPF. مع DMARC عند p=reject، قد يرفض المستلم الرسالة إذا لم ينجح أي من SPF وDKIM بنطاق متوافق مع From الظاهر. قد ينتج عن رفض SMTP إشعار بتعذر التسليم؛ لا تختفي الرسائل بصمت دائمًا.

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

ما هي إعادة توجيه البريد عبر SRS؟

تعيد إعادة توجيه البريد عبر SRS، أي Sender Rewriting Scheme، كتابة عنوان مرسل المغلف قبل إرسال الرسالة إلى وجهة جديدة. تستبدل نطاق المرسل الأصلي بنطاق خادم التوجيه في مسار العودة التقني. قد ينجح SPF إذا سمحت إعدادات DNS الحالية بعنوان IP المرسل فعليًا. يبقى From الظاهر كما هو. يعمل SRS على المغلف، وليس تشفيرًا؛ ويمكن للمستخدم قراءة Return-Path في الترويسات الكاملة.

يمكن دمج SRS في Postfix عبر خدمة postsrsd. تدعمه Microsoft 365 في مسارات إرسال وإعدادات هجينة معينة، وكذلك بعض المنصات المُدارة. يعتمد الدعم والإعداد على الإصدار والمسار والعرض الحالي. يساعد SRS في التعارض بين التوجيه التقليدي وSPF، لكنه لا يضمن اجتياز DMARC.

لماذا قد تفشل إعادة التوجيه: محطة SMTP الجديدة

تضيف إعادة التوجيه محطة SMTP جديدة. لا يفشل SPF عندها بالضرورة، لكن تغير عنوان IP المرسل قد يؤثر فيه. Header From وفق RFC 5322 هو المرسل الظاهر، مثل From: alice@client.com. أما مرسل المغلف وفق RFC 5321، MAIL FROM، فهو عنوان العودة التقني وهوية SPF. يغيب غالبًا عن العرض المعتاد، لكنه متاح في الترويسات الكاملة.

يوضح المثال التالي فشلًا ممكنًا، لا قاعدة عامة للحذف الصامت:

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

كيف يساعد SRS في SPF

تستبدل إعادة توجيه البريد عبر SRS نطاق مرسل المغلف بنطاق خادم التوجيه قبل الإرسال اللاحق. يفحص المستلم SPF لهذا النطاق. يتطلب النجاح تفويض عنوان IP المستخدم فعليًا. يبقى Header From كما هو، بينما يمكن معالجة إشعارات العودة عبر نطاق التوجيه. يجب إعداد ذلك وفق التنفيذ المستخدم.

مكونات عنوان SRS

عند تفعيل SRS، قد يتحول عنوان العودة البسيط إلى عنوان منظم تحميه قيمة تحقق تشفيرية:

قبل SRS: MAIL FROM: <alice@client.com>
بعد SRS: MAIL FROM: <SRS0=4fac=PM=client.com=alice@yourdomain.com>

عند إعادة توجيه ثانية (A → B → C)، قد يُستخدم SRS1. يعتمد التمثيل المتداخل على التنفيذ، ولا يقتصر ببساطة على قيمة التجزئة والطابع الزمني. يحد من النمو الإضافي مقارنة بتغليف سلسلة SRS0 كاملة مرارًا. يظل حد 64 حرفًا للجزء المحلي وفق RFC 5321 بحاجة إلى فحص؛ فلا يضمن ملاءمة أي عنوان.

لماذا لا يكفي SRS: توافق DMARC

يفعّل مسؤولون إعادة توجيه البريد عبر SRS ويتوقعون حلًا كاملًا. لكن نجاح SPF لا يضمن توافق النطاقات في DMARC. يتطلب DMARC نجاح SPF أو DKIM بنطاق متوافق مع Header From. بعد إعادة الكتابة، قد ينجح SPF لنطاق yourdomain.com، بينما يظل Header From على client.com. لا يتوافق النطاقان المختلفان في المثال. أما التوافق المرن فقد يسمح بنطاقات تشترك في النطاق التنظيمي.

إذا غاب SPF المتوافق، فقد يظل DKIM صالحًا ومتوافقًا ويحقق DMARC. قد تؤثر خوادم التوجيه في التوقيع إذا غيرت أجزاء موقعة، مثل:

• إضافة [EXTERNAL] إلى بداية سطر الموضوع إذا كان من الأجزاء الموقعة
• إدراج تذييلات مكافحة الفيروسات أو إخلاء المسؤولية في محتوى موقع
• تحويل ترميز 8 بت إلى 7 بت
• إعادة كتابة حدود MIME

يعتمد أثر التغيير في DKIM على الأجزاء الموقعة وقواعد توحيد الصيغة. إذا فشل مسارا المصادقة المتوافقان معًا، يفشل DMARC. قد يرشح المستلم الرسالة أو يرفضها وفق سياسته، رغم صحة إعادة كتابة SRS.

دعم إضافي عبر ARC (Authenticated Received Chain)

يتيح ARC وفق RFC 8617 للوسيط تسجيل نتائج المصادقة التي رصدها فعلًا وحمايتها بالتوقيع، سواء نجحت الفحوص أم فشلت. يستخدم ثلاث ترويسات:

• ARC-Authentication-Results: تسجل نتائج SPF/DKIM/DMARC الملحوظة عند الاستقبال
• ARC-Message-Signature: توقع ترويسات مختارة وجسم الرسالة وقت التوقيع؛ وقد تبطلها تغييرات لاحقة ذات صلة
• ARC-Seal: توقيع تشفيري يربط سلسلة ARC ويحميها

إذا وثق المستلم بجهة توقيع ARC وبالسلسلة الصالحة، فقد يراعي معلوماتها عند اتخاذ قرار القبول رغم فشل DMARC لاحقًا. لا يحول ARC ذلك إلى نجاح DMARC ولا يضمن القبول. تقيّم Gmail توقيعات ARC في الإنتاج منذ 2019؛ ويظل قرار الثقة للمستلم.

في إعادة التوجيه خلال 2026، تُعد إعادة توجيه البريد عبر SRS وحفظ المحتوى الموقع وARC عناصر مهمة للفحص. ليست كلها ضرورية دائمًا، ولا تكفي مجتمعة لضمان النتيجة. يحدد المسار والمصادقة وسياسة المستلم ما يلزم.

إعداد SRS بحسب المنصة

يختلف الإعداد كثيرًا. يحتاج Postfix إلى تكامل مناسب، وتعتمد Microsoft 365 على المسار وسياسات الأمن، ولدى Google Workspace سلوك وحدود خاصة. افحص الإصدارات والإعدادات الحالية بدل افتراض تفعيل افتراضي أو تغييرات إلزامية للجميع.

Postfix على Linux تديره بنفسك

يستخدم تكامل شائع لـPostfix خدمة postsrsd. يجب التحقق من مثال تثبيت الحزمة التالي وفق التوزيعة والإصدار قبل أي تطبيق مفوض:

apt-get install postsrsd

مثال خرائط TCP التالي في /etc/postfix/main.cf طريقة تكامل أقدم. احتفظ بنسخة من الإعدادات وادمج الخرائط الجديدة مع القائمة بعناية. افحص الإصدار والصياغة المدعومة والمنافذ والمقابس والمسارات والصلاحيات:

sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

مهم: يعتمد المتغير SRS_EXCLUDE_DOMAINS في /etc/default/postsrsd على الإصدار. افحص النطاقات المحلية والمسارات التي ينبغي استثناؤها. قد تسبب الاستثناءات الناقصة كتابة غير مرغوبة، أو حلقات عند اجتماعها مع قواعد أخرى؛ لكنها لا تسبب كل مشكلة بالضرورة. اختبر الدخول والخروج وإشعارات العودة.

Microsoft 365

قد تطبق Microsoft 365 نظام SRS في مسارات خروج مدعومة. تحقق من السلوك الحالي في البيئات الهجينة والموصلات. يشير 550 5.7.520 Access denied, Your organization does not allow external forwarding إلى سياسة إعادة توجيه صادرة، لا خلل مثبت في SRS.

غيّر هذه السياسة الأمنية فقط بتفويض ومراجعة ضيقة للنطاق المطلوب، لا لتجاوز الحماية. قد تتغير الواجهة وخيارات التوجيه التلقائي. الأمر التالي مثال لموصل؛ افحص وجود المعامل ودعمه في إصدار PowerShell الفعلي ونوع الموصل:

Set-OutboundConnector -Identity "Outbound to Gateway" -SenderRewritingEnabled $true

Google Workspace

لدى Google Workspace سلوك خاص لإعادة التوجيه. من مجالات الفحص التالية، وهي ليست حصرية له:

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

تشخيص أخطاء إعادة التوجيه عبر SRS

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

الفحص 1: Return-Path

مثال دون إعادة كتابة SRS ظاهرة: Return-Path: <original@protonmail.com>
مثال مع إعادة كتابة SRS: Return-Path: <SRS0=xxxx=yy=protonmail.com=original@yourdomain.com>

قد يشير Return-Path غير المعدل إلى غياب التكامل أو توقف الخدمة أو استثناء مقصود للمسار. لا يثبت وحده تعطل postsrsd. افحص الطريق الذي سلكته الرسالة فعلًا.

الفحص 2: Authentication-Results

ابحث عن spf=pass والنطاق الذي فُحص. إذا بقي dmarc=fail، فلا يوجد SPF أو DKIM ناجح ومتوافق. قد يغيب DKIM أو يكون غير صالح أو يستخدم نطاقًا غير متوافق رغم صحة التوقيع. افحص المحتوى الموقع والتغييرات والتوافق بدل افتراض تلف الجسم تلقائيًا.

الفحص 3: DNS

dig yourdomain.com TXT +short

افحص SPF لنطاق التوجيه وإمكان وصول إشعارات العودة. MX شائع، لكن غيابه قد يتيح مسارًا ضمنيًا عبر A/AAAA. قد تراعي بعض الجهات استقبال النطاق للارتدادات؛ وجود MX وحده لا يثبت ذلك.

الفحص 4: سجلات Postfix

grep "srs_forward" /var/log/mail.log

قد تشير hash mismatch أو timestamp expired إلى مفاتيح مختلفة بين العقد أو تبديلها أو مشكلات الوقت والإعداد أو التأخير أو إعادة استخدام عناوين قديمة. لا تثبت وحدها هجوم replay. راجع السياق الكامل.

متى تفضل صندوقًا مباشرًا على إعادة التوجيه

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

قارن النهجين ومتطلباتهما الفعلية:

تصف TrekMail خططًا بتخزين مشترك للصناديق والنطاقات بدل رسوم مستقلة للصندوق. تدفع لخطة محدودة، لا للتخزين وحده أو استخدام غير محدود. قارنها بـإعادة توجيه معتادة إلى Gmail، أو اقرأ اعتبارات التوجيه بالأسماء المستعارة. تساعد مقارنة الاسم المستعار للنطاق بالصندوق في القرار الأساسي.

عند الاستقبال المباشر في صندوق TrekMail، تُزال محطة التوجيه الخارجية هذه، فلا يلزم إعداد SRS وARC لهذا الاستقبال. قد تحتاج إليهما مسارات أخرى. يساعد المساعد الموصوف في SPF وDKIM وDMARC، لكنه لا يستبدل التفويض والاختبار. خادم MX المعتمد للاستقبال ليس مرسل SMTP مفوضًا تلقائيًا.

جرّب TrekMail مجانًا: يتوفر Nano دون بطاقة في العرض المذكور، وتقدم Starter تجربة لمدة 14 يومًا مع SMTP مُدار، وتبدأ أسعارها المعلنة من $3.50 شهريًا. راجع الأهلية والمزايا والأسعار والشروط الحالية، بما فيها مزود SMTP الخاص وبياناته.

ملخص

تُعد إعادة توجيه البريد عبر SRS عنصرًا مهمًا في 2025-2026، لا متطلبًا عامًا لكل مسار. دون إعادة كتابة قد يفشل SPF في محطة التوجيه. قد يسبب DMARC الصارم رفضًا إذا غاب أيضًا DKIM صالح ومتوافق. مع SRS، قد ينجح SPF لنطاق التوجيه دون توافق مع From الأصلي. قد يظل DKIM صالحًا ومتوافقًا ويحقق DMARC.

يحتاج SRS في Postfix إلى تكامل مناسب للإصدار واستثناءات مفحوصة. في Microsoft 365، يعتمد السلوك وأي تغيير مفوض للسياسة على المسار والدعم الحالي؛ مثال PowerShell ليس تعليمات عامة. في Workspace، تحقق من الحصص والتوجيه والسجلات الفعلية بدل افتراض التعليق في كل حالة.

قد يساعد SRS وتوقيعات DKIM المحفوظة وARC معًا، دون ضمان تسليم موثوق في كل حالة. قيّم العناصر اللازمة لمسارك، أو اختر صندوقًا مباشرًا في الوجهة المطلوبة وتجنب محطة التوجيه الإضافية.