قَبِل الخادم الرسالة، لكن المستخدم ظل عاجزاً عن العثور عليها

الخلاصة

• تفصل RFC 9755 بين قدرة يعلنها الخادم وتمكين صريح يجريه عميل موثّق؛ ولا يثبت أي منهما وحده سلامة سلسلة الهوية ومخزن البريد والفهرس والعرض.
• ينتهي القبول برسالة اختبار يستطيع المستخدم المقصود إدراجها والبحث عنها وجلبها وفهمها والتصرف بها، لا بسطر أخضر في سجل البروتوكول.

قد ينجح الاختبار عند البوابة الخطأ. تُضاف رسالة ذات ترويسات دولية، فيرد الخادم بـ OK، ثم لا يجدها المستلم باسم المرسل أو يعجز عن فتح رسالة مرفقة أو لا يراها في عميل معتمد. نجاح APPEND صحيح، لكنه أجاب عن سؤال أضيق من صلاحية الخدمة.

صدرت RFC 9755 في مارس 2025 ضمن Standards Track وحلّت محل RFC 6855 في IMAP4rev1، بينما يتضمن IMAP4rev2 قدرات مماثلة تقريباً. تعلن UTF8=ACCEPT فتح صناديق تحوي رسائل دولية وإرجاع أسماء UTF-8. وتتضمن UTF8=ONLY تلك القدرة مع رفض modified UTF-7 القديم.

الإعلان ليس حالة الجلسة

على العميل أن يوثّق نفسه ثم يرسل ENABLE UTF8=ACCEPT. وهذا هو الأمر حتى مع UTF8=ONLY؛ فلا يوجد ENABLE UTF8=ONLY. وفق RFC 5161، تسجل استجابة ENABLED ما فُعّل فعلاً، أما CAPABILITY فلا تتغير ولا تصبح إيصالاً للجلسة.

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

قانونية النص لا تنشئ هوية

لا توسع RFC 9755 أمر LOGIN لاسم مستخدم أو كلمة مرور UTF-8؛ يلزم AUTHENTICATE. لكنها تنص على أن حمل النص قانونياً لا يضمن أن نظام تزويد الهويات يسمح بالحساب. يجب إثبات وجود الهوية في المصدر المعتمد، ونجاح آلية التوثيق الفعلية، وربطها بالصندوق الصحيح وصلاحياتها في كل مسار.

APPEND بداية إثبات التخزين

بعد ENABLE يقبل الخادم الداعم ترويسات UTF-8 في APPEND، وقبله يرفض ترويسات 8 بت. الاختباران مفيدان، لكن القبول لا يثبت الفهرسة أو العرض.

تلغي المراجعة عنصر APPEND UTF8 القديم، وتذكر أن IMAP4rev1 وIMAP4rev2 وJMAP لا تقدم مؤشراً موثوقاً لكل رسالة عن استخدامه. لذا يرتبط الإيصال بالرسالة نفسها: المدخل الخام وبصمته، والاستجابة، وUID إن توفر، ثم جلب الكائن ذاته.

تحتاج أسماء الصناديق إلى متجهات منفصلة. تشترط RFC 9755 ‏Net-Unicode وتستبعد محارف تحكم وفصل محددة. تشرح RFC 5198 تطبيع NFC، وتوصي RFC 6532 به في الترويسات وتحذر من NFKC حين يمحو فروق التهجئة. التشابه البصري وتساوي البايتات وتساوي نتيجة البحث ثلاث دعاوى مختلفة.

تبيّن وثائق Dovecot الحالية حداً تنفيذياً: تخزين أسماء الصناديق بـUTF-8 خيار مستقل، وتغييره قد يكسر أسماء غير ASCII القائمة. هذا مثال واحد لا مسح للسوق، لكنه يثبت أن تحديث البروتوكول لا ينجز ترحيل المخزن تلقائياً.

قد تكون لـBODYSTRUCTURE صورتان صحيحتان

قد يعامل برنامج لا يفهم message/global الجزء كمرفق مجهول. تسمح RFC 9755 في IMAP4rev1 الممكّن بصورتين صحيحتين لـBODYSTRUCTURE وتلزم العميل بقبولهما؛ ويتبع IMAP4rev2 ‏RFC 9051. تصحح الهوامش 8697 المصطلح إلى message/rfc822.

يجب أن يشمل corpus الصورتين في rev1، وصورة rev2، وترويسات دولية متداخلة، وجلب الجزء الخام. ظهور رمز مرفق لا يثبت أن البنية فُسرت كما خُزنت.

الجلب ليس الاكتشاف

بعد ENABLE لا يحمل SEARCH وسم charset، وينبغي أن تستخدم SORT وTHREAD ‏UTF-8. قد ينجح عميل قديم في LIST وFETCH ويفشل في البحث. سجّل الاستعلام وUIDs الناتجة للصيغ المركبة والمفككة والترويسات وأسماء الصناديق والمتن.

قد يصل إلى المخزن نفسه IMAP وPOP وبريد الويب وعملاء بقدرات مختلفة. الرفض أو الإشعار أو الإخفاء أو surrogate معياري سياسات وليست تكافؤاً. لا تعيد هذه المقالة حجة المقال السابق بشأن حيازة أصل surrogate؛ بل تطلب نتيجة معلنة ومرصودة لكل مسار مدعوم.

الإيصال الأخير عند المستخدم: هل يرى الصندوق، ويجد الرسالة، ويميّز الطرفين، ويفتح الأجزاء، ويرد حيث تسمح السياسة؟ المصادر تثبت دلالة المعايير وحداً تنفيذياً واحداً، لا انتشار منتج أو جودته. وبحسب تمييز Heng Lu بين التمثيل الرمزي والواقع القابل للتنفيذ، رمز القدرة تمثيل، والرسالة القابلة للاستخدام هي الواقع. وتشمل سلسلة المعايير أيضاً تدويل SMTP، وتحويل الرجوع، وسلوك POP المبسط، وخط أساس IMAP4rev2. تحد هذه النصوص دعاوى التشغيل البيني، ولا تحول نجاح مسار واحد إلى رؤية شاملة.