إعادة التوجيه باستخدام SRS: إعداد PostSRSd وARC

تبدو إعادة توجيه البريد سهلة: تضبط تحويلًا وتنتهي المهمة. لكن من دون إعادة التوجيه باستخدام SRS، أي مخطط إعادة كتابة المرسل، قد يفشل SPF. تخيّل أن bank.com يرسل رسالة إلى عنوان معاد توجيهه على خادمك، فيمررها الخادم إلى الوجهة. يأتي الاتصال من عنوان IP الخاص بك، بينما يبقى مرسل المغلف على bank.com. إذا لم يسمح النطاق بعنوانك، يفشل SPF. ومع سياسة DMARC p=reject، قد تُرفض الرسالة عند غياب توقيع DKIM صالح ومتوافق أيضًا. قد يحدث رفض SMTP أو يصدر إشعار بتعذر التسليم؛ فالرسالة لا تختفي صامتة في كل حالة.

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

ما الذي تفعله إعادة التوجيه باستخدام SRS فعليًا

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

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

مستويان لهوية مرسل البريد

لإعداد SRS بصورة صحيحة، يجب التمييز بين حقلين منفصلين للعنوان. يفحص SPF مستوى المغلف؛ وعند تغير خادم الإرسال، قد لا يبقى التفويض مناسبًا للاتصال الجديد.

• مرسل المغلف (RFC 5321 MAIL FROM): عنوان الإرجاع الذي تستخدمه خوادم البريد لتوجيه إشعارات تعذر التسليم. يتحقق SPF مما إذا كان عنوان IP للاتصال مخوّلًا بالإرسال لهذا النطاق. ويمكن فحص مرسل المغلف أيضًا في Return-Path ضمن الترويسات الخام.
• From في الترويسة (RFC 5322 From): العنوان الذي تعرضه برامج البريد. يتحقق DMARC من التوافق مع نطاق واحد على الأقل اجتاز مصادقة SPF أو DKIM. يترك SRS هذا الحقل دون تغيير.

يوضح المثال التالي نتائج SPF عند إعادة التوجيه مع SRS وبدونه، وفق تفويضات النطاقات المبينة:

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

صيغة SRS: معنى المكونات

قد يبدو العنوان المعاد كتابته باستخدام SRS معقدًا، لكن لكل مكوّن وظيفة. يساعد فهمه في التحقيق في أخطاء سجلات الإرجاع وسلاسل التسليم التي تمر بعدة محطات.

تبدو إعادة الكتابة في أول محطة باستخدام SRS (SRS0) كما يلي:

SRS0=Hash=Timestamp=OriginDomain=OriginLocalPart@AnchorDomain

المكونات:

• Hash: رمز مصادقة HMAC مقتطع يُنشأ بمفتاح سري محلي، وتستخدم بعض التطبيقات SHA1. يصعّب تزوير عناوين إرجاع SRS على نطاقك. من دون تحقق مناسب، قد تُستغل عناوين SRS0 التي تبدو صحيحة لإرسال إشعارات تعذر تسليم غير مرغوبة. تعتمد الحماية على الآلية وإدارة المفاتيح.
• Timestamp: مرمّز باستخدام Base32 في هذا المثال، مع نافذة صلاحية قابلة للضبط تبلغ نحو 7-21 يومًا. يمكن رفض العناوين المنتهية. يحد ذلك من بعض مخاطر إعادة الاستخدام، لكنه لا يزيلها بالكامل.
• Origin: البيانات اللازمة لاستعادة المرسل الأصلي عند تعذر التسليم. يستقبل خادمك الإشعار، ويستعيد العنوان الأصلي، ثم يعيد توجيه الإشعار إلى المرسل الصحيح.
• AnchorDomain: النطاق الذي تتحكم فيه. يجب أن يسمح سجل SPF له بالخادم الوسيط، وأن يتوفر مسار إرجاع قابل للوصول لاستقبال إشعارات تعذر التسليم. يُستخدم MX عادةً لهذا الغرض؛ وفي ظروف معينة يمكن أن يعمل مسار ضمني عبر A أو AAAA أيضًا.

عند إعادة التوجيه لاحقًا، قد يتحول SRS0 إلى SRS1:

SRS1=NewHash=PreviousAnchorDomain==SRS0_Suffix@NewAnchorDomain

