RFC 2061: تشغيل البريد القديم وحدود الوعد بالتوافق

الخلاصة

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

يطلب عميل البريد معاينة مقطع من رسالة دون تعديل حالتها. على المسار القديم، يستطيع جلب البايتات ثم محاولة إزالة أثر الاسترجاع. لكن «عرض المقطع نفسه» و«تنفيذ العملية نفسها» ليسا شيئًا واحدًا: قد تدخل كتابةٌ إلى حالة الرسالة في عملية تبدو للمستخدم قراءةً فقط. هذه هي المفارقة التي تبرز عند مقابلة بدائل RFC 2061 بدلالات الاسترجاع في RFC 2060.

مذكرة تعترف بما لا تعرفه

نشر Mark Crispin، من University of Washington، RFC 2061 في ديسمبر 1996 بوصفها مذكرة معلوماتية، لا معيارًا. وصف IMAP2bis بأنه شائع آنذاك وموزع على نطاق واسع مع Pine، مع غياب وثيقة تصفه بصورة حاسمة. تلك شهادة عن زمن الكتابة، لا حصة سوقية مقاسة ولا وصف للحاضر. وأقر بنقص المعرفة وبالاستناد جزئيًا إلى خبرة متداولة؛ واختار التركيز على الصيغة القديمة الأرجح مصادفتها، لا جميع الصيغ. أما تحمل التعامل مع البرامج القديمة فقرار للمطور، لا التزام تفرضه مواصفة IMAP4. RFC 2061

وللتسلسل الزمني أهميته: يصف RFC 1176، الصادر في أغسطس 1990، IMAP2، وليس مواصفة حاسمة لـIMAP2bis. وفي ديسمبر 1994 جاء RFC 1730 لمواصفة IMAP4، ومعه RFC 1732 لإرشادات توافق أوسع. ثم جاءت مراجعة IMAP4rev1 في RFC 2060 في ديسمبر 1996. دعم نسختي 1994 و1996 يستلزم قراءة المواصفتين؛ والإرشادات الأقدم ليست بديلًا مطابقًا لمذكرة 2061 الأضيق نطاقًا.

اختيار المسار لا يضمن نتيجته

تبدأ قاعدة التوافق باختبار CAPABILITY. يتيح نجاحه بـOK التعرف إلى صيغ IMAP4 المعلنة؛ وإن لم يعرف العميل أيًّا منها، توصي المذكرة بمعاملة الخادم كـIMAP2bis. أما BAD ردًا على هذا الأمر فيشير، ضمن هذه القاعدة، إلى IMAP2bis أو أقدم. إنها قرينة لتوجيه العميل، لا إثبات قاطع لهوية خادم مجهول أو لصحة عملياته التالية. ولا تعني المهلة المنتهية أو الإخفاق الأمني أو أي خطأ آخر تلقي BAD. RFC 2061

يمكن ترتيب البدائل في ثلاث فئات تحليلية؛ هذه تسميات للقراءة وليست تصنيفًا رسميًا في المذكرة:

الفئة	ما يقدمه المسار القديم	الحد الذي يبقى قائمًا
عملية نافعة قريبة من المقصود	يحل FIND ALL.MAILBOXES محل LIST، بصياغة وردود تشبه FIND MAILBOXES في RFC 1176.	الأمر الأخير نفسه غير مرجح أن يعطي معلومات مفيدة؛ تشابه الصياغة لا يجعله البديل الموصى به.
تقريب للمعنى أو تعويض للأثر	يحل BODY غير القابل للتوسعة محل BODYSTRUCTURE، وتُختزل أقسام HEADER وTEXT وMIME وHEADER.FIELDS وHEADER.FIELDS.NOT إلى أرقام الأقسام.	تغيير الصياغة لا يستحدث معلومات البنية الموسعة ولا دلالات اختيار الأقسام الأغنى.
غياب المكافئ الوظيفي	لا مكافئ لعنصر الاسترجاع UID وأوامره، ولا لـCLOSE.	أرقام التسلسل ليست بديل هوية ثابتًا، وجمع EXPUNGE بأمر آخر لا يصنع مكافئًا لـCLOSE.

ويُستبدل * في التسلسل بعدد الرسائل الوارد في رد EXISTS غير المطلوب، دون ضمان لقطة ثابتة. وتُعاد صياغة امتدادات SEARCH وفق نحو RFC 1176، وقد يلزم أكثر من بحث؛ لا يعني ذلك ضمان مجموعات المحارف أو معايير البحث الأحدث. كذلك لا مكافئ وظيفي مباشر لـLSUB وSUBSCRIBE وUNSUBSCRIBE. ومفهوم لوحات النشرات القديم، bboards، مختلف؛ بل توصي المذكرة بعدم تنفيذ أوامره في البرامج الجديدة، حتى الخوادم التي تخدم عملاء قدامى. RFC 2061

