الخلاصة
- يضع RFC 2034 الرمز
class.subject.detailقبل النص البشري في معظم ردود SMTP من فئات 2xx و4xx و5xx، ويشترط أن تتفق فئته مع فئة الرمز الأساسي. - يرسل الخادم الرمز حتى إن لم يستخدم العميل EHLO، ولا توجد آلية لطلبه أو رفضه. يصف المستند ذلك كاستثناء توافق محدود لا كسابقة عامة لتجاوز التفاوض.
- تفيد البنية في التصنيف وإعادة المحاولة والتوطين، لكنها تثبت فئة أعلنها خادم في جلسة بعينها، لا السبب الجذري ولا التسليم النهائي ولا القراءة ولا عدالة السياسة.
يمكن لردّين يحملان 550 أن يتطلبا إجراءين مختلفين. قد يكون العنوان غير موجود، أو يكون التوجيه ممنوعاً، أو تكون سياسة وصول قد رفضت الرسالة. الرقم التقليدي يمنح الآلة قراراً واسعاً، أما الجملة التالية فتختلف باختلاف المنتج والمشغل واللغة. تحويل كلمات تلك الجملة إلى خوارزمية يجعل أسلوب الخادم جزءاً هشاً من نظام الإرسال.
في أكتوبر 1996 وضع RFC 2034 طبقة صغيرة بين الرقم والجملة. لم يلغ رمز SMTP الثلاثي ولم يلغ النص الموجه إلى الإنسان. أضاف في أول النص فئة وموضوعاً وتفصيلاً. بقي الانتقال العام للحالة في الرقم القديم، وصارت الفئة الدقيقة قابلة للنقل بين الأنظمة، واستمر الشرح الطبيعي لخدمة القارئ.
بنية قابلة للتحقق داخل رد قائم
تعلن EHLO عن الامتداد بالكلمة ENHANCEDSTATUSCODES من دون معاملات، ولا يضيف الامتداد أفعال SMTP جديدة. الفئة هي 2 أو 4 أو 5، والموضوع والتفصيل من رقم إلى ثلاثة أرقام لكل منهما. يجب أن يقترن 2xx بـ2.X.X و4xx بـ4.X.X و5xx بـ5.X.X.
يمنع هذا الشرط إشارتين متعارضتين في السطر نفسه. يستمر الرمز الأساسي في قيادة منطق SMTP العام، بينما يقسم الموضوع والتفصيل الحالات داخل الفئة. تستطيع قوائم الانتظار واللوحات وفرق الدعم العمل على تصنيف مشترك بدلاً من البحث في عبارات متغيرة.
كما يمكن للواجهة أن تعرض شرحاً عربياً مبنياً على الرمز وتحفظ النص الأصلي كدليل. لكن الاتساق ليس صدقاً مستقلاً. ظهور 550 5.1.1 يثبت أن الخادم أعلن مشكلة دائمة في صندوق الوجهة؛ لا يفحص قاعدة بياناته ولا يثبت صحة السياسة أو نتيجة مسار آخر.
للاستثناءات معنى تشغيلي
تشمل القاعدة أسطر 2xx و4xx و5xx، باستثناء التحية الأولى والرد على HELO أو EHLO. أما 3xx فمستبعدة صراحة. لذلك يظهر 354 في حوار RFC من دون رمز محسّن، مع أنه رد صحيح يدعو العميل إلى إرسال البيانات.
يجب أن تحتفظ القياسات بالأمر السابق وموضع الرد في الجلسة. اختبار يطالب برمز محسّن بعد كل رقم SMTP سيعتبر السلوك الصحيح خطأ. وعدّ الرموز المنفصلة عن سياقها يخلط الاستثناء القانوني بالنقص الحقيقي.
تعرض الأمثلة 2.1.0 و2.1.5 و5.1.1 و5.7.1 و2.6.0 و2.0.0. هي تثبت طريقة عمل البنية عبر الحوار، لكنها لا تثبت وصول الرسالة إلى صندوق بريد أو ظهورها أو فتحها. «قبول الرسالة» انتقال لدى خادم مستلم، وليس نهاية سلسلة التسليم.
امتداد يعمل من دون اختيار العميل
يرسل الخادم المتوافق الرموز سواء استخدم العميل EHLO أم لم يستخدمه. لا أمر للتشغيل ولا للانسحاب. هذا مخالف للنمط المعتاد الذي يعلن فيه الخادم قدرة ثم يطلب العميل استخدامها.
مصدر التوافق هو حصر التغيير داخل حقل النص الذي كان على العميل القديم قبوله أصلاً. يستطيع التطبيق القديم التعامل مع البادئة الجديدة كجزء من الجملة. ورأى المؤلفون أن ضعف تطبيق أخطاء SMTP آنذاك يبرر منح جميع العملاء تصنيفاً أوضح.
لكن RFC يغلق باب التعميم: هذه حالة خاصة جداً ولا يجوز أن تبرر تغييرات مستقبلية كبيرة من دون إعلان الخادم وأمر تمكين من العميل. غياب التفاوض هنا آمن بقدر ما يبقى التغيير داخل تركيب قديم ولا ينشئ سلوكاً جديداً واسعاً.
عدة أسطر وإعلان واحد
إذا امتد الرد إلى أسطر عدة، يجب أن يبدأ نص كل سطر بالرمز المحسّن نفسه. يكرر المثال 5.7.1 في سطرين يحملان 551، كما تشترط قواعد SMTP العامة ثبات الرمز الأساسي.
يسمح التكرار بتحليل السجلات سطراً سطراً من دون فقد التصنيف، ويمنع الرد الواحد من تبديل معناه التشغيلي في منتصفه. يمكن للنص أن يضيف تفاصيل، لكن الفئة المعلنة واحدة.
التفصيل يخلق أيضاً سطح كشف. يقر قسم الأمان بأن كل معلومات إضافية تكشف المزيد عن الخادم وقد تساعد على تجاوز الحماية. اسم مضيف داخلي أو وجود حساب أو مسار تحويل أو قاعدة ترشيح لا يصبح آمناً لمجرد أن حقل التشخيص يستوعبه.
لذلك ينبغي الجمع بين الاتساق وتقليل الإفصاح: تكرار الفئة الضرورية، وشرح ما يحتاجه الطرف البعيد للعمل، وعدم نشر منطق القرار الداخلي كله.
الرمز شهادة لا تدقيقاً في السبب
يمكن للسياسة المحلية وضع 4.X.X في قائمة إعادة المحاولة وإيقافها عند 5.X.X. ويمكن للموضوع والتفصيل توجيه الحالة إلى فرق العناوين أو السعة أو الأمن أو الإعداد. كما يكشف التاريخ تغير تصنيفات خادم بعد تحديث.
هذه استخدامات مشروعة لأنها تتعامل مع إعلان تمت ملاحظته. الرمز لا يبين لماذا فشل بحث داخلي، ولا يثبت أن المرشح أصاب، ولا يضمن استمرار السياسة غداً. حتى الفئة الإيجابية لا تثبت التسليم النهائي أو العرض أو القراءة.
يبني مثال RFC لاحقاً إشعاراً، ثم يذكر أن MTA المبلّغ حذف الرموز المحسّنة من بعض حقول التشخيص لتقليل الازدحام. الرد الحي وسجل قائمة الانتظار والإشعار اللاحق وملخص الواجهة آثار مختلفة؛ قد تحفظ كل طبقة معلومات أو تغيرها أو تسقطها.
أنشأ RFC 5248 لاحقاً سجل IANA لتجنب تعارض معاني الرموز. ينظم السجل المفردات ولا يضمن صحة حالة بعينها. قد يرسل برنامج معيب رمزاً مسجلاً للحدث الخطأ.
يحفظ الدليل القوي الطرف والوقت والأمر والرمز الأساسي والمحسّن والنص الكامل وحدود الأسطر ونتيجة المحلل والقرار المحلي. يمكن التحقق حتمياً من الصيغة والاتساق. أما السبب وشرعية السياسة والنتيجة النهائية فتحتاج إلى مصادر مستقلة. أعطى RFC 2034 للإعلان شكلاً مشتركاً، ولم يمنحه سلطة على ما لم يظهر على السلك.
المصادر
- سجل RFC 2034
- النص الكامل لـRFC 2034
- RFC 2034 في Datatracker
- بحث تصويبات RFC 2034
- RFC 1869 — امتدادات خدمة SMTP
- RFC 5321 — بروتوكول نقل البريد البسيط
- RFC 3463 — رموز حالة نظام البريد المحسنة
- RFC 5248 — سجل رموز SMTP المحسنة
- سجل IANA لرموز SMTP المحسنة
- Heng Lu — Minimum Initial Specification
- Heng Lu — Running-Code Primacy
- Heng Lu — On Reality Layers
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

