الخلاصة

  • اشترط RFC 3462 أن تكون multipart/report حاوية MIME الخارجية، وأن تضم بالترتيب شرحاً إلزامياً للبشر ثم سجلاً إلزامياً ذا نوع محدد للآلة، مع جزء ثالث اختياري يعيد الرسالة الأصلية أو مقطعاً مفيداً منها.
  • جعل الشكل التقرير قابلاً للتعرف، لا موثوقاً بالضرورة. يعلن report-type النوع الفرعي للجزء الثاني، لكن تقريراً مزوراً مطابقاً للبنية قد يضلل القارئ أو يدفع الأتمتة إلى إجراء ضار.

حادثة واحدة وقراءتان مختلفتان

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

وضع RFC 3462، المنشور في يناير 2003، هذا التصميم. يثبت النص الخام وسجل محرر RFC وصفحة Datatracker وتاريخ الوثيقة ومراجعها والإحالات اللاحقة إليها وبحث التصويبات حدود السجل العام. حل النص محل RFC 1892، وحول غلاف إشعار بعينه إلى عائلة عامة لتقارير MIME.

كان يجب أن تكون multipart/report نوع المحتوى الخارجي الأبعد في الرسالة. وإلى جانب boundary المطلوب للأجزاء المتعددة في RFC 2046، كان report-type إلزامياً. تسمي قيمته نوع MIME الفرعي للجزء الثاني. وهكذا تستطيع البرمجية فحص الترويسة الخارجية، وتعرف أن الكائن تقرير وما السجل الآلي المتوقع فيه قبل قراءة الجسم كله.

كان الترتيب جزءاً من المعنى

الجزء الأول إلزامي وموجه للإنسان. يمكنه استعمال أي نوع MIME محدد في معيار، واختيار اللغة وترميز المحارف المناسبين، بل واستخدام multipart/alternative لتقديم أكثر من صيغة. لم تكن هذه المرونة ثغرة؛ فالشرح المفيد يتغير بحسب الجمهور.

الجزء الثاني إلزامي أيضاً لكنه مخصص للمعالجة الآلية. يسجل حدثاً من أحداث التعامل مع الرسالة ضمن نوع وسائط مسجل، وقد يحمل تفاصيل تفيد المختص. في إشعار حالة التسليم استخدم RFC 3464 النوع message/delivery-status. غير أن الحاوية العامة لم تحدد متى يطلب SMTP الإشعار، وهي مهمة RFC 3461، ولم تعرف رموز الحالة المحسنة التي تناولها RFC 3463. كان RFC 3462 يحدد مكان الادعاء الآلي ونوعه، لا حقيقة التسليم بمفرده.

أما الجزء الثالث فاختياري. يحمل الرسالة الأصلية أو جزءاً منها يساعد على التشخيص والربط. عند غياب طلب صريح لمستوى الإرجاع كانت التوصية إعادة الرسالة كاملة، لكن ذلك يستهلك النطاق وقد يكشف المحتوى. إذا لم يكن مسار العودة آمناً لبيانات ثمانية البتات أو الثنائية، أمكن إعادة الترميز إلى MIME قانوني بسبعة بتات أو إعادة text/rfc822-headers فقط. تعود تلك الترويسات إلى تقليد RFC 822، لكنها ليست رسالة كاملة ولا يصح تسميتها message/rfc822.

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

التعرف لا يمنح الأصالة

سهل الموضع الخارجي اكتشاف التقرير من Content-Type. وفر سجل IANA لأنواع الوسائط فضاء أسماء مشتركاً. واستخدم الغلاف لاحقاً لإشعارات تصرف الرسالة في RFC 3798، التي نقحها RFC 8098، ولحالات التسليم المدولة في RFC 6533.

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

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

يساعد منظور Heng Lu اللاحق عن طبقات الواقع على فصل الوثيقة المستلمة وتفسير المحلل وحدث نظام البريد والقرار الإداري. وتوجه أولوية الشيفرة العاملة فعلاً النظر إلى شجرة MIME الحقيقية والمولد والتحقق والمستهلك الآلي. هذه عدسات تحريرية لاحقة، وليست دليلاً على نية خاصة لدى مؤلفي RFC.

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

المصادر