الخلاصة

  • كان RFC 2076 فهرساً معلوماتياً لا اعتماداً عاماً؛ فاحتفظ البريد وUsenet وبوابات X.400 والممارسات غير المعيارية بنطاقات وحالات مختلفة.
  • استبعد سمات مظروف النقل في SMTP وUUCP وNNTP وحقول أجسام PEM وMOSS الداخلية؛ لم تكن الترويسات تمثل المعاملة كلها.
  • تتدرج الأدلة من الظهور إلى التعريف ثم البروتوكول والحالة والقرار المحلي فالنتيجة المرصودة، ولا يقوم إيصال مرحلة مقام المرحلة التالية.

لم يخترع RFC 2076 ترويسة جديدة عام 1997، بل رسم حدوداً حول أسماء كانت الأنظمة تتداولها. قد يكون الحقل معيارياً أو تجريبياً أو مثيراً للخلاف أو غير مستحسن، وقد يخص Usenet أو بوابة X.400 أو يكون مجرد عادة شائعة بلا معيار.

الصيغة الواحدة لم تكن ولاية واحدة

جمع الفهرس بين بريد RFC 822 وأخبار RFC 1036 وتحويلات X.400 في RFC 1327. ظهور حقل للأخبار داخل رسالة بريد لا يجعله معياراً للبريد. كما أن X400-Received وAlternate-Recipient يحملان سياق البوابة ولا يكتسبان سلطة عامة عند الوصول إلى صندوق بريد.

حوّل RFC 3864 هذا الحذر لاحقاً إلى سجلين دائم ومؤقت، وسمح للاسم نفسه بقيود بروتوكول مختلفة. التسجيل المؤقت ليس إقراراً من IETF أو IANA. وحافظ RFC 4021 وسجل IANA الحالي على فصل البروتوكول والحالة والمرجع.

ما استُبعد رسم حدود الإثبات

لم يشمل RFC 2076 مظروف النقل ولا الحقول الأمنية داخل الجسم ولا ترويسات HTTP الخالصة. لذلك لا يحل سطر ظاهر محل عنوان الرجوع في النقل أو قائمة المستلمين الفعلية أو بيان داخل المحتوى.

يتطلب التحقيق حفظ الرسالة الخام والمظروف ومسار المرحّلات وتحويلات البوابة وقرار العميل كل على حدة. دمجها في قاموس واحد يمحو مصدر القرار ومسؤوليته.

كشف Apparently-To تكلفة الاستدلال

كانت بعض نسخ sendmail تضيفه من مستلمي المظروف حين يغيب To. وصفه RFC 2076 بأنه غير معياري وغير مستحسن، لأنه قد يكشف مستلمي النسخة المخفية. حوّلت الإضافة الآلية معرفة خاصة بطبقة النقل إلى محتوى يراه القارئ.

أما Reply-To فله تعريف معياري، لكن استعماله ظل خلافياً لأن الرد الشخصي ورد المجموعة وسياسة القائمة نيات مختلفة. وكان Errors-To وReturn-Receipt-To غير معياريين وغير مستحسنين؛ طلب الإشعار لا يثبت التسليم أو القراءة أو الأثر.

السلسلة السليمة هي: حدوث → مرجع تعريفي → سياق → حالة → معالجة → نتيجة.

المصادر