الخلاصة

  • وحّدت RFC 2342 اكتشاف قواعد التسمية لثلاث فئات من صناديق البريد: الشخصية، والخاصة بمستخدمين آخرين، والمشتركة.
  • لا يغني إعلان مساحة الأسماء عن أدلة LIST والوجود وACL وSELECT وFETCH والعرض والانتباه البشري.

أعطى الخادم مفتاح قراءة الخريطة

إذا أعاد الخادم مساحة شخصية بلا بادئة وفاصلها /، ومساحة للمستخدمين الآخرين تبدأ بـ ~، وNIL للمساحة المشتركة، يستطيع العميل تكوين الاسم ~mark/INBOX. لكنه لا يعلم من ذلك أن Mark موجود، أو أن صندوقه ظاهر للهوية الحالية، أو أن SELECT سيقبله.

هذه هي المهمة المحددة في RFC 2342. قبلها كان العميل يطلب من المستخدم أحياناً إدخال بادئة محلية. أعادت NAMESPACE ثلاثة مواضع مرتبة: Personal ثم Other Users' ثم Shared، ويحتوي كل موضع NIL أو قائمة من البادئات والفواصل.

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

كان حجب التعداد سلوكاً أمنياً مقصوداً

اقترحت RFC إضافة % إلى بادئة Other Users' ثم إرسال LIST. لكنها أوصت أيضاً بألا يكشف الخادم أسماء مستخدمين لم يمنحوا حق list access. يمكنه إرجاع المصرح بهم فقط، أو رفض النمط الواسع بـ NO وطلب اسم محدد.

في المثال، يفشل #Users/% ثم ينجح #Users/Mike/% ويعرض INBOX وFoo. لم تتغير مساحة الأسماء؛ تغيرت دقة السؤال وسياسة الإفصاح. فقائمة الحسابات نفسها قد تكشف معلومات سرية أو تمنح المهاجم نقطة بداية.

تجعل RFC 9051 الحد أوضح: تعيد LIST مجموعة فرعية من أسماء صناديق البريد المتاحة للعميل، وقد لا تعيد أي اسم. وقد يحمل الاسم \Noselect أو \NonExistent. كما قد تضم قائمة الاشتراكات اسماً لصندوق لم يعد موجوداً.

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

رؤية الاسم ليست صلاحية قراءة

تفصل RFC 4314 الحقوق: يتيح l الظهور في LIST/LSUB، ويتيح r تنفيذ SELECT/STATUS، ويتحكم s في حفظ Seen/Unseen. أما الإنشاء والإدخال والحذف والإفراغ وإدارة ACL فلها حقوق أخرى.

لذلك قد يكون الصندوق مرئياً وغير مقروء. تعرض RFC 9051 حالة يملك فيها المستخدم l من دون r: يظهر الاسم في LIST، لكن STATUS لا ينجح ويجب أن تعكس النتيجة عدم قابلية الاختيار. أضافت RFC 8440 إمكانية إرجاع MYRIGHTS مع LIST الموسعة، غير أن الصلاحية تظل احتمالاً للعمل، لا دليلاً على وقوعه.

يثبت نجاح SELECT شيئاً أقوى: دخل هذا الاتصال حالة selected وتلقى FLAGS وEXISTS وUIDNEXT وUIDVALIDITY. لكنه لا يثبت أن FETCH أعاد المتن، أو أن العميل عالجه، أو أن النافذة كانت ظاهرة، أو أن إنساناً قرأ الرسالة.

حتى \Seen ليس إيصال قراءة بشرية. يمكن أن يغيّره FETCH أو STORE أو المعاينة أو المزامنة الخلفية. يسجل البروتوكول حالة الرسالة، لا الفهم والانتباه.

كانت قوة المعيار في حدود ادعائه

أزالت RFC 2342 تخميناً من العميل من دون أن تتنبأ بنتيجة الأمر التالي. البادئة مدخل لبناء سؤال صالح؛ أما الجواب فيصدر عن حالة الصندوق والحقوق في تلك اللحظة.

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

دلّت NAMESPACE على كيفية الوصول إلى الباب. لم تثبت وجود الباب ولا قارئاً خلفه.