الخلاصة

  • كان كل وكيل Netnews يضع هويته في بداية Path، فيظهر أحدث مرحّل إلى اليسار وتنمو الرحلة عكس اتجاه القراءة.
  • استطاع المرسل استبعاد جار مذكور أصلًا قبل نقل المقال، بينما ظل سجل Message-ID المحلي مسؤولًا عن رفض النسخ الواصلة من اتجاه آخر.
  • لم تكن !! و! وPOSTED وMISMATCH وSEEN ادعاءً واحدًا؛ كما أن not-for-mail في الذيل لم يكن اسم مرحّل زاره المقال.

التصحيح بعد العودة لا يستعيد السعة

لنفترض أن A أرسل مقالًا إلى B ضمن شبكة تعتمد الغمر. بعد قبول المقال يعرضه B على الجيران المهتمين. إذا عرضه على A من جديد، فسيفحص A سجل Message-ID ويعرف أنه شاهد المقال ثم يرفض النسخة. تنتهي الحلقة منطقيًا، لكن الوصلة حملت بيانات كانت نتيجتها محسومة.

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

يفصل RFC 1036 بين الوظيفتين. يكفي تاريخ Message-ID لإيقاف الدوران، ثم يأتي Path كتحسين يمنع B خصوصًا من إعادة ما تلقاه فورًا إلى A. وهكذا لا تعيد هذه المقالة كتابة تاريخ هوية الرسائل؛ إنها تشرح قرار الجار السابق لنشوء النسخة المكررة على السلك.

أحدث خطوة كُتبت في أقصى اليسار

إذا استقبل B السلسلة A!X!Y!Z أضاف اسمه في المقدمة فصارت B!A!X!Y!Z. الحاضر إلى اليسار والبداية الأقدم إلى اليمين. يتغير الحقل أثناء المعالجة من دون أن يصبح المقال مقالًا جديدًا.

وصف RFC 850 هذه القاعدة منذ 1983. سمح بعلامات فصل متعددة، وكان الشكل يشبه مسارات البريد اليدوية في عالم UUCP. ولهذا وضع النص حدًا صريحًا: لا يُستخدم Path للرد، ولا ينبغي اعتباره عنوانًا بريديًا.

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

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

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

الذيل ليس آخر خادم في الرحلة

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

يفصل RFC 5536 نحويًا بين path-list وtail-entry. وقد يكون الذيل not-for-mail. العبارة ليست عطلًا ولا اسم جهاز؛ إنها إعلان بأن الموضع الذي يشبه العنوان قديمًا لا يصلح صندوق بريد.

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

كان NNTP وسيلة نقل، لا تفسيرًا للمسار

نظم RFC 977 عام 1986 توزيع الأخبار وقراءتها ونشرها فوق تدفق موثوق مثل TCP. واستبدله RFC 3977 عام 2006 بعقد أحدث. يحددان الحوار بين البرنامجين، ولا يجعلان Path قائمة جلسات TCP.

أما معمارية RFC 5537 فتفصل معالجة Netnews عن بروتوكول النقل الأساسي. قد يبقى المقال بعد إغلاق الاتصال، ويمر بين مكونات الحقن والترحيل والخدمة، أو يعبر بوابة إلى وسيط آخر. ما يسجله Path وكلاء أخبار في طبقة التطبيق، لا موجّهات IP.

ولا تختار السلسلة الوجهة التالية وحدها. لدى المشغّل أصلًا علاقات feed ومجموعات وDistribution وسياسات قبول. يوفر ظهور الهوية سببًا سلبيًا لعدم استخدام علاقة قائمة؛ أما غياب الاسم فلا ينشئ العلاقة ولا يمنح إذنًا.

حفظت المواصفة درجات اليقين بدل إخفائها

تطلب وثيقتا 2009 من مكونات خادم الأخبار أن تضع path identity. يُفضّل الاسم المؤهل بالكامل، ويمكن استعمال اسم آخر تضمن إدارته فرادته في دائرة الأقران المعنية. نجاح المقارنة يعتمد على اتفاق الجيران على الاسم وبدائله.

تعني !! أن الوكيل الواقع إلى اليسار تحقق، وفق معيار يرضيه، من هوية الجار إلى يمينه. أما ! المفردة فلا تتضمن هذا الادعاء. تسوية الشكلين أثناء التنظيف تضيف دليلًا لم يوجد.

يسجل POSTED موضع الحقن. ويعني MISMATCH أن الهوية المتوقعة من سياق الاتصال لا تطابق الهوية التي تصدرت المقال. أما SEEN فيحفظ المصدر المرصود عندما لا يريد المستقبل أو لا يستطيع التحقق منه بوصفه الهوية المعلنة. وقد يأتي المتوقع من هوية مصادقة النظير أو عنوان IP للاتصال.

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

لذلك يوصي RFC 5537 بألا تقبل المرحّلات المقالات إلا من وكلاء موثوقين للحد من تزوير Path وInjection-Info. الثقة تأتي من العلاقة والأدلة خارج الحقل، لا من الحقل نفسه.

عدم ظهور الاسم لم يكن تصريح عبور

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

يبقى تطابق Newsgroups وDistribution وصحة المقال والثقة والسعة والسياسة المحلية مستقلًا. ويبقى تاريخ Message-ID ضروريًا للنسخ القادمة من جهة أخرى. وتحتاج البوابات إلى دفاعات إضافية لأن التحويل بين الوسائط قد يفقد خصائص التتبع ثم يعيد حقن المحتوى.

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

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