الخلاصة

  • ميّز RFC 1344 بين نقل البريد داخل بيئة متجانسة والعبور بين بيئات مختلفة. فإذا عدّل relay المحتوى، وجب أن يعترف بدور gateway وما يرافقه من مسؤولية.
  • أتاح MIME إرجاع رسالة مرفوضة كاملة، وتقسيم جسم كبير، ونقل مرجع خارجي، أو ترميز محارف لحمايتها. أما تحويل صيغة صورة فأنشأ تمثيلاً جديداً ولم يثبت التكافؤ.
  • أظهر trace التحويل واقتُرح حق منع للمرسل. وحفظت مواصفات لاحقة أيضاً حالة الفقد، والعنوان الأصلي والنهائي، والرمز العام والرمز المحلي كأدلة منفصلة.

حماية الحمولة ليست إعادة تأليفها

عند عبور بوابة بين ASCII وEBCDIC قد تضيع محارف معينة، حتى لو لم يرغب أحد في تغيير الرسالة. كان تطبيق base64 أو quoted-printable وسيلة لتعديل شكل النقل كي يمكن استرجاع البايتات الأصلية بعد فك الترميز. التغيير هنا يحمي الجسم من القناة.

أما تحويل GIF إلى JPEG لتقليل حجم البريد على وصلة بعيدة، فيختار تمثيلاً آخر. قد يوفر السعة، لكنه قد يفقد تفصيلاً ويفترض أن برنامج المتلقي يدعم الصيغة الجديدة. إنه ليس الدليل نفسه، حتى لو سمّت لوحة التشغيل الفعلين “conversion”.

بنى RFC 1344 هذا الفرق فوق خاصية أساسية في MIME: الرسائل المحسنة تستطيع المرور عبر مرافق النقل القائمة من دون أن تفهم تلك المرافق كل بنية في الجسم. لم تكن قدرة الخادم على القراءة أو التحويل شرطاً للحمل، ولذلك لم تمنحه القدرة الجديدة سلطة تلقائية للتعديل.

عرّف النص transport بأنه تحريك رسالة داخل شبكة بريد متجانسة تقريباً، وgateway بأنه تبادل البريد بين بيئات مختلفة بصورة جوهرية. كان تغيير المحتوى غير مقبول عموماً في الدور الأول، وقد يصبح ضرورياً في الثاني. وإذا أراد SMTP relay أن يعدّل رسالة بسبب تكلفة وصلة عابرة للقارات، فعليه إعادة تعريف نفسه بوابة.

يمكن للرافض أن يحفظ ما لا يفهمه

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

قدّم RFC 1344 مثالاً من نوع multipart: جزء يشرح السبب للإنسان، وجزء يضم الرسالة المرفوضة كاملة كـmessage/rfc822. لا يحتاج برنامج النقل إلى تفسير الصورة؛ يكفي أن يحافظ على حدود الرسالة ويضعها في غلاف صحيح.

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

نظم RFC 3464 لاحقاً Delivery Status Notification قابلة للمعالجة الآلية والقراءة البشرية. فصل حقول الرسالة عن نتيجة كل recipient، واحتفظ بالعنوان الذي حدده المرسل والعنوان النهائي بعد التحويل أو إعادة التوجيه. كما سمح بحمل status مستقل عن نظام النقل والرمز الأصلي للنظام الأجنبي. الترجمة تساعد المقارنة، والرمز المحلي يحفظ سبب العطل كما ظهر فعلاً.

المرجع القريب قد يقطع الطريق إلى الأصل

أعطى message/external-body البريد خياراً ألا يحمل البيانات الكبيرة، بل يذكر طريقة جلبها. عند حد بطيء يمكن للبوابة تنزيل الملف، أو نسخه إلى مخزن أقرب، أو تغيير الموقع المشار إليه.

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

واجه message/partial حداً آخر: حجم الرسالة. قد يقسم gateway الإرسال أو يجمع الأجزاء، بحسب الطرف الذي يعرف قدرة البيئة الأخرى. غير أن الحد الموجود في بقية المسار لم يكن معروفاً دائماً؛ قد يبني الوسيط قراره على تقدير. إنشاء أجزاء صحيحة لا يثبت وصولها كلها ولا إعادة تجميعها.

أما تحويل الصور، فكان خدمة ذات أثر مباشر في التمثيل. ذكر النص سهولة عرض GIF في بعض البيئات وصغر JPEG للنقل. لكنه اشترط ضمنياً توفر دعم الصيغة الجديدة ولم يثبت تطابق الصورة. سجل خرج صالح من converter يصف فعل الآلة فقط.

أثر التحويل يحدد صاحب الفعل

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

واقترح Content-Conversion: prohibited وpermitted للتعبير عن رغبة المرسل. بقي ذلك اقتراحاً في RFC Informational، وليس دليلاً على حقل موحد ومنفذ في كل مكان. وتوقع النص أن تفترض بوابات كثيرة الإذن عند غياب الحقل. كذلك مُنح الصوت للمرسل لا لكل متلقٍ.

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

حمل RFC 2156 في MIXER بين X.400 وRFC 822/MIME حالات أدق: منع التحويل، منع التحويل إذا وقع فقد، وسط غير مدعوم، تحويل مع فقد، وفشل التحويل. وأضاف gateway عنصراً يبيّن أن conversion حدث. كما ربط الدعم بالمقابلة الدلالية وغياب الفقد المهم. لا يثبت ذلك انتشار اقتراح 1992، لكنه يثبت أن كلمة “relayed” لا تكفي لوصف بوابة حقيقية.

نتيجة الإنسان تقع بعد حدود البروتوكول

ينشئ الأصل رسالة؛ يقبلها transport؛ تظهر قيداً؛ تختار البوابة إجراء؛ ينتج جسم جديد؛ يقبله أو يرفضه نظام آخر؛ تظهر نتيجة لكل صندوق؛ يحاول البرنامج العرض؛ ثم قد يستخدمه إنسان. هذه سجلات متعددة وليست حالة واحدة.

يمكن أن ينجح converter ويفشل decoder. يمكن أن تنجح جلسة SMTP ثم يفشل recipient. يمكن أن تكون النسخة القريبة قديمة. ويمكن أن يكون DSN صحيحاً من دون أن يقرأ أحد الرسالة.

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

المصادر

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