المسار الذي كان يتراجع عند كل مُرحِّل

الخلاصة

• كان source route في SMTP حالة متغيرة داخل الظرف: يستهلك كل مُرحِّل العنصر الأول الخاص به من forward-path وينقله إلى reverse-path.
• المسار ليس صندوق البريد المطلق، وظرف SMTP ليس حقلي To: وFrom: الظاهرين للقارئ. كما أن أسماء المسار لا توثّق المؤلف ولا تثبت المرور الفعلي بكل محطة.
• نقل MX وأسماء النطاقات ذات المعنى العالمي قرار الطريق المعتاد إلى MTA وDNS والسياسة المحلية؛ ظل الخادم يفهم الصيغة القديمة من دون أن تصبح أمراً ملزماً بالترحيل.

اسم اختفى من الأمام ولم يختف من المسؤولية

بعد أن يحدد العميل reverse-path في أمر MAIL FROM، كان يستطيع إرسال:

RCPT TO:<@ONE,@TWO:JOE@THREE>

يسمي RFC 821 وسيطة RCPT بـ forward-path. الجزء JOE@THREE هو صندوق البريد المطلق، أما @ONE,@TWO فهو source route الذي يصف كيفية الوصول إليه. جمعهما في سلسلة واحدة لم يجعلهما مفهوماً واحداً؛ المواصفة تحذر صراحة من الخلط بين الوجهة والطريق.

عندما يرى ONE نفسه في أول قائمة الطريق يحذف @ONE. يصبح الجزء المتبقي @TWO:JOE@THREE. وفي اللحظة نفسها يضيف ONE هويته إلى مقدمة reverse-path. لم تُمحَ المعلومة، بل تغير دورها: كانت توجّه مهمة لم تُنفذ بعد، ثم صارت جزءاً من مسار يمكن أن يحمل إخطار عدم التسليم إلى الخلف.

لهذا لم يكن العنوان الطويل مجرد طريقة كتابة. كانت فيه حالة تُستهلك تدريجياً، وحالة مقابلة تتراكم. كل مُرحِّل ينفذ انتقالاً محدداً بينهما مع انتقال عهدة الرسالة.

ظرف النقل لا يكتب خانة المؤلف

reverse-path في MAIL FROM قيمة تخص معاملة SMTP ومعالجة الفشل بعد قبول المسؤولية. ليس هو From: الذي يراه القارئ، ولا Reply-To:، ولا توقيعاً على هوية من كتب النص.

وبالمثل، لا يلزم أن يكون forward-path في RCPT TO نسخة من To: أو Cc:. قد تكون للرسالة الواحدة عدة وجهات في الظرف، وقد يختفي مستلم Bcc من المتن، وقد يذكر المتن عنواناً لا يستلم شيئاً في تلك الجلسة.

يفصل RFC 822 في route-addr بين route وaddr-spec، وينصح بتجنب source routing إلا لحاجة خاصة. وجود صيغة قريبة في تاريخ تنسيق الرسائل لا يلغي الحد الفاصل بين الرسالة وظرف نقلها.

إذن، حين نقل ONE اسمه إلى reverse-path لم يغيّر مؤلف الرسالة. وإذا احتفظ الأرشيف بالمتن ورؤوسه فقط، فقد يفقد المسار الذي تلقاه الخادم فعلاً. يجب حفظ الدليل مع طبقته وسياق تحوله.

قد يحتاج المُرحِّل إلى اسم آخر عند الجهة المقابلة

لم يطلب RFC 821 من ONE أن ينسخ الاسم الوارد كما هو. عند إضافته إلى reverse-path يستخدم الاسم الذي تعرفه به البيئة التي سيرسل إليها، لا بالضرورة الاسم المستعمل في البيئة التي استقبل منها.

كان ذلك ضرورياً للبوابات بين فضاءات تسمية ومجتمعات بريد مختلفة. تبدو القائمة التي كتبها المرسل خريطة مكتملة، لكنها تعتمد عند كل حد على تفسير محلي وقد تعيد التعبير عن هوية المُرحِّل.

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

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

