الخلاصة

  • كان رقم الرسالة موضعاً يُمنح بعد فتح صندوق البريد في الجلسة الحالية. أما LAST فكان يحفظ أعلى رقم جرى الوصول إليه، ولذلك لم يستطع وصف تاريخ متقطع أو ذاكرة مختلفة لكل عميل.
  • أزالت RFC 1725 الأمر LAST وأضافت UIDL اختيارياً. وألزمت RFC 1939 المعرّف بالبقاء عبر الجلسات داخل صندوق بريد واحد، بينما ظل على العميل أن يسجل ما عالجه فعلاً وأن يفصل الهوية عن بقاء الرسالة على الخادم.

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

هذه القسمة هي جوهر UIDL. لم يحوّل POP3 إلى نظام مزامنة كامل، ولم ينقل سجل القراءة لكل جهاز إلى المركز. منح الخادم التزاماً ضيقاً: إذا بقيت الرسالة نفسها في صندوق البريد، يبقى معرّفها مستقراً عبر الاتصالات. ومنح العميل مادة يستطيع بها بناء ذاكرته الخاصة.

قبل ذلك، كان البروتوكول يملك رقماً مؤقتاً وخط تقدم واحداً. كلاهما كان مفيداً، لكن أياً منهما لم يكن اسماً دائماً لرسالة بعينها.

الرقم يصف ترتيب هذه الجلسة

صممت RFC 1460 بروتوكول POP3 لمحطات أصغر لا تستطيع تشغيل نظام نقل بريد مقيم بصورة دائمة. يحتفظ الخادم بالبريد في maildrop، ويتصل العميل عند الحاجة ليسترجعه، وكان السلوك المعتاد أن ينزل الرسائل ثم يحذفها.

بعد أن يفتح الخادم صندوق البريد ويحلله، يمنح الرسالة الأولى الرقم 1 والثانية الرقم 2 وهكذا. يستخدم العميل هذه الأرقام مع LIST وRETR وDELE. داخل المعاملة الحالية، الموضع قصير وواضح.

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

قدمت RFC 1460 أيضاً الأمر LAST. كان الخادم يعيد أعلى رقم رسالة جرى الوصول إليه في معاملات سابقة. يستطيع العميل أن يفترض أن الأرقام الأعلى لم تُمس بعد. ويحرّك RETR أو DELE لرقم أعلى ذلك الحد، بينما يعيده RSET إلى الصفر.

لكن أعلى رقم يلخص التاريخ في عدد واحد. لا يستطيع تمثيل حالة استرجع فيها العميل الرسالتين 1 و3 ولم يسترجع 2. ولا يستطيع منح جهازين سجلين مستقلين. كما أن حذف موضع أدنى يغير معنى الحدود التي بنيت على الترتيب السابق.

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

جمع UIDL بين موضع لحظي ورمز مستمر

إذا أرسل العميل UIDL مع رقم، يعيد الخادم الرقم الحالي والـ unique-id المقابل. وإذا أرسله بلا رقم، يحصل على قائمة متعددة الأسطر لكل رسالة غير معلّمة للحذف.

للعمودين زمنان مختلفان. الرقم يحدد ما ينبغي استرجاعه أو حذفه الآن. والـ UID يتيح مقارنة السطر الحالي بسجل من اتصال سابق.

تحدد RFC 1939 المعرّف كسلسلة يقررها الخادم، طولها من حرف واحد إلى سبعين حرفاً قابلاً للطباعة. يميز رسالة داخل maildrop واحد ويستمر عبر الجلسات. ويجب أن يستمر حتى عندما تنتهي الجلسة السابقة من دون بلوغ حالة UPDATE.

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

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

استمرارية الخادم لا تساوي حالة الاستخدام لدى العميل

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

لهذا يحمل العميل دفتر الحالة. ينبغي أن يربط UID بنطاق الخادم والحساب، وأن يفصل بين uid_listed وretrieval_completed وstored_locally وdelete_marked وupdate_committed وsession_aborted.

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

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

كلمة unique لم تمنح هوية عالمية

نطاق UID هو صندوق بريد واحد. لا علاقة محددة للسلسلة نفسها في حساب آخر أو خادم آخر. وليست هي ترويسة Message-ID، ولا تصادق على المرسل أو المستلم أو المحتوى، ولا تثبت التسليم أو السلامة.

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

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

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

استمرار الرمز لا يضمن استمرار التخزين

يلتزم الخادم بالحفاظ على UID ما دام العنصر موجوداً، لكنه لا يلتزم ببقاء العنصر إلى الأبد. تحذر RFC 1939 من تراكم مئات أو آلاف الرسائل المقروءة عندما يتركها العملاء على الخادم. يستطيع الموقع تطبيق حصة أو سياسة احتفاظ وإزالة البريد خارج تدفق أوامر POP3.

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

أضافت RFC 2449 الأمر CAPA لأن اكتشاف الوظائف الاختيارية كان يعتمد سابقاً على التجربة أو الإعداد. يعلن سطر UIDL أن الأمر مدعوم. لكنه لا يراجع جودة مساحة المعرفات ولا يضمن الاحتفاظ.

وقدمت الوثيقة نفسها قدرة EXPIRE للإعلان عن حد أدنى للأيام أو صفر أو NEVER. وحتى ذلك لا يعطي لحظة انتهاء دقيقة لرسالة بعينها؛ قد يبدأ الخادم العد عند الوصول أو أول إدراج أو الاسترجاع أو حدث آخر.

الدعم والهوية والاحتفاظ ثلاث حقائق مستقلة. CAPA يقول إن الأمر متاح، وUIDL يقول كيف نتعرف إلى عنصر أثناء خدمته، وEXPIRE يصف سياسة العمر. لا يحل واحد منها محل الآخر.

ذاكرة موزعة أبقت البروتوكول بسيطاً

لم يحل UIDL مزامنة صندوق البريد كاملة. لم يضف مجلدات أو أعلاماً مشتركة أو تسوية لتعارض أجهزة متعددة. قدم حلاً أضيق: ربط موضع اليوم المؤقت بسجل الأمس عند العميل.

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

يعيش الرقم مدة الجلسة. ويعيش UID بما يكفي لعبور الانقطاع. وتعيش ذاكرة الاستخدام عند العميل. بهذه الحدود دعم POP3 ممارسة “اترك البريد على الخادم” من دون أن يتخلى عن نموذجه البسيط.

المصادر