محو الأثر ليس منع وقوعه

بديل BODY.PEEK[section] هو BODY[section] ثم مسح العلم \Seen يدويًا عند الحاجة. وتوضح مواصفة 2060 أن الأول لا يضبط هذا العلم ضمنيًا، بخلاف الثاني. كما تجيز تغير الأعلام بفعل جهات أخرى وتوصي بإرسال تحديثاتها تلقائيًا. RFC 2061؛ RFC 2060

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

وبالمثل، تُستبدل FLAGS.SILENT و+FLAGS.SILENT و-FLAGS.SILENT بصيغ STORE المقابلة دون .SILENT، ويتجاهل العميل ردود FETCH غير الموسومة العائدة. تجاهلها محليًا لا يمنع صدورها ولا يمحو آثار العملية لدى الخادم أو الأطراف الأخرى. RFC 2061

نجاح النسخ ليس إيصال حفظ

تقرر RFC 2061 أن IMAP2bis غامض بشأن حفظ الأعلام والتواريخ الداخلية عند COPY، وأن سلوك الخادم لا يمكن معرفته من هذا الوصف. أما توصية الحفظ بصيغة SHOULD في RFC 2060 فلا تُفرض بأثر رجعي عليه. لذلك لا يثبت رد النجاح حفظ البيانات الوصفية؛ واختبار خادم بعينه يثبت ملاحظة محددة، لا عقدًا عامًا مفقودًا. RFC 2061؛ RFC 2060

ويتطلب TRYCREATE انتباهًا مستقلًا: في IMAP2bis يأتي داخل رد OK منفصل غير مطلوب، لا داخل NO. ينبغي تفسير التلميح مع إبقاء سياق الفشل؛ فهو لا يحوّل COPY الفاشل إلى نجاح. وفي الاتجاه العكسي، تحصر المذكرة المشكلة المعروفة لعميل IMAP2bis مكتوب جيدًا مع خادم IMAP4 في الشرطة المائلة العكسية داخل السلاسل المقتبسة؛ وتقترح السلاسل الحرفية محددة الطول عند تضمين \ أو ". لا يمتد هذا الحكم المقيد إلى كل برنامج قديم. RFC 2061

وتوصية استعمال LOGIN بدل AUTHENTICATE نصيحة توافق تاريخية في مذكرة لا تناقش الأمن. ليست إذنًا معاصرًا بإرسال بيانات الدخول مكشوفة أو خفض الحماية. تُستحضر هنا إرشادات IETF في RFC 8314، الصادر في يناير 2018، بشأن TLS للوصول إلى البريد وإيداعه، لهذا الفصل الزمني فقط، لا لإثبات نشره عام 1996.

قراءة لاحقة، لا نية منسوبة إلى الماضي

كتب Lu Heng في مقاله عن المواصفة الأولية والقرار المحلي والتبني الطوعي عام 2026: "Non-adoption is not a violation." وفي مقاله عن طبقات الواقع والسلطة الرمزية عام 2025: "Most conflicts persist because participants mix these layers." تطبيق هذين الرأيين هنا محدود: للعميل أن يختار نطاق توافقه، لكن تسمية القدرة لا تثبت أثر تنفيذها. هذه قراءة تحريرية لاحقة، وليست مصدرًا تاريخيًا لـIMAP ولا دليلًا على نية Mark Crispin. والخلاصة العملية: التوافق وعد معلن بخدمة أضيق، لا إبقاء خفيًا لكل خصائص الخدمة الأحدث.

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

المصدر	نطاق الاستناد إليه
RFC 2061	مذكرة ديسمبر 1996: البدائل الاختيارية، والحدود، وعدم اليقين.
RFC 2060	مواصفة ديسمبر 1996: دلالات الاسترجاع والأعلام والنسخ في IMAP4rev1.
RFC 1176	أساس IMAP2 في أغسطس 1990؛ مرجع الصياغة القديمة، لا توثيق نهائي لـIMAP2bis.
RFC 1730	مواصفة IMAP4 في ديسمبر 1994، المتميزة عن مراجعة 1996.
RFC 1732	إرشادات ديسمبر 1994 الأوسع لـIMAP2 وIMAP2bis والصيغ الأقل شيوعًا.
RFC 8314	حد أمني لاحق في يناير 2018؛ ليس شاهدًا على أنظمة 1996.
Lu Heng: المواصفة الأولية والقرار المحلي والتبني الطوعي	رأي تنسيقي من عام 2026، لا تاريخ تقني لتطبيقات البريد.
Lu Heng: طبقات الواقع والسلطة الرمزية	إطار تفسيري من عام 2025، لا دليل على مقاصد مؤلف المذكرة.