لم يحوّل MX قائمة المُرحِّلات إلى قائمة أخرى

يعرّف RFC 974 سجل MX بوصفه ربطاً بين نطاق الوجهة ومبادلات بريد ذات تفضيلات. يستعلم MTA المرسل عن النطاق ويجرب المرشحين وفق القواعد والحالة المتاحة. يبقى المستخدم عند user@domain حتى لو تغيرت خوادم استقبال ذلك النطاق.

ليست سجلات MX نقاط عبور متسلسلة يجب المرور بها واحداً بعد آخر. ويحذر RFC 974 من مطاردة MX الخاص بـMX بصورة تكرارية لبناء مسارات مبالغ فيها. لذلك لا يصح وصف MX بأنه source route مخزن في DNS.

التغيير الحقيقي هو فصل الهوية المستقرة نسبياً عن قرار متغير. يسمي المستخدم الوجهة؛ يختار MTA الخطوة التالية وقت الإرسال باستخدام DNS والوصول والسياسة المحلية. يستطيع النطاق تغيير بوابته من دون تغيير عنوان كل صندوق.

ويختلف موضع الإصلاح أيضاً. قد تُنسخ source route قديمة في دفاتر العناوين والطوابير والأسماء المستعارة. أما تغيير MX فيجري في نقطة يديرها صاحب النطاق. خرجت صورة الطوبولوجيا من العنوان وصارت نتيجة قرار آني.

بدأ التقاعد بمنع إنشاء نسخ جديدة

يقول RFC 1123 إن Sender-SMTP ينبغي ألا يرسل source route صريحة من صيغة @...: في RCPT. كان الاختيار المعماري لصالح التسمية العامة: يكفي user@domain مع نطاق عالمي المعنى وMX للحاجة الأساسية.

مع ذلك ظل على Receiver-SMTP قبول الصيغة. القبول هنا يعني أن المحلل يفهمها، لا أن الخادم يمنح أي عميل خدمة relay بلا شرط. فإذا لم ينفذ المسار المطلوب أمكنه، ضمن شروط المعيار، محاولة التسليم مباشرة إلى النطاق الواقع يمين آخر @.

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

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

نجاح التحليل لا يمنح تصريح الترحيل

يمكن للخادم تحليل @ONE,@TWO:JOE@THREE تحليلاً صحيحاً ثم رفض المرور وفق هوية العميل أو الشبكة أو النطاقات المسموح بها أو سياسة مكافحة الإساءة. grammar وrelay authorization حاجزان منفصلان.

يصف RFC 2821 source routes بأنها deprecated. يجب أن تكون الخوادم مستعدة لاستقبال الصيغة، وينبغي عادة تجاهل الطريق، ويمكن رفض relay. وينبغي ألا ينشئها العملاء.

عند تجاهل الطريق لا ينبغي نسخ أسماء المحطات إلى reverse-path. انتقال الاسم من الأمام إلى الخلف في RFC 821 يخص نمطاً يستخدم الطريق القديم فعلاً، وليس سلوكاً عاماً لكل رسالة SMTP حديثة.

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

لذلك لا تكفي عبارة «قبل source route». هل قبل الصيغة فقط، أم المستلم، أم حق relay، أم المسؤولية بعد DATA؟ لكل نقطة معنى وتكلفة مختلفان.

بين جزر البريد كانت خريطة المستخدم ذات قيمة

يشرح RFC 1711 عام 1994 explicit source routing على أنه إدخال MTA الذي يريد المستخدم المرور به في العنوان. عندما تصل الرسالة إليه ينزع نفسه ويتابع ما بقي.

في عالم من «جزر البريد» ضعيفة الاتصال، قد يعرف المستخدم بوابة تصل إلى جزيرة بعيدة في حين لا توزع البنية التحتية تلك المعرفة عالمياً. كتابة الطريق في العنوان كانت تعويضاً عن نقص معلومات الوصول.

