المعرّف الذي عبر الجلسة ولم يعبر ولادة صندوق البريد من جديد: لماذا احتاج IMAP إلى UIDVALIDITY

الخلاصة

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

الأمر الصحيح وصل إلى رسالة لم يخترها المستخدم

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

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

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

موضع العنصر ليس هويته

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

لكن محو الرسالة السادسة يجعل السابعة هي السادسة، ويزحزح كل ما يليها. يمكن للرقم نفسه أن يشير إلى رسالتين مختلفتين في وقتين مختلفين. شرح RFC 2060 هذه القاعدة في IMAP4rev1، وأبقاها RFC 9051 في IMAP4rev2.

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

منح IMAP4 الرسالة ذاكرة منفصلة عن ترتيبها

نشر RFC 1730 في ديسمبر 1994 تعريف IMAP4 لإدارة صناديق بعيدة وإعادة مزامنة العملاء بعد الانقطاع. عرّف UID بوصفه عدداً من 32 بت، متزايداً داخل الصندوق، غير ملزم بالتتابع من دون فجوات، وقابلاً للبقاء بين الجلسات.

أصبح بوسع العميل ربط حالة «مقروء» أو إجراء مؤجل برسالة من دون مقارنة كل الأجسام عند كل عودة. لكن الاستمرار الذي يصفه البروتوكول يجب أن تنفذه طبقة تخزين حقيقية. بعض المخازن القديمة لم يكن فيها موضع دائم لـ UID؛ وقد يعيد برنامج خارج IMAP ترتيب الملفات؛ أو يحذف صندوق ثم ينشأ صندوق آخر بالاسم نفسه؛ أو تعيد عملية استرجاع المحتوى من دون بيانات الهوية.

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

UIDVALIDITY يحدد الجيل ولا يسمّي الصندوق

يعرض كل صندوق قيمة UIDVALIDITY. إذا لم تعد UID القديمة مستمرة، وجب أن تكون القيمة الجديدة أكبر من السابقة. يمكن اشتقاقها من وقت الإنشاء أو من عدّاد متزايد. ليست هناك وصفة وحيدة؛ الالتزام هو أن يميز العميل الجيل الجديد من الحالة التي حفظها.

حذّر RFC 2683 من سوء فهم شائع: UIDVALIDITY ليس معرّف صندوق البريد. يجوز لصندوقين أن يحملا القيمة نفسها، وUID فريد داخل صندوقه فقط. لذلك لا تكفي ثنائية UIDVALIDITY وUID لصنع هوية عامة من 64 بت. النطاق الصحيح يضم اسم الصندوق أيضاً.

ألزم RFC 3501 ثم RFC 9051 بأن تشير ثلاثية اسم الصندوق وUIDVALIDITY وUID إلى رسالة واحدة غير متبدلة على الخادم. لا يجوز أن يتحول الجسم أو الغلاف أو التاريخ الداخلي أو الحجم أو البنية إلى محتوى رسالة أخرى تحت الثلاثية نفسها. تبقى العلامات قابلة للتغيير لأنها حالة تشغيلية. وبعد محو الرسالة لا يعاد UID ذاته في الجيل نفسه.

لا تأتي فرادة المعرّف من طول الرقم، بل من حدوده ومن منع إعادة استخدامه ومن القدرة على إعلان نهاية صلاحيته.

كان على المخزن الناقص أن يعلن نقصه

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

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

كلما كان إعادة تنفيذ العمل غير المتصل أكثر آلية، ازدادت ضرورة فحص الجيل قبل التنفيذ.

إبطال الذاكرة يسحب سلطة النية القديمة

رتب RFC 4549 خطوات عميل IMAP غير المتصل. عند فتح الصندوق يقارن العميل UIDVALIDITY التي أعادها الخادم بالقيمة المحلية. إذا اختلفتا، وجب أن يفرغ ذاكرة الصندوق، ويحذف الإجراءات التي تشير إلى UID القديمة، ويعاملها كإجراءات فاشلة.

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

ويظل الإبطال محلياً في صندوق واحد. ينتقد RFC 2683 عدّاد UID واحداً للخادم كله، لأنه يستهلك فضاء 32 بت أسرع وقد يحول نفاداً واحداً إلى تغيير أجيال كل الصناديق. النطاق الأصغر يحصر الضرر.

حمل الرابط شرط تقادمه معه

سمح RFC 2192 عام 1997 لعنوان IMAP بأن يحمل اسم الصندوق وUIDVALIDITY وUID. ينبغي للبرنامج الذي يفتحه أن يقارن الجيل المحفوظ بالحالي كي يعرف أن المرجع أصبح قديماً.

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

المزامنة السريعة بدأت من فحص الهوية

مع الصناديق الكبيرة والاتصالات المحمولة أصبح الفحص الكامل مكلفاً. جمع RFC 7162 بين CONDSTORE وQRESYNC، واستخدم تسلسل التعديل لتتبع تغييرات العلامات وVANISHED للإبلاغ عن UID المحذوفة. قد ينجز العميل المزامنة في رحلة واحدة.

لكن أول قيمة حالة يقدمها العميل إلى QRESYNC هي UIDVALIDITY الأخيرة التي يعرفها. إذا لم تطابق الجيل الحالي، تجاهل الخادم تسلسل التعديلات ومجموعة UID الباقية. قد تكون الفروق دقيقة، لكنها تخص مجموعة أخرى من الكيانات.

قبل سؤال «ما الذي تغير؟» يجب إثبات أن الأشياء المقارنة ما زالت هي نفسها. السرعة لا تصلح خطأ النطاق.

أزال UIDONLY الموضع ولم يلغ الجيل

عرّف RFC 9586 التجريبي في مايو 2024 امتداد UIDONLY. بعد تفعيله لا يستخدم العميل أرقام التسلسل ولا يعيدها الخادم؛ تحل صيغ UID وVANISHED محل خريطة المواضع المتحركة، ما يقلل الموارد لدى الطرفين.

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

ومع UIDONLY يظل UID مقيداً بالصندوق وبـUIDVALIDITY. إزالة الموضع النسبي لا تجعل الرقم أبدياً أو عالمياً.

طال عمر المعرّف لأنه استطاع أن يموت بصدق

وزع IMAP المسؤولية حيث توجد المعرفة. الخادم يسيطر على المخزن، ولذلك يعلن هل استمرت UID. والعميل يسيطر على الذاكرة والإجراءات المؤجلة، ولذلك يسحب أثرها عند تغير الجيل. لا يملك أي طرف أن يحول الراحة إلى برهان.

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

استطاع UID عبور الجلسات لأن UIDVALIDITY يستطيع إعلان أنه لم يعبر ولادة الصندوق من جديد.

المصادر والحدود

يأتي تصميم 1994 من RFC 1730، وتأتي قواعد أرقام التسلسل وUID والثلاثية من RFC 2060 وRFC 3501 وRFC 9051. يوثق RFC 2683 خبرة التنفيذ، وRFC 2192 الروابط، وRFC 4315 حالة UIDNOTSTICKY، وRFC 4549 العمل غير المتصل، وRFC 7162 QRESYNC، وRFC 9586 امتداد UIDONLY التجريبي. لا تثبت هذه الوثائق نسبة النشر الحالية أو سلوك منتج بعينه أو أصالة البريد أو السلامة التشفيرية أو خوارزمية وحيدة لـUIDVALIDITY.