الخلاصة

  • أضاف UIDPLUS إلى نجاح APPEND وCOPY قيمة UIDVALIDITY لصندوق الوجهة ومعرّفات UID التي أنشأها الخادم، فصار بوسع العميل غير المتصل مطابقة الفعل بنتيجته من دون بحث تخميني.
  • بقي هذا الإيصال محدود السلطة: قد يُحجب بسبب الصلاحيات أو UIDNOTSTICKY، ولا يثبت COPYUID هوية عالمية، ولا يحذف UID EXPUNGE إلا الرسائل الموجودة في المجموعة المحددة والحاملة مسبقًا للعلامة \Deleted.

عندما تكون المعلومة الصحيحة إفشاءً

تفصل أنظمة البريد أحيانًا بين حق الكتابة وحق المشاهدة. قد يستطيع حساب أن ينفذ APPEND أو COPY إلى صندوق مخصص للاستقبال، مع منعه من SELECT أو EXAMINE. هذه ليست مفارقة؛ إنها سياسة تسمح بالإيداع ولا تسمح باستطلاع المحتوى أو بنية الصندوق.

لو أعاد الخادم UIDVALIDITY وUID جديدًا في هذه الحالة، لأصبح نجاح الكتابة قناة تكشف معلومات عن صندوق غير قابل للفحص. ينص RFC 4315 لذلك على أن الخادم لا ينبغي أن يرسل APPENDUID أو COPYUID حين يملك العميل حق التغيير لكنه لا يملك حق اختيار صندوق الوجهة أو فحصه.

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

APPENDUID سمّى ما أنشأه النجاح

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

أدخل APPENDUID في رد OK الموسوم قيمة UIDVALIDITY للوجهة ثم UID الممنوح. يستطيع العميل ربط بند الانتظار المحلي بالرسالة البعيدة التي صارت نتيجته، بدل إبقاء العملية في حالة مبهمة بين النجاح وإعادة الاكتشاف.

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

وعند إضافة عدة رسائل بأمر واحد، يمكن أن يحمل APPENDUID مجموعة مرتبة. يقابل UID الأول الرسالة الأولى في الأمر. لا يجوز أن تضم المجموعة * أو أرقامًا لم تنشأ عن العملية. يستطيع العميل بذلك مقارنة عدد المدخلات وشكل المخرجات.

COPYUID وصف انتقالًا بين نطاقين

لا ينتقل UID المصدر مع الرسالة إلى صندوق آخر. للوجهة نطاق تسمية مستقل، ويمنح الخادم نسخها أرقامًا جديدة. يعيد COPYUID قيمة UIDVALIDITY للوجهة، ومجموعة UID المصدر، ومجموعة UID الوجهة.

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

أرقام التسلسل المرئية لا تصلح أساسًا بديلًا. إذا حذف عميل آخر رسالة أثناء COPY، تتغير مواضع ما يليها. أما UID فيثبت نطاق الأمر، ويحظر المعيار أن يضيف الرد معرّفات لا تخص النسخ المنفذ.

ومع ذلك لا يصبح COPYUID هوية مشتركة لكل العملاء. يوضح RFC 8474 أن العميل الذي تلقى الرد يعرف المطابقة، لكن عميلًا آخر لا يستطيع استنتاجها لاحقًا من UID العادي في صندوقين. جاءت معرّفات الكائن لمعالجة هذا الاحتياج الأوسع. يعالج UIDPLUS نتيجة أمر، لا مفهوم التطابق الكوني.

الحذف احتاج إلى شرطين

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

يأخذ UID EXPUNGE مجموعة UID ولا يزيل إلا ما يقع في تقاطعها مع الرسائل الموسومة. UID موجود في الطلب بلا \Deleted يبقى، ورسالة موسومة خارج المجموعة تبقى أيضًا. هكذا يفصل البروتوكول بين أهلية الحذف وقرار هذا العميل بإتمامه الآن.

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

UIDNOTSTICKY منع وعدًا زائفًا

قد يكون صندوق الوجهة من نوع UIDNOTSTICKY، أي إن UID لا يضمن البقاء بين الجلسات. لا يشجع RFC 4315 إنشاء مخازن بهذه الصفة، لكنه يسمح بحجب APPENDUID أو COPYUID عنها. رقم دقيق الآن قد يصبح مرجعًا مضللًا لاحقًا.

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

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

MOVE جعل توقيت الإيصال جزءًا من المعنى

ينشئ MOVE رسالة جديدة في الوجهة ويحذف الأصل. في UID MOVE ينبغي لخادم UIDPLUS أن يقدم COPYUID حين تسمح الشروط. إذا أرسل EXPUNGE أولًا، تتحرك أرقام التسلسل في المصدر قبل أن يعرف العميل الربط الجديد.

أوصى RFC 6851 بإرسال COPYUID داخل OK غير موسوم قبل ردود الحذف. وأدخل RFC 9051 هذا الترتيب في IMAP4rev2. ليست الحقيقة وحدها كافية؛ يجب أن تصل قبل زوال الحالة التي تجعل تفسيرها بسيطًا وغير ملتبس.

من تحسين للعميل المنقطع إلى قاعدة إثبات

عرّف RFC 2359 UIDPLUS عام 1998 باعتباره تحسينًا يفيد العملاء غير المتصلين. حل RFC 4315 محله عام 2005، وضبط المجموعات والاستثناءات وأضاف UIDNOTSTICKY. لا يزال سجل IANA يربط القدرة بالوثيقة الأحدث، ثم دمج IMAP4rev2 هذه الآليات في مواصفته الأساسية.

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

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

ظهر التعريف الأول في RFC 2359، وحل محله RFC 4315. يقدم RFC 3501 سياق IMAP4rev1، ويشرح RFC 6851 MOVE، ويبين RFC 8474 حدود الرؤية بين العملاء، ويدمج RFC 9051 السلوك في IMAP4rev2. يسجل سجل IANA UIDPLUS. لا تقيس هذه المصادر الانتشار، ولا تجعل UID دليلًا تشفيريًا أو إيصال تسليم.