الخلاصة

  • اقترح RFC 1505 حقل Encoding اختيارياً يصف أجزاء جسم الرسالة، وعدد الأسطر، وسلسلة التحويلات المرتبة اللازمة لاسترجاعها. نجاح الوصف في توجيه فك الترميز لا يثبت هوية المرسل ولا يمنح إذناً بالفعل.
  • قدّم LZJU90 عدد البايتات الأصلية وفحص CRC للكشف عن التلف أو فك الترميز الخاطئ. كان ذلك دليلاً على سلامة محددة النطاق، لا مصادقةً على المرسل ولا موافقةً على تنفيذ الناتج.
  • أمكن لترميز FS حمل المالك والمجموعة وقائمة التحكم وكلمة مرور صريحة، كما أمكن لـSHAR حمل أوامر. ظل تحويل هذه البيانات إلى صلاحيات أو آثار محلية قراراً في النطاق الإداري للمستقبل.

فحصان ناجحان وسؤال بلا جواب

كان في RFC 1505 نوعان من العد يمكن الخلط بينهما بسهولة. يصف الرقم في حقل Encoding عدد أسطر النص المشفّر في جزء من جسم الرسالة. أما ذيل LZJU90 فيحمل عدد البايتات الأصلية وقيمة CRC التي ينبغي أن تتطابق بعد فك الضغط.

لكل فحص قيمة عملية. اختلاف عدد الأسطر قد يكشف اقتطاعاً أو فاصلاً فُهم على نحو خاطئ. اختلاف عدد البايتات أو CRC قد يشير إلى فساد أثناء النقل، أو تحويل غير صحيح، أو فقد حدث بين بوابات البريد وتحويلات ASCII وEBCDIC. هذه أدلة أدق من عبارة عامة مثل «تمت المعالجة».

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

إذا اختزلت الواجهة عدّ الأسطر، وعدّ البايتات، وCRC، والمصادقة، والإذن في علامة خضراء واحدة، فستحوّل سلامة النقل إلى سلطة متخيلة. السؤال «هل استعدنا البايتات المقصودة؟» يختلف عن «هل يحق لهذه البايتات أن تغيّر جهازنا؟».

كان الحقل خريطةً للتحويلات

قسّم RFC 822 رسالة البريد إلى ترويسة وجسم تفصل بينهما سطر فارغ. حاول RFC 1505 أن يصف أجزاء متعددة من الجسم وتحويلاتها داخل حقل Encoding اختياري، بدلاً من زرع بنية تحكم جديدة بين أجزاء النص قد تعرضها برامج القراءة القديمة كما هي.

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

عندما تتداخل التحويلات، يصبح ترتيب الكلمات حاسماً. يعالج مفكك الترميز الكلمات من اليسار إلى اليمين، بينما يكتبها المرمّز بعكس ترتيب العمليات التي نفذها. لذلك لا تعني السلسلة uuencode LZW tar أن ثلاث قدرات متاحة بأي ترتيب؛ إنها مسار بعينه نحو المادة الأصلية.

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

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

معرفة SHAR لم تمنح حق تشغيل الصدفة

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

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

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

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

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

سمات الملفات جاءت من فضاء إداري آخر

صُمم ترميز FS لتمثيل أدلة ومدخلات وملفات ومقاطع وبيانات من أنظمة مختلفة، منها Unix وDOS وVMS وPrimos وMacintosh. وكان يستطيع حمل اسم العرض والتعليق والنوع وأزمنة الإنشاء والتعديل والوصول والمالك والمجموعة وقائمة التحكم وكلمة المرور وحجم الكتلة والسجل والتطبيق المرتبط.

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

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

ربط $SYSTEM بمدير النظام المحلي قرار يمنح سلطة. تجاهله قرار يفقد جزءاً من القصد. وربطه بالمستخدم الذي فتح الرسالة يخلط الاستلام بالملكية. لا تصبح أي من هذه الخيارات آليةً محايدة لمجرد أن البرنامج يسميها «استعادة».

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

كلمة المرور الصريحة لم تعبر بسلطتها

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

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

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

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

لم تكن Signature دائماً توقيعاً تشفيرياً

