الخلاصة

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

سلطة الاسم لا تصل إلى الواقعة

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

جاء RFC 5248 لمعالجة مشكلة مختلفة. فقد صمم RFC 3463 فضاء قابلاً للتوسع لرموز الحالة، لكنه لم يضع طريقة صريحة لتسجيل القيم الجديدة وتتبعها. ومع ظهور تعريفات متعارضة، أصبح هناك احتياج إلى سجل عام يمنع مجموعتين من استخدام الموضع نفسه لمعنيين مختلفين. لذلك أنشأ BCP 138 إجراءات IANA وحدّث وثائق كانت قد وسعت المفردات، ومنها RFC 4468 وRFC 4954.

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

ثلاثة جداول تفصل طبقات الدلالة

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

لا يحتوي السجل على عبارة قصيرة فقط. فهو يحفظ الرمز، والملخص أو النص النموذجي، والوصف، والمرجع وحالته المعيارية، ومقدّم الطلب، وجهة التحكم في التغيير. ويضيف للرموز المعدّدة حالة SMTP أساسية مرتبطة. هذه الحقول ترسم سلسلة مسؤولية للمعنى: من اقترحه، وأين شُرح، ومن يستطيع تصحيحه.

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

حتى عدم المعرفة له تمثيل محدود. X.0.0 هو الرمز الوحيد غير المحدد ويستخدم عندما لا يُعرف سوى فئة الرد. لا يمنح المشغل حق اختراع الموضوع أو التفصيل، بل يحفظ حد المعرفة كما هو.

الخبير يراجع تعريفاً لا تنفيذاً

تتبع القيم الجديدة سياسة Specification Required. طلب RFC 5248 أن تكون المواصفات غير المعيارية متاحة بسهولة، وجعل الغرض الأساسي تجنب الالتباس والتصادم من دون عوائق غير لازمة. ويشرح RFC 8126 الإطار الحالي الذي يجمع مواصفة عامة دائمة مع مراجعة خبير معيّن ينظر في الوضوح والاستقرار والجودة التقنية.

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

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

تُظهر القيم الأولية أن الأصل ليس متجانساً. فقد جمع RFC 5248 قيماً من وثائق منشورة وقيماً كانت الصناعة تستخدمها بلا مواصفة منشورة. ووضع بعض رموز الأمن تحت تحكم IESG. كما نقل معنى «Trust Relationship Required» من استعمال سابق لـ X.7.8 إلى X.7.14. يستطيع السجل إصلاح عنوان الدلالة، لكنه لا يثبت متى هاجرت كل البرمجيات ولا كيف ينبغي تفسير كل سجل تاريخي.

الفئة توجّه القرار ولا تجمّد الزمن

يعرّف RFC 3463 الفئة 2 على أنها نجاح ضمن إشعار حالة التسليم. وتشير الفئة 4 إلى فشل مؤقت مستمر قد تنجح بعده محاولة مستقبلية. أما الفئة 5 فتشير إلى فشل دائم يتطلب عادة تغيير الرسالة أو الوجهة.

هذه القواعد ضرورية للتشغيل البيني، لكنها لا تتنبأ بالمستقبل. يطلب RFC 5321 من عميل SMTP أن يتصرف وفق رمز الرد لا النص التفسيري. يتيح 4yz المحاولة لاحقاً في الظروف المناسبة، بينما يعني 5yz ألا تتكرر الطلبية نفسها من دون تعديل. ومع ذلك يعترف النص بأن حالة تبدو دائمة قد تُصحح لاحقاً.

لهذا لا يعد 4.x.x بنجاح إعادة المحاولة، ولا يثبت 5.x.x استحالة التغيير إلى الأبد. تحتاج السياسة إلى هوية الرسالة والمستلم ورقم المحاولة والزمن والخادم والمسار والرد اللاحق. الرمز مدخل إلى القرار وليس إيصالاً بنتيجته.

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

الإفصاح الأدق قد يكون أخطر

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

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

ابنِ سلماً للأدلة ولا تقفز إلى نهايته

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

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

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

المصادر