الخلاصة

  • تتيح RFC 10022 لعميل IMAP طلب نطاقات UID تنازلية تقارب عدداً محدداً من الرسائل، بما في ذلك وضع UIDONLY. هذه النطاقات تهيئ أوامر لاحقة؛ وليست لقطة مجمدة ولا نتيجة بحث محفوظة.
  • قد لا توجد رسائل عند طرفي النطاق، وقد تكون الدفعة أصغر من المطلوب ثم تنكمش بعد الحذف. كما أن عدد الرسائل لا يضمن تساوي البايتات أو الزمن أو كلفة الخادم.
  • حرر Daniel Eggert وثيقة إجماع IETF. تحدد مساهمته آلية مشتركة ضيقة، فيما تبقى الخوارزمية والجدولة ومعالجة الاختلاف والنتيجة التشغيلية لدى الجهات التي تنفذها.

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

نُشرت RFC 10022، IMAP UIDBATCHES Extension، في يوليو 2026 على مسار معايير IETF، وحررها Daniel Eggert من Apple Inc. تسمح الإضافة بتحديد نطاقات UID مسبقاً حتى لا تعمل أوامر FETCH أو SEARCH أو STORE اللاحقة على عدد غير محدود من الرسائل. وتزداد أهميتها مع UIDONLY، إذ لا يستطيع العميل استخدام أرقام التسلسل.

الآلية تنظم العمل من دون أن تدعي إيقاف زمن صندوق البريد. وهذه ليست فجوة؛ إنها حدود مقصودة للسلطة التي يحملها الرد.

النطاق ليس قائمة عضوية

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

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

لهذا لا يساوي طرح الطرفين عدد الرسائل. ولا يثبت وقوع رقم داخل النطاق أن رسالة بذلك الرقم كانت موجودة. العضوية الفعلية تظهر في جواب الأمر اللاحق.

يجب أن يحفظ السجل مستويين: رد UIDBATCHES بوصفه خطة تقسيم، ثم UIDs التي وجدها FETCH أو SEARCH أو عدلها STORE. دمج المستويين في «صفحة» واحدة يمحو سبب الفجوات عند التحقيق.

وتؤكد SEARCHRES الحد نفسه. UIDBATCHES ليس SEARCH ولا UID SEARCH، ولا يجوز تخزين نتيجته في المتغير $. أما PARTIAL فيقدم SEARCH وFETCH على صفحات؛ فهو يحل مسألة أخرى حتى لو تشابهت بعض شيفرة العميل.

التساوي يخص هدف العد فقط

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

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

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

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

الحذف ينقص الدفعة ولا يعيد كتابة أصلها

تحصل الرسائل الجديدة على UIDs أعلى، فلا تدخل داخل نطاق سبق إرجاعه. لن يكبر عدد رسائل ذلك النطاق، لكنه قد ينقص بعد EXPUNGE.

يمكن للعميل متابعة EXPUNGE وVANISHED وEXISTS. وتعد إعادة الحساب مناسبة بعد اختيار صندوق آخر، أو حذف أكثر من نصف حجم الدفعة، أو وصول أكثر من نصف دفعة من الرسائل الجديدة. خارج هذه الحالات يجب ألا يعيد العميل UIDBATCHES.

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

رموز LIMIT وTOOFEW وTOOMANY ليست رسالة عامة لزر «حاول مجدداً». كل رمز يحدد شرطاً يجب تغييره: التكرار أو الصغر أو الحجم. إعادة الطلب نفسه بلا تعديل تضاعف الخطر.

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

التداخل شاهد بين نافذتين

قد يطلب العميل في صندوق كبير الدفعات 1:100 ثم 101:200. لأن الأحجام تقريبية والحالة تتغير، تقترح RFC تكرار دفعة الحد: 1:100 ثم 100:200 ثم 200:300.

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

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

لا يجوز أن يغطي طلب ذو نطاق أكثر من 100 ألف رسالة. يجب على الخادم دعم هذا القدر على الأقل، ويمكنه رفض الأكبر بـTOOMANY. وفي صندوق هائل يمكنه رفض طلب جميع النطاقات. وإذا أعلن MESSAGELIMIT، ينبغي للعميل ألا يتجاوز حد الرسائل للأمر الواحد.

يحمي الحد الأدنى 500 مقصد UIDONLY أيضاً. فلو سُمح بدفعات بالغة الصغر لاستطاع العميل إعادة بناء معلومات موضعية دقيقة تشبه أرقام التسلسل.

النجاح الفارغ له سببان

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

يربط tag الرد بالأمر. ويبين مدى الدفعات ما سُئل عنه. وتوفر EXISTS سياق الصندوق عند الاختيار. اختصار الجميع إلى «صفر دفعات» قد يحول تجاوز نهاية النافذة إلى ادعاء أن الصندوق فارغ.

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

سياق Daniel Eggert لا يثبت النشر

عند الحفظ في 1 سبتمبر 2026، كان ملف Daniel Eggert الرسمي في IETF Datatracker يسرد RFC 10022 وRFC 9979. وقد قدمه Swift.org في مقال عن SwiftNIO IMAP عام 2022 بوصفه عضواً في فريق Apple العامل على Mail لنظامي iOS وmacOS، وربط بهويته العامة على GitHub.

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

المساهمة الموثقة تحافظ على هذا الفصل. تحدد RFC اللغة المشتركة والحدود الوقائية، ويحتفظ الخادم بخوارزميته، والعميل بجدولته، والمشغّل بقرار القبول. يتفق ذلك مع Minimum Initial Specification لدى Heng Lu؛ أما Running-Code Primacy فيجعل نتيجة الأوامر الفعلية طبقة الواقع النهائية.

إيصال دفعة قابل للمراجعة

يسجل الإيصال الخادم وحد الحساب والصندوق وUIDVALIDITY والقدرات. ثم tag والعدد ومدى الدفعات ورمز الرد والنطاقات. ويربط EXISTS وEXPUNGE وVANISHED وسبب إعادة الحساب ومقارنة التداخل.

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

بهذا يبقى نطاق UID أداة تقسيم فعالة من دون أن ينتحل صفة صفحة ثابتة.

المصادر