المستخدم التالي يحتاج إذناً جديداً، ولو بقي الاتصال

الخلاصة

• يسمح UNAUTHENTICATE لعميل إداري بإعادة اتصال IMAP إلى حالة غير موثقة ثم استخدامه لحساب مستخدم آخر. تستمر طبقة TLS، بينما يجب إنهاء حالة التطبيق المرتبطة بالمستخدم السابق.
• ليست العملية محواً شاملاً: لا تستأصل الرسائل من صندوق البريد المحدد، ولا تُبطل شهادة TLS، وتترك تفاعلاً مع IMAP ID تحدده جهة التنفيذ.
• قد يفحص الوكيل المصادقة الأولى فقط ثم يمرر الحركة دون فحص لاحق. عندئذ قد لا تسري قيوده على المصادقة التالية إذا كانت غائبة عن الخادم الخلفي. نجاح الدخول الثاني وحده لا يثبت استمرار الرقابة.

ما الذي كان ينتهي مع إغلاق الاتصال؟

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

يتيح RFC 8437 فصل هاتين الوظيفتين. ينهي UNAUTHENTICATE ارتباط التطبيق بالمستخدم، مع إبقاء TLS. وبذلك يمكن للعميل الإداري أن يعيد استعمال الاتصال بدلاً من تكرار العمل اللازم لإقامته وحمايته. الغرض مشروع ومحدد، لكنه لا يمنح أي عميل حقاً عاماً في الانتقال إلى أي حساب.

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

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

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

انتقال محدد لا خروج كامل

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

لا يقبل الأمر معاملات، وتكون استجابة النجاح OK. أما BAD فترتبط بحالات مثل استخدام الأمر في حالة غير صالحة، أو دون إعلان القدرة، أو بصياغة غير صحيحة. ويحظر المعيار استجابة NO. إذا عجز الخادم عن إعادة حالته إلى الوضع المطلوب، فيجوز له إرسال BYE غير موسومة وإغلاق الاتصال.

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

بعد ذلك يمكن استخدام AUTHENTICATE أو LOGIN بحسب القدرات المتاحة. وقد لا يعلن الخادم UNAUTHENTICATE إلا بعد المصادقة، لذلك يمكن أن يحتاج العميل إلى استعلام CAPABILITY جديد. عدم ظهور القدرة في الملاحظة الأولى لا يساوي بالضرورة غيابها عن الخادم.

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

اسم المستخدم ليس كل ما يتذكره الخادم

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

ينص RFC على إعادة حالة الامتدادات عند إعلان UNAUTHENTICATE واستخدامه، مع الاستثناءات المحددة لـ STARTTLS وID. ولا ينحصر الالتزام في الامتدادات التي كانت معروفة عند كتابة النص. أي امتداد مستقبلي يحمل حالة يضيف شيئاً يجب فحصه في الانتقال بين المستخدمين.

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

يعاد التعامل مع CONDSTORE كأنه غير مفعّل، وتُلغى كل الميزات التي فُعّلت عبر ENABLE. تصبح نتيجة SEARCHRES المحفوظة فارغة، وتعود LANGUAGE إلى i-default. ويقع ما يعادل CANCELUPDATE ضمناً على جميع سياقات البحث في الخادم، بينما يعود NOTIFY إلى سلوكه الأساسي المناسب.

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

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

الطبقات لا تنتهي كلها في اللحظة نفسها

القول إن «التشفير باقٍ» يختصر أكثر مما ينبغي. يحافظ UNAUTHENTICATE على TLS، لكنه يحدد نهايات منفصلة لطبقة أمان SASL.

في اتجاه إرسال العميل، تنتهي طبقة SASL مباشرة بعد CRLF الذي ينهي الأمر. وفي اتجاه إرسال الخادم، تنتهي بعد CRLF الخاص باستجابة OK. ولـ COMPRESS أيضاً حدود انتهاء مقابلة في الاتجاهين، وينتهي الضغط قبل SASL حيث ينطبق ذلك.

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

يوفر RFC 4422 الإطار العام لـ SASL، لكن لا يجوز إسقاط قواعد عامة تخص مسار مصادقة آخر على UNAUTHENTICATE دون تمييز. ما يحكم هذه العملية هو وصفها المحدد في RFC 8437. تحتاج مراجعة التنفيذ إلى إثبات حدود الطبقات المعنية، لا إلى الاكتفاء بنتيجة المصادقة النهائية.

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

الشهادة المستمرة ليست تفويضاً مفتوحاً

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

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

يصف RFC 8437 بقاء بيانات اعتماد عميل TLS مع قطع ارتباطها على مستوى التطبيق. يمكن لشهادة إدارية أن تتيح العمل لمصلحة مستخدمين متعددين عبر EXTERNAL عندما تسمح قواعد التفويض بذلك. لا يترتب على هذا أن كل شهادة تستطيع اختيار أي حساب.

ويورد النص حالة مشروطة يبدأ فيها اتصال imaps باستجابة PREAUTH مرتبطة بهوية افتراضية. للانفصال عن ذلك الارتباط ثم إجراء مصادقة بالوكالة عبر EXTERNAL، يجب أن تكون قدرة UNAUTHENTICATE معلنة. هذه علاقة محددة بين حالة أولية وقدرة متاحة، لا وصفاً لكل اتصال محمي.

بناء عليه، تتوزع أسئلة التحقق: ما بيانات الاعتماد التي بقيت؟ هل انتهى ارتباط التطبيق بالمستخدم السابق؟ من منح الحق في الهوية التالية؟ إثبات استمرار الشهادة لا يغني عن السؤالين الآخرين. والمطالبة بزوالها كي تُعد العملية ناجحة تناقض الهدف المعلن من الاحتفاظ بالقناة.

الاستثناء يحتاج وصفاً، لا إنكاراً

IMAP ID لا يمثل هوية مستخدم البريد في نظام المصادقة. يعالج RFC 2971 معلومات عن التنفيذ، مثل البرنامج، بينما يترك RFC 8437 التفاعل بين ID وUNAUTHENTICATE لما تحدده جهة التنفيذ.

لذلك لا تصح عبارة أن العملية تمحو كل أثر سابق. ينبغي تحديد أي معلومات ID تبقى وكيف تُستخدم. وفي المقابل، يحظر RFC 2971 تغيير التشغيل أو تحسينه أو رفض الوصول بناءً على تلك المعلومات. يمكن الإفصاح عن معلومات أقل، أو NIL، لكن لا يجوز تقديم معلومات كاذبة.

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

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

الوكيل الذي يراقب الدخول الأول فقط

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

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

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

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

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

حد الاستنتاج

لم تُرجع صفحات تصحيحات RFC 8437 وRFC 4422 وRFC 2971 سجلات مطابقة وقت البحث. يصف ذلك حالة المصادر التي جرى الرجوع إليها، ولا يثبت خلو التطبيقات الحالية من العيوب.

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

ويفرض التأكيد على أن يكون الواقع هو المنتج لا الترويج لموقف قيداً مقابلاً على الكتابة. المصادر تثبت قواعد وتحذيرات مشروطة. لا تثبت انتشار التنفيذ ولا مقدار الوفر ولا الحالة الأمنية لمنصة لم تُفحص.

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