الخلاصة

  • أتاح RFC 1524 لبرامج بريد متعددة مشاركة قواعد mailcap: حملت الرسالة Content-Type، لكن ترتيب الملفات المحلية والمطابقة والاختبار هي التي اختارت العرض أو الإنشاء أو التحرير أو الطباعة.
  • في دلالات UNIX تحولت القاعدة إلى سطر أوامر لـ Bourne shell تُستبدل فيه قيم النوع أو أسماء ملفات مؤقتة. لا تثبت المطابقة ولا نتيجة الاختبار الصفرية ولا انتهاء العملية سلامة المحتوى أو أصالته أو موافقة المستخدم.

الاسم المشترك لم يفرض برنامجاً مشتركاً

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

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

كان الاتفاق الرقيق هو تمثيل العلاقة بين اسم النوع والفعل المحلي. يعلن المرسل تفسيراً، لكنه لا يعيّن البرنامج الذي يكتسب سلطة التنفيذ على جهاز آخر.

السياسة الفعلية كانت ترتيب البحث

تكوّن الإعداد من وصل افتراضي لعدة ملفات mailcap. يفوز أول إدخال يطابق Content-Type، ويوفر العملية المطلوبة، وينجح في حقل test= الاختياري.

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

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

قد يشغّل test= برنامجاً معقداً لاختبار بنية الجهاز أو نظام النوافذ أو وجود الصوت. عودة الصفر قالت إن القاعدة قابلة للاستخدام في البيئة. لم تقل إن وحدات البايت القادمة فُحصت أو أصبحت مأمونة.

دخلت قيم الرسالة إلى نص قابل للتنفيذ

عرّف الملحق أوامر UNIX كأسطر كاملة مقصودة لـ Bourne shell، بما يعادل سبقها بـ /bin/sh -c. استُبدل %t بنوع الوسيط، و%{name} بمعامل Content-Type، و%n بعدد الأجزاء، و%F بسلسلة من الأنواع وأسماء الملفات، و%s بملف يحتوي جسم الرسالة.

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

غيّر %s أيضاً مسار البيانات. بدونه تستقبل أوامر العرض والتحرير الجسم من الدخل القياسي. ومعه قد ينشئ وكيل البريد ملفاً مؤقتاً. حذر RFC من افتراض بقاء الملف بعد خروج الأمر؛ وكان على برنامج يستمر في الخلفية أن يحفظ ما يحتاجه أولاً.

سمح nametemplate باسم ينتهي مثلاً بـ .gif لبرامج تعتمد على اللاحقة. لكنه لم يتحقق من المحتوى، أو هوية المرسل، أو سلامة الفتح.

للإنشاء سلسلة مسؤولية أخرى

أنتج أمر compose بيانات يضع عليها برنامج البريد نوع القاعدة. أما composetyped فاستطاع إخراج Content-Type ورؤوس مرتبطة بنفسه. وظلت تهيئة ترميز النقل مسؤولية المستدعي ما لم يعلن المنتج المرمّز ذلك صراحة.

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

قابلية التوسع لم توزّع الثقة

نبّه RFC 1524 إلى أن الآلية قد تسهّل الوقوع في مشكلات أمن MIME، ودعا المنفذين ومديري mailcap إلى الحذر عند اختيار برامج للتشغيل التلقائي. لم يوثق هجوماً معيناً أو منتجاً معيباً. دليله أضيق: لا يتحول الاسم البعيد إلى فعل قوي إلا لأن سياسة محلية يملكها طرف ما ربطتهما.

نقّحت RFC 2045 و2046 و2048 MIME، ثم حدّث RFC 6838 تسجيل أنواع الوسائط. يمنح التسجيل اسماً ووثائق مشتركة، لكنه لا يثبت وجود معالج لدى المستلم، ولا القاعدة التي فازت، ولا إذن التنفيذ.

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

المصادر