مع ازدياد ترابط الإنترنت، صار علم المستخدم بالطوبولوجيا غير ضروري في الاستخدام العادي وسريع التقادم. ويذكر RFC 1711 اختلاف معالجة العناوين بين المُرحِّلات سبباً إضافياً للتثبيط.

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

ينتمي percent hack ومسار UUCP بعلامة التعجب وتحويلات البوابات إلى الجوار التاريخي نفسه، لكنها ليست الصيغة نفسها ولا تنفذ بالضرورة انتقال forward/reverse ذاته. موضوع المقال محدد بـ@relay1,@relay2:user@host.

بقيت الصيغة بعد زوال سببها اليومي

يقرر RFC 5321 أن MX أزال الحاجة المعتادة إلى source routes الصريحة، وأن شرط Fully Qualified Domain Names أزال آخر مبرر عام مهم. لا ينبغي للعملاء استعمالها إلا في ظروف غير عادية مثل التشخيص أو مشكلة DNS خطرة ومؤقتة.

لكن الخوادم ما زالت تتعرف إلى الصيغة القديمة. يمكنها رفض relay، أو تجاهل الطريق ومعالجة الوجهة النهائية، أو استخدامه في نطاق ضيق وفق القواعد. وجود الصيغة في parser لا يعيد إليها موقعها كطريقة عادية جديدة.

ولا يضمن حذف الطريق إنقاذ الرسالة. اعتمدت بعض العناوين القديمة على اسم لا يفهم إلا في بيئة وسطية. بعد نزع المحطات قد يكون النطاق النهائي غير قابل للحل عالمياً. التوافق لا يخمّن فضاء تسمية محلياً مفقوداً.

لهذا لا تكفي خانة «مدعوم/غير مدعوم». هناك recognized وpreserved وignored وrejected وused. وقد ينجح النطاق النهائي أو يفشل، وقد تكون المسؤولية رُفضت في الجلسة أو قُبلت قبل فشل لاحق.

النص الذي يصف طريقاً لا يثبت أن الرسالة سلكته

وجود @ONE,@TWO في سجل يثبت وجود الأحرف في السجل. لا يثبت أن ONE استهلك الخطوة، أو أن TWO تلقى اتصالاً، أو أن THREE استلم الرسالة. يلزم لذلك سجل الجلسة والاستجابات وحل الخطوة التالية والطابور والزمن.

والعكس صحيح. ظهور JOE@THREE وحده بعد التطبيع لا يثبت أن الإدخال كان بسيطاً. ربما حذف MTA حدودي الطريق، أو حفظ الجامع صندوق البريد المحلل فقط، أو لم تحمل رؤوس المتن تلك المعلومة أصلاً.

يحفظ السجل القوي الوسيطة الخام، ونتيجة التحليل، وقرار use/ignore/reject، ونقطتي الجلسة، والخطوة التالية، والنتيجة. يمكن حفظ الشكل المطبع كقيمة مشتقة، لا بديلاً صامتاً عن الوارد.

حتى reverse-path الذي نما لا يصادق على المُرحِّلات. يؤدي وظيفة في إرجاع الفشل، ولا يضمن مروراً واحداً صادقاً ولا ملكية كل اسم. ينبغي ألا تتجاوز الاستنتاجات وظيفة الحقل المحددة.

حدود المصادر

تثبت RFC 821 وRFC 822 وRFC 974 وRFC 1123 وRFC 1711 وRFC 2821 وRFC 5321 الصيغة والقواعد والتحول التاريخي. لا تقيس الانتشار الحالي أو توافق المنتجات أو open relays أو الهجمات أو معدلات التسليم.

ولا تجعل source route في SMTP هي LSRR أو SSRR في IPv4. تشابه الكلمات لا يوحد الطبقة أو الكائن أو الجهة المعالجة أو حدود السلطة.