يحد SRS1 من نمو الجزء المحلي للعنوان. يظل حد 64 محرفًا في RFC 5321 مهمًا؛ ولا تضمن الآلية الالتزام به في كل سلسلة. عند فشل إعادة توجيه متعددة المحطات، افحص طول العنوان، إضافة إلى التوجيه والمصادقة.

التكامل مع Postfix: إعداد PostSRSd

يُعد PostSRSd خيارًا شائعًا لتكامل SRS في أنظمة Linux/Postfix. توفر خدمة تعمل في الخلفية عناوين مغلف معاد كتابتها إلى Postfix عبر واجهات ربط مناسبة. يجب أن تتوافق الأمثلة التالية مع الإصدار المثبت فعلًا. افحص صيغة الإعداد ومسار المقبس وأذونات الوصول وطريقة الربط بإعدادات Postfix الحالية قبل تطبيق التغييرات.

الخطوة 1: متطلبات النطاق المرجعي

جهّز النطاق المرجعي قبل تعديل ملفات الإعداد. يظهر هذا النطاق في مرسلي المغلف الذين يعيد خادمك كتابتهم. أهم المتطلبات:

• سجلات MX: تُوجّه إشعارات تعذر التسليم إلى هذا النطاق. تحقق من أن مسار الإرجاع يستقبل الرسائل فعلًا. قد يؤدي غياب الاستقبال إلى ضياع الإشعارات. تصف RFC 5321 أيضًا التسليم عبر MX ضمني باستخدام A أو AAAA في ظروف معينة؛ لذا لا يثبت غياب MX صريح وحده عدم إمكانية الوصول.
• سجل SPF: تفحص خوادم الوجهة SPF لهذا النطاق مقابل عنوان IP المرسل. إذا لم يكن مسار الإرسال الفعلي مخوّلًا، قد يفشل SPF رغم تفعيل إعادة الكتابة بواسطة SRS.
• سمعة جيدة: قد يضر البريد المزعج المعاد توجيهه بسمعة عنوان IP والنطاق المرجعي، ويسهم في الإدراج في قوائم الحظر. ليس هذا حتميًا، لكن SRS لا يعزلك عن البريد الذي تمرره.

# Verify SPF record exists for your anchor domain
dig relay.yourdomain.com TXT +short
# Expected output - must include your server IP:
"v=spf1 ip4:203.0.113.10 -all"

# Check MX records exist for bounce delivery
dig relay.yourdomain.com MX +short

الخطوة 2: إعداد PostSRSd

بحسب الحزمة والإصدار، قد تكون الإعدادات في /etc/default/postsrsd (Debian/Ubuntu) أو /etc/postsrsd/postsrsd.conf. تحقق من الملف المستخدم والصيغة المدعومة، بما فيها استثناءات النطاقات التي تختلف بين الإصدارات. لا يؤدي غياب قائمة الاستثناءات وحده بالضرورة إلى حلقة توجيه:

# Domain that appears in SRS-rewritten envelope senders
SRS_DOMAIN=relay.yourdomain.com

# Secret key path
# In a multi-server cluster, this file MUST be identical on all nodes.
# If nodes have different secrets, they can't validate each other's bounces.
SRS_SECRET=/etc/postsrsd.secret

# Exclusion list - critical config, don't skip this
# Without it, Postfix rewrites local-to-external mail too,
# causing routing confusion and potential delivery loops.
SRS_EXCLUDE_DOMAINS=yourdomain.com,client-one.com,client-two.com

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

openssl rand -base64 32 > /etc/postsrsd.secret
chmod 600 /etc/postsrsd.secret

الخطوة 3: التكامل مع Postfix

يُضبط التكامل في /etc/postfix/main.cf. يعرض المثال التالي socketmaps في PostSRSd 2.x وTCP في الإصدار 1.x. لا تنقله دون تكييف: تحقق من مسار المقبس الفعلي والأذونات وإمكانية الوصول وصيغة الإصدار المثبت:

# PostSRSd 2.x - modern installs (unix socket maps)
sender_canonical_maps = socketmap:unix:srs:forward
sender_canonical_classes = envelope_sender
recipient_canonical_maps = socketmap:unix:srs:reverse
recipient_canonical_classes = envelope_recipient

# PostSRSd 1.x - legacy installs (TCP)
# sender_canonical_maps = tcp:localhost:10001
# sender_canonical_classes = envelope_sender
# recipient_canonical_maps = tcp:localhost:10002
# recipient_canonical_classes = envelope_recipient

