الخلاصة

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

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

هذه المعرفة المحدودة هي نقطة انطلاق RFC 9698. نُشر المستند في يناير 2025، ويسجله RFC Editor بمعيار مقترح. يهدف إلى الانتقال التدريجي أو استخدام امتدادات JMAP داخل عميل IMAP. وهو يقدم آلية تسليم بين مسارين، لا شهادة بأن الانتقال اكتمل في خدمة بعينها.

الاستنتاج مرتبط بطريقة المصادقة

عندما تنجح LOGIN أو AUTHENTICATE ويدخل الخادم الحالة الموثقة، ينظر إلى الطريقة التي استخدمها العميل. إذا أمكنه استنتاج كفاية بيانات الاعتماد للمصادقة عبر JMAP، وجب أن يضيف JMAPACCESS إلى قوائم القدرات التي يرسلها بعد ذلك.

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

أمثلة البنية المشتركة في RFC ليست أدلة على أن مزودا مسمى يستخدمها اليوم. كما أن الإعلان لا يجعل كل وسيلة مقبولة في IMAP مقبولة تلقائيا في JMAP. القرار يتعلق بالاعتماد الذي استُخدم وبما يعرفه الخادم عن الطرف الآخر.

ما الذي يجب أن يبقى هو نفسه؟

تدعم الآلية التكافؤ الكامل لمجموعة الرسائل المتاحة عبر البروتوكولين. إظهار بعض المجلدات أو عينة متشابهة من البريد لا يفي بهذا الوصف، حتى لو حمل المنفذان الاسم التجاري نفسه.

ويتعهد الخادم بأن صندوق البريد أو الرسالة ذات object ID في أحد البروتوكولين تكون الكائن نفسه، بالمعرف نفسه، عند الوصول من الآخر. لهذا يجب أن يعلن أيضا OBJECTID المحدد في RFC 8474. لا يجوز التعامل مع UID عادي خاص بصندوق IMAP وكأنه أصبح معرفا عاما بين الأنظمة.

أما RFC 8620 فيحدد فرادة معرف سجل JMAP داخل نوع بيانات واحد وحساب واحد. الاحتفاظ بسلسلة المعرف وحدها في جدول المطابقة يسقط جزءا ضروريا من السياق. ويضيف RFC 8474 قيدا آخر: EMAILID يحدد المحتوى غير القابل للتغيير، لكن النسخ ذات EMAILID واحد قد تحمل كلمات مفتاحية مختلفة. هوية المحتوى لا تثبت تساوي جميع الحالات القابلة للتعديل.

العنوان يفتح عملا جديدا

يطلب العميل عنوان الجلسة باستخدام GETJMAPACCESS. إذا عرف خادم IMAP خدمة JMAP المقابلة، يعيد استجابة JMAPACCESS غير موسومة تحتوي على رابط Session واحد، ثم OK موسومة. وإذا لم يعرفها، يعيد BAD ولا يجوز له إعلان القدرة.

يوجد خطأ مهم لمن ينسخ المثال كما هو. التصويب التقني 8635، الذي جرى التحقق منه في 21 نوفمبر 2025، يستبدل الأمر JMAPACCESS في المثال الثاني بالأمر الصحيح GETJMAPACCESS. إنه تصحيح لمثال، وليس بلاغا عن اختراق أو تغييرا لنظام المصادقة.

الرابط يقود إلى مورد Session. لا بد بعد ذلك من نجاح GET موثق كي يحصل العميل، بحسب RFC 8620، على كائن يصف الحسابات والقدرات المتاحة لبيانات الاعتماد المقدمة. الحصول على العنوان ونجاح هذا الطلب واقعتان مختلفتان. الامتداد لا ينشئ سرا جديدا، ولا يعفي الطرف الآخر من التحقق عند الدخول.

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

الوقت والعرض يظلان متغيرين

يمكن أن تُحذف رسالة بعد قراءتها عبر IMAP وقبل طلبها عبر JMAP بنصف ثانية. يذكر RFC 9698 هذا الاحتمال صراحة، لأنه لا يغير عمر الرسالة. عدم العثور عليها في القراءة الثانية يحتاج إلى سجل زمني أو دليل حذف قبل تفسيره على أنه خلل في الهوية المشتركة.

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

العناوين الدولية تكشف حد التمثيل. في ظروف IMAP القديم التي يصفها RFC 9698، قد يؤدي عدم تفعيل UTF8=ACCEPT إلى حقول مخفضة بينما يقدم JMAP الحقول الدقيقة. يشرح RFC 6855 أن البدائل ليست قابلة للاستعاضة عن الأصل في كل الاستخدامات، ومنها الرد والتحقق من بعض التوقيعات. تطابق المعرف لا يصلح اختلاف التمثيل، ولا ينبغي تعميم هذه الحالة على كل جلسة IMAP4rev2.

تقدم كتابات Lu Heng عن المواصفة الأولية الدنيا، وأولوية الشيفرة العاملة، وطبقات الواقع إطارا تحريريا لهذه الحدود: الاتفاق المشترك صغير، وتبنيه ونتيجته مسؤولية الأنظمة التي تنفذه. الحقائق التقنية هنا مصدرها مستندات البروتوكول نفسها.

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