الخلاصة

  • يتيح RFC 9738 للخادم معالجة أحدث N رسالة في SEARCH أو FETCH أو STORE أو MOVE أو UID EXPUNGE، ثم إعادة OK مع MESSAGELIMIT وحد UID أدنى يبيّن موضع التوقف.
  • تحافظ COPY وMULTIAPPEND على الذرية فلا تنفذان جزءاً من الطلب الكبير، بينما قد تترك العمليات الأخرى آثاراً جزئية حقيقية تتطلب استئنافاً خاصاً بكل أمر.
  • القيمة المعلنة تنظم تعاون العميل والخادم؛ ولا تثبت وحدها أن الحد الصارم مطبق الآن، أو أن كل العملاء يدعمونه، أو أن الصندوق ثابت، أو أن النتيجة المرئية كاملة.

يبدأ الخطر عندما تُقرأ $ بلا تاريخ. الرمز لا يقول كيف وُلد. فإذا كانت SEARCH الأصلية قد فحصت آخر ألف رسالة فقط بسبب MESSAGELIMIT، فإن النتيجة المحفوظة تحتوي مطابقات صحيحة من تلك الشريحة وحدها. أمر COPY أو STORE لاحق قد ينجح تماماً على $، لكن نجاحه لا يضيف الرسائل التي لم تُفحص أصلاً.

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

الحد يخص أمراً واحداً

يعلن الخادم MESSAGELIMIT=N لبيان أقصى عدد من الرسائل التي يعالجها أمر SEARCH أو FETCH أو STORE أو COPY أو MOVE، ونسخ UID منها، وكذلك APPEND وUID EXPUNGE. أما SAVELIMIT=N فيخص الحالة الأضيق التي يحد فيها الخادم عائلتي COPY وAPPEND فقط. ويوصي النص بألا تقل القيمة عن ألف.

لا تعني N أن الصندوق يضم N رسالة. وليست حصة تخزين أو مدة احتفاظ أو حداً لحجم الرسالة. إنها سقف عمل لاستدعاء واحد.

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

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

الحالة الموسومة لا تختصر الرد كله

يمكن أن يعيد FETCH بيانات ألف رسالة ثم ينهي بـOK [MESSAGELIMIT …]. ويمكن لـSEARCH إعادة مطابقات الشريحة المفحوصة. وقد يكون STORE غيّر flags بالفعل. وقد يكون MOVE نسخ الشريحة إلى الوجهة وحذفها من المصدر. وقد يكون UID EXPUNGE أزال رسائل \Deleted فعلياً.

هذه ليست معاينة. هناك نتيجة أو أثر وقع. وصفها بالفشل يمحو الأثر، ووصفها بالاكتمال يمحو الباقي. لذلك يجب أن يحتفظ السجل بنجاح الاستدعاء وبحالة اكتمال الهدف كحقلين مستقلين.

يختلف الاستئناف باختلاف الأمر. يجب تضييق مدى UID STORE بحيث لا يشمل أدنى UID المنجز مرة أخرى. ويمكن إعادة UID MOVE بالمجموعة نفسها لأن ما نُقل لم يعد موجوداً في المصدر. أما MOVE المبني على أرقام التسلسل فيحتاج إلى إعادة حساب، لأن expunge غيّر المواقع. ويمكن إعادة UID EXPUNGE بالمعامل نفسه إلى أن يختفي كود الحد أو يصل NO أو BAD.

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

وقد يظهر كود النقص في رد غير موسوم. إذا احتاج الخادم أيضاً إلى EXPUNGEISSUED، يوضع هذا في OK الموسوم، بينما يأتي MESSAGELIMIT في NO غير موسوم. العميل الذي يقرأ السطر الأخير فقط يحتفظ بكلمة النجاح ويتخلص من واجب الاستمرار. الإيصال الكامل هو tag والردود غير الموسومة والبيانات والأكواد والحالة النهائية معاً.

الذرية تقسم الأوامر إلى عائلات

COPY وUID COPY ذريتان. إذا تجاوزت المجموعة السقف، يعيد الخادم NO [MESSAGELIMIT …] ولا ينسخ أي رسالة. وMULTIAPPEND كذلك: لا يجوز إلحاق أول جزء من مجموعة كبيرة ثم رفض بقيتها.

أما MOVE فلا يلزم أن يكون ذرياً، ولذلك قد يترك رسائل في الوجهة ويحذفها من المصدر قبل بيان الحد. ويستطيع STORE وUID EXPUNGE ترك أثر جزئي أيضاً. الكود نفسه قد يعني إذن رفضاً بلا أثر أو نجاحاً بأثر غير مكتمل. اسم الأمر جزء لا ينفصل عن تفسير النتيجة.

هناك فئة ثالثة لا يطبق عليها هذا السقف: EXPUNGE وCLOSE وSTATUS UNSEEN. يحظر RFC 9738 تقييدها بعدد الرسائل. لكن اكتمالها على مستوى IMAP لا يثبت متانة التخزين أو مزامنة عميل آخر أو ما ظهر للقارئ.

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

أصل $ أهم من اسمها

عندما تعمل SEARCHRES مع MESSAGELIMIT، يجب أن تُحفظ في $ النتيجة المبتورة فقط. هذه قاعدة صحيحة: الرمز لا يدعي ما لم يفحصه الخادم. الخطأ يحدث في الطبقات التي تنزع عنه وصفه وتعرضه كـ«مجموعة نتائج» بلا حالة اكتمال.

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

يضيف RFC 9738 معياري UIDAFTER وUIDBEFORE لتسهيل بناء النطاق التالي. وهما لا يوقفان وصول الرسائل ولا يعيدان UID محذوفاً ولا يعبران تغيير الجيل. إنهما لغة بحث، لا قفل معاملة طويل.

الإعلان قد يسبق الإنفاذ

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

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

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

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

إغلاق النية الأصلية

تبدأ المهمة الشاملة بتحديد ما كانت تريد معالجته. ثم تسجل في كل جولة الصندوق وUIDVALIDITY والأمر والمجموعة المطلوبة وفئة الذرية والقدرة المعلنة وUID المعادة والآثار والردود غير الموسومة والحالة النهائية والحد وأدنى UID.

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

ينبغي أيضاً إبقاء الأدوات المتجاورة منفصلة. UIDBATCHES يخطط نطاقات UID محدودة. PARTIAL يطلب صفحة بعينها. MESSAGELIMIT يصف سقفاً صادفه التنفيذ. SEARCHRES يحفظ مجموعة. QRESYNC يساعد على مزامنة التغير. دمجها في كلمة «دفعات» يفقد موضع كل ضمان.

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

المصادر