الخلاصة

  • كان CLOSE ينقل اتصال IMAP من Selected إلى Authenticated، ويزيل نهائياً في الصندوق القابل للكتابة كل رسالة تحمل \Deleted، من دون إرسال استجابة EXPUNGE مستقلة لكل رسالة.
  • عرّف RFC 3691 الأمر UNSELECT لتحرير موارد الصندوق المختار والعودة إلى Authenticated من دون إزالة الرسائل. وهكذا صار الانتقال بين الحالات والقرار غير القابل للعكس فعلين منفصلين.

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

في IMAP حمل الأمر CLOSE معنى أثقل. إذا كان الصندوق مختاراً للكتابة، أزال الخادم نهائياً كل رسالة تحمل العلم \Deleted ثم أعاد الاتصال إلى حالة Authenticated. ربما كانت العلامات قد وُضعت في وقت سابق أو في جلسة أخرى. ومع ذلك صار فعل الخروج هو لحظة تثبيت المجموعة كلها.

أضاف RFC 3691 في 2004 الفعل المفقود. لا يأخذ UNSELECT معاملات. عند نجاحه يحرر موارد الصندوق المختار ويغادر Selected، لكنه لا يزيل أي رسالة بصورة دائمة.

الإضافة قصيرة، لكن ما فصلته كبير: التخلي عن سياق عمل ليس تفويضاً تلقائياً بتغيير البيانات على نحو لا يمكن الرجوع عنه.

الاختيار حالة بروتوكول لها كلفة

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

إنهاء الاختيار لا يساوي إنهاء اتصال TCP. قد ينتقل العميل إلى صندوق آخر أو يبقى موثّقاً لعمل لاحق. لذلك فالعودة إلى Authenticated انتقال مستقل ومفيد.

كان CLOSE يحقق الانتقال، لكنه ينفذ expunge أيضاً. لا يُظهر مخطط الحالات هذه الفروق دائماً؛ فقد يصل أمران إلى العقدة ذاتها فيما يترك أحدهما الرسائل ويزيلها الآخر.

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

قلة الاستجابات لا تعني قلة الأثر

يرسل EXPUNGE العادي استجابة غير موسومة لكل رسالة يزيلها. تستخدم الاستجابة message sequence number، وهو موضع يتغير مع زوال الرسائل السابقة. وهكذا تصف سلسلة الاستجابات إعادة ترتيب الصندوق المفتوح.

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

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

ويغيّر نمط الاختيار النتيجة. إذا فُتح الصندوق بـ EXAMINE أو كان للقراءة فقط، لا يزيل CLOSE رسائل ولا يعيد خطأ لمجرد عدم الإزالة. لذلك لا يكفي اسم الأمر ورمز النجاح؛ يلزم ربطهما بالصندوق والنمط والأعلام السابقة ومسار الخروج.

كان الخروج الآمن ممكناً بطريقة ملتوية

سمح IMAP4rev1 بإرسال SELECT أو EXAMINE لصندوق آخر، أو LOGOUT، من دون CLOSE سابق. كانت هذه الأفعال تنهي الاختيار الحالي ضمناً من دون expunge. إذن لم يكن كل خروج حذفاً.

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

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

قال UNSELECT القصد مباشرة: اترك الصندوق المختار، أبقِ الاتصال موثّقاً، ولا تنفذ expunge.

أعلنت capability المعنى قبل الاستعمال

كان خادم IMAP4rev1 يعلن capability باسم UNSELECT عندما يفهم التوسعة. يتحقق العميل أولاً ثم يرسل الأمر. رفض كلمة مجهولة ليس خروجاً ناجحاً؛ فقد يبقى الاتصال Selected وتظل الموارد مشغولة.

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

لا يمحو UNSELECT أعلام \Deleted، ولا يسترجع ما أزيل، ولا يمنع جلسة أخرى من العمل. قد تبقى العلامات عند الاختيار التالي، ويمكن لأمر لاحق مخوّل أن يثبتها. الأمر يحفظ نقطة القرار ولا يَعِد بحفظ أبدي.

أصبح الفصل جزءاً من IMAP4rev2

أدخل RFC 9051 الأمر في مجموعة IMAP4rev2 الأساسية. يسلك كل من CLOSE وUNSELECT الطريق من Selected إلى Authenticated، لكن أثر البيانات لا يتحد. الأول يزيل العلامات في الصندوق القابل للكتابة، والثاني لا يزيل شيئاً.

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

النمط عام. يمكن إغلاق اتصال قاعدة بيانات بعد commit أو rollback؛ ويمكن تحرير ملف بعد flush أو بعد إسقاط buffer. الحالة النهائية للاتصال واحدة، أما البيانات فمختلفة. القياس الذي يسجل النهاية وحدها يفقد القرار الذي وقع على الطريق.

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

فقدان التأكيد يترك نوعين مختلفين من الشك

قد يتلقى الخادم الأمر ثم ينقطع الاتصال قبل وصول النتيجة الموسومة. بعد UNSELECT يدور الشك حول بقاء حالة Selected. وبعد CLOSE يمتد إلى احتمال وقوع حذف دائم بالفعل. لذلك ليست إعادة آخر استدعاء آلياً خطوة محايدة.

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

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

المصادر