الخلاصة

  • ربطت RFC 1036 الأمر cancel بوجود المقالة ذات Message-ID على النظام المحلي؛ وإذا تعذر إلغاؤها، فلا ينبغي تمرير الطلب إلى الأنظمة المجاورة.
  • انتقلت رسالة التحكم عبر آلية مجموعات الأخبار العادية، لكن الإرسال كان مقصورًا على المؤلف أو مسؤول أخبار محلي، مع مقارنة محددة لحقول الرأس.
  • تصف الوثيقة قاعدة على مستوى كل مضيف، ولا تثبت اختفاء المقالة من جميع الخوادم أو الأرشيفات أو نسخ القراء.

التوزيع لا يمنح الأمر سلطة عامة

لم تكن مقالة Usenet نسخة واحدة في مكان واحد. كانت تنتقل بين مضيفين تديرهم جهات مختلفة، ولكل منهم حالة محلية لما يحتفظ به. لذلك تبدأ قاعدة cancel في RFC 1036 بسؤال بسيط: هل توجد المقالة ذات Message-ID المطلوب على هذا النظام؟

صدرت RFC 1036 في ديسمبر 1987، وصاغت cancel بوصفه رسالة تحكم موجهة إلى برنامج الأخبار. إذا كانت المقالة موجودة محليًا، أمكن إلغاؤها هناك. أما إذا عجز النظام عن تنفيذ الإلغاء، فينبغي ألا يمرر الطلب إلى الأنظمة المجاورة. يتوقف الطلب عند أول مضيف لا يستطيع اتخاذ الإجراء على نسخته.

هذا الحد يفصل بين وصول التعليمات وامتلاك السلطة. وصول رسالة التحكم إلى شبكة لا يعني أن كل مضيف يستطيع حذف محتوى لا يخزنه. ولم تنشئ RFC 1036 خدمة مركزية تتابع كل نسخة أو تثبت أن الإزالة تمت في كل مكان.

رسالة التحكم بقيت جزءًا من تدفق الأخبار

كان حقل Control اختياريًا؛ وإذا ظهر في المقالة، أصبحت رسالة تحكم بين مضيفات Usenet وليست مادة موجهة إلى القراء. ووفق RFC 1036، تنتشر هذه الرسائل عبر آلية مجموعات الأخبار نفسها التي تستخدمها المقالات العادية. كان بوسع المنفذين والمسؤولين اختيار المعالجة التلقائية أو إدخال الرسائل في قائمة انتظار، على أن تُعالج الرسائل اليدوية بسرعة. أما رسائل التحكم الفاشلة فتذهب إلى حساب usenet المحلي لا إلى منشئ الطلب.

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

من يرسل cancel وكيف يُتحقق منه

سمحت RFC 1036 لمؤلف المقالة أو لمسؤول الأخبار المحلي بإرسال الطلب. وتعتبر قيمة Sender هي المرسل المتحقق منه؛ وإذا غاب هذا الحقل، تستخدم From. ويجب أن يطابق المرسل المتحقق منه لرسالة cancel حقل Sender أو From في المقالة الأصلية. كما يسمح النص بأن يطابق المرسل المتحقق منه قيمة From أصلية غير متحقق منها.

تشرح RFC 822 وظيفة Sender عندما يرسل الرسالة شخص أو وكيل غير مؤلفها، ثم تستخدم RFC 1036 هذه الحقول في قاعدة الإلغاء. لكنها تظل مقارنة بين حقول رأس؛ ليست توقيعًا رقميًا ولا إثباتًا حديثًا للسيطرة على حساب. ما تثبته الوثيقة هو القيم التي ينبغي للبرنامج مقارنتها، لا أن العنوان يستحيل تزويره أو أن كل موقع نفذ هذا الفحص.

ما الذي تغير عن RFC 850؟

حدّثت RFC 1036 وثيقة RFC 850 واستبدلتها كي تعكس الإصدار B2.11 من برنامج News. كانت نسخة 1983 تسمح بالفعل بإلغاء المقالة الموجودة محليًا على يد مؤلفها أو مشرف محلي بصلاحيات مرتفعة. أما نسخة 1987 فتسمي الدور «مسؤول الأخبار المحلي» وتضيف صراحةً أن النظام الذي يعجز عن الإلغاء لا يمرر الطلب إلى الجيران.

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

نتيجة المضيف الواحد لا تصف بقية النسخ

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

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

المصادر والحدود

المصادر الأولية هي RFC 1036، ولا سيما قسما Control وCancel، وسابقتها RFC 850، وRFC 822 بشأن Sender. وهي تثبت نص المواصفات، لا معدل تبنيها أو سلوك كل خادم أو زمن الانتشار أو المصادقة التشفيرية أو المحو من كل الشبكة.