في RFC 1505، كانت كلمة Signature تعني منطقة التوقيع العادية في نهاية رسالة بريد أو مقالة Usenet. يمكن أن تحتوي اسم المرسل أو قولاً مفضلاً، وكثيراً ما تضاف آلياً. ولذلك كان Text Signature وصفاً لجزء تحريري، لا نتيجة تحقق تشفيري.

ظهر PEM وPEM-Clear وPGP ككلمات مستقلة، لها صيغها الداخلية للتشفير أو التكامل أو كتل المفاتيح أو التواقيع المنفصلة. ومع ذلك، لا تكفي الكلمة الخارجية لإثبات الثقة. يلزم تحديد البايتات المشمولة، ونتيجة الخوارزمية، ومصدر المفتاح، والثقة المحلية بالاسم المدّعى.

لاحظ النص أيضاً أن نوعاً متداخلاً بعد PGP قد يكشف للمراقب إن كانت المادة نصاً أو معاملة EDI. نجاح الحماية لا يمحو كل معلومة سياقية.

لو عرض النظام كلمة «موقّع» فقط، لخلط بين خاتمة بشرية، ووجود شكل تشفيري، ونجاح حساب رياضي، وهوية يقبلها المستقبل. كل حالة تحتاج دليلاً منفصلاً.

التسجيل نسّق المفردات ولم يصادق على القدرة

طلب RFC 1505 تسجيل الكلمات التي لا تبدأ بـX- لدى IANA، وترك بادئة X- للاستخدامات الخاصة بالتطبيقات. يوفّر التسجيل اسماً مشتركاً ومساراً إلى وثيقة تشرح معناه، ويقلل احتمال استخدام الكلمة نفسها لعمليتين متعارضتين.

لكنه لا يثبت أن مفككاً معيناً يطبق العملية، ولا أنه يطبقها بلا عيب، ولا أن تشغيلها آمن أو مطلوب افتراضياً. يمكن للمستقبل أن يعرف الكلمة ولا يملك الوحدة اللازمة. ويمكنه أن يدعمها لكنه يعطلها، أو يفكها داخل منطقة عزل ولا يسمح بأي أثر تالٍ.

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

تجربة ظهرت إلى جانب MIME

صدر RFC 1505 في أغسطس 1993 بوصفه Experimental، وأبطل RFC 1154. ولم يحدد معياراً للإنترنت. أشارت ملاحظة IESG الخاصة به إلى وجود تقنية في مسار المعايير ضمن المجال نفسه، وأحالت إلى RFC 1341، أي MIME.

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

راجع RFC 2045 لاحقاً سلالة MIME عبر RFC 1521 وRFC 1522 وRFC 1590. لا يعني ذلك أن RFC 1505 كان نسخة مبكرة من MIME، ولا يثبت أن MIME أبطله رسمياً. كما لا تثبت دقة المواصفة انتشار تنفيذ أو تبنياً واسعاً.

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

ما تثبته المصادر وما لا تثبته

تدعم المصادر الأولية تركيب الحقل، وعدّ الأسطر، وترتيب الكلمات، وسمات FS، وتحذير SHAR، وفحوص LZJU90، وقاعدة التسجيل، والحالة التجريبية، وملاحظة IESG حول MIME. تسمح هذه الأدلة بالفصل بين التمثيل والسلامة والمصادقة والتفويض والأثر.

لكنها لا تحدد تنفيذاً بعينه يدعم كل الكلمات، ولا تقيس الانتشار، ولا تسجل هجوماً فعلياً عبر SHAR، ولا تثبت إمكان نقل هويات وقوائم وصول بأمان. ولا تسمح بالقول إن CRC يصادق على المرسل، أو إن Signature تعني توقيعاً تشفيرياً، أو إن التسجيل يبيح التنفيذ.

تفصيل المواصفة يثبت أن اقتراحاً دقيقاً كُتب. إثبات ما جرى على آلة فعلية يحتاج إلى سجل التنفيذ والتهيئة والسياسة والموافقة والنتيجة. هنا أيضاً لا تُختزل الكلمات في واقعها.

المصادر