بعد التحقق من الإعداد، يمكنك إعادة تشغيل الخدمتين ضمن نافذة صيانة مناسبة:

systemctl restart postsrsd
systemctl restart postfix

قد لا يكفي SRS وحده: ARC كإضافة

قد يعالج SRS مشكلة SPF لنطاق المغلف الجديد، لكنه لا يحقق تلقائيًا توافق نطاقات DMARC. يتطلب DMARC توافق نطاق اجتاز SPF أو نطاق توقيع DKIM صالح مع From في الترويسة. بعد إعادة كتابة SRS، يصادق SPF في المثال على relay.yourdomain.com لا client.com. من دون هذا التوافق، يبقى توقيع DKIM صالح ومتوافق هو المسار لنجاح DMARC.

قد تبطل إعادة التوجيه DKIM. يمكن أن تؤدي إضافة بادئة “External Sender” إلى الموضوع، أو روابط إلغاء الاشتراك في التذييل، أو تغيير حدود MIME إلى إبطال التوقيع الأصلي إذا تأثرت أجزاء موقعة ولم تستوعب قواعد توحيد الصيغة التغيير. إذا غاب بعدها توافق SPF وتوقيع DKIM صالح ومتوافق، يفشل DMARC وقد يرفض المستلم ذو السياسة الصارمة الرسالة.

من الإضافات الممكنة ARC، أي Authenticated Received Chain، المحدد في RFC 8617. يستطيع الوسيط توثيق نتائج المصادقة التي رصدها فعلًا عند الاستلام بتوقيعات. وقد يراعي المستلم الذي يثق بجهة توقيع ARC والسلسلة هذه المعلومات عند اتخاذ قرار بشأن فشل DMARC الحالي. لا يصلح ARC توافق النطاقات ولا يضمن التسليم.

يضيف ARC ثلاث ترويسات إلى الرسالة المعاد توجيهها:

• ARC-Authentication-Results: نتائج المصادقة التي رُصدت فعلًا عند الاستلام، وليست بالضرورة فحوصًا ناجحة
• ARC-Message-Signature: يوقع ترويسات مختارة وجسم الرسالة بحالته وقت إنشاء توقيع ARC
• ARC-Seal: يربط مجموعة ARC تشفيريًا بالسلسلة عبر المحطات

يعالج SRS المغلف، ويوثق ARC سياق المصادقة. في بيئات DMARC الصارمة، مثل Google أو Microsoft، قد يفيد الاثنان. ليسا مطلوبين في كل حالة، ولا يكفيان معًا لضمان التسليم. عند غياب توافق SPF وتوقيع DKIM صالح ومتوافق، لا يجعل SRS وحده DMARC ينجح.

المرجع المعياري لـSPF، الذي يعالج SRS مشكلة إعادة التوجيه فيه، هو RFC 7208.

أخطاء خاصة بالمزودين يجب معرفتها قبل النشر

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

قد يستهلك خطأ M365 550 5.7.520 وقتًا طويلًا إذا تعاملت معه كمشكلة SRS. في هذا السيناريو، تمنع سياسة أمان في المستأجر المرسل إعادة التوجيه الخارجي قبل خروج الرسالة منه. لا يصلح SRS أو ARC على خادم لاحق ذلك. تتطلب التغييرات في بوابة Microsoft Defender أذونات إدارية مناسبة وتفويضًا من المؤسسة.

التحقق من عمل إعادة التوجيه باستخدام SRS

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

1. افحص ترويسة Return-Path

أرسل رسالة اختبار من حساب خارجي، مثل ProtonMail، إلى عنوان إعادة التوجيه. افتح المصدر الخام للرسالة في الوجهة وابحث عن سطر Return-Path:

• Return-Path: <SRS0=...@yourdomain.com> → تظهر إعادة كتابة SRS لهذه الرسالة؛ افحص نتائج المصادقة أيضًا
• Return-Path: <alice@protonmail.com> → لا تظهر إعادة كتابة؛ افحص الاستثناءات ومسار الإرسال وتكامل الخدمة

2. افحص DNS للنطاق المرجعي

# SPF record must cover your server IP
dig relay.yourdomain.com TXT +short

# MX record must exist so bounces can arrive
dig relay.yourdomain.com MX +short

3. افحص سجلات Postfix

grep -E "srs_forward|canonical" /var/log/mail.log | tail -50

تحقق من أن Postfix يستعلم من خدمة SRS ويستقبل عناوين معاد كتابتها؛ تعتمد تفاصيل السجلات المتاحة على الإعداد ومستوى التسجيل. قد تشير “Connection refused” إلى توقف الخدمة أو عنوان خاطئ أو مشكلات في المقبس والشبكة. افحص، ضمن نقاط أخرى، systemctl status postsrsd والواجهة المضبوطة وقواعد الجدار الناري عند انطباقها.

4. اختبر إمكانية الوصول وTLS

قد تظهر مشكلات SRS وTLS في صورة أخطاء تسليم متشابهة. لذلك افحص الاتصال الشبكي وSTARTTLS أيضًا:

openssl s_client -connect gmail-smtp-in.l.google.com:25 -starttls smtp

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

متى تتوقف عن إعادة التوجيه وتبدأ استضافة الصناديق

تخلق SRS وARC والنطاق المرجعي وإدارة المفاتيح واستثناءات النطاقات ومراقبة السمعة عبئًا تشغيليًا حقيقيًا. تستخدم مؤسسات كثيرة إعادة التوجيه لتجنب رسوم التراخيص لكل صندوق لدى المزودين الكبار. تعيد توجيه sales@ إلى صندوقك الشخصي وتوفر في المثال ترخيصًا بقيمة $6 شهريًا. ما يبدو مناسبًا لعنوان واحد قد يصبح مكلفًا تشغيليًا عند عشرة عناوين.

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

تبلغ تكلفة خطة TrekMail Pro الموصوفة $10 شهريًا، وتوفر 100 نطاق و50GB من التخزين المشترك. تحقق من الأسعار والحدود والمزايا الحالية. استضف sales@ وsupport@ وinfo@ كصناديق IMAP فعلية دون رسوم لكل مستخدم وفق النموذج الموصوف. تستغني عن محطة إعادة التوجيه الإضافية وصيانة SRS الخاصة بها. ويبقى التسليم المباشر والتخزين مرتبطين بالإعداد والحصص وقرارات المزودين.

إذا احتجت إلى إعادة التوجيه، مثل تجميع عدة نطاقات في وجهة واحدة، فإن الخدمة المُدارة الموصوفة في Pro وAgency تنفذ إعادة كتابة SRS وتوقيع OpenARC على الخادم. تحقق من الدعم الحالي. تضبط عنوان الوجهة في اللوحة؛ ولا تضمن المعالجة على الخادم توافق DMARC أو قبول الرسالة. لا تعني Nano مع BYO SMTP تلقائيًا استحقاق إعادة التوجيه المُدارة. إذا مررت البريد عبر بنيتك الخاصة، يكون SRS مهمًا فيها؛ ويجب أن تلائم أمثلة PostSRSd إصدارك وبنيتك.

للمسار المحدد من نطاق خاص إلى Gmail، يفصّل دليل إعادة توجيه بريد النطاق إلى Gmail الأخطاء الخاصة بهذه الوجهة وخطوات التحقق.

الخلاصة المختصرة

تعيد إعادة التوجيه باستخدام SRS كتابة مرسل المغلف كي يفحص SPF نطاق الخادم الوسيط. قد ينجح الفحص إذا سمح هذا النطاق بعنوان IP المرسل بصورة صحيحة. لا تفشل كل رسالة معاد توجيهها من دون SRS. يُعد PostSRSd تكاملًا ممكنًا مع Postfix، باستخدام نطاق مرجعي قابل للوصول وسجل SPF مناسب ومفتاح سري واستثناءات نطاق ملائمة وخرائط في main.cf. افحص الإصدار والصيغة. يمكن أن يضيف ARC سياقًا عند إبطال DKIM أثناء النقل، لكنه لا يصلح غياب توافق DMARC.

بعد كل تغيير في الإعداد، افحص الترويسات الخام ونتائج المصادقة الفعلية. عندما يتجاوز عبء تشغيل SRS ما توفره من رسوم التراخيص، قد تكون الاستضافة المباشرة أنسب. افحص خطط TrekMail والشروط الحالية لعرض Nano الموصوف دون بطاقة. يعتمد التفعيل على DNS والإعداد، وليس فوريًا في كل حالة. توفر Pro إعادة توجيه SRS مُدارة وARC ضمن النطاق الموصوف إذا أردت تفويض هذه المعالجة.