الخلاصة

  • يسجّل RFC 9979 سبع عشرة كلمة مفتاحية لرسائل IMAP/JMAP وثلاث سمات لأسماء صناديق البريد، مع تمييز من يضع كل حالة وما إذا كانت إرشادية أو قادرة على تحريك إجراء.
  • $muted قد يبقى أثراً لقرار اتخذه مهاجم، و$istrusted ادعاء من الخادم، و$unsubscribed سجل محاولة، وScheduled مكان تخزين. لا يثبت أي منها النتيجة الأوسع وحده.

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

هذه واقعة افتراضية وليست تقريراً عن خدمة أو اختراق حقيقي. حدّها الفني يأتي من RFC 9979، وهو مستند IETF معلوماتي نُشر في مايو 2026. يعرّف المستند سبع عشرة كلمة مفتاحية وثلاث سمات لصناديق البريد كانت مستخدمة في تطبيقات مختلفة، ثم يسجّلها لتجنّب تصادم الأسماء. الاتفاق على الاسم لا يطهِّر الحالة التي وصلت عبره.

يعرض سجل IANA لكلمات IMAP وJMAP المفتاحية الاسم والنوع والاستعمال والنطاق والمرجع. ويسجّل دليل سمات أسماء صناديق IMAP أسماء مثل Memos وScheduled وSnoozed. تلك السجلات تنسّق مساحة الأسماء؛ لا تفحص رسالة بعينها ولا تراقب محاولة إلغاء اشتراك ولا تشهد على تسليم.

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

أنشأ RFC 5788 سجل الكلمات المفتاحية، وقدّم RFC 8457 نموذجاً سابقاً لمعنى «المهم». ويعرّف RFC 9051 IMAP4rev2، بينما يعرّف RFC 8621 بريد JMAP. تطابق العرض عبر البروتوكولين دليل اتساق، لا دليل صحة مستقل.

يكشف زوج المرفقات الفرق بين الغياب والنفي. لا يجوز أن يجتمع $hasattachment و$hasnoattachment. لكن غياب الأول لا يعني الثاني؛ فقد لا يكون التحليل قد جرى أصلاً. لذلك توجد ثلاث حالات: مرفق موجود، وفحص أكد عدم وجوده، وحالة مجهولة. الواجهة التي تعرض مشبكاً أو فراغاً قد تمحو الفرق بين النفي والجهل.

يجب أن تعكس خاصية hasAttachment في JMAP المعلومة ذاتها. فإذا اتفق البروتوكولان، نعرف أن الإسقاط متسق. لا نعرف أي محلل MIME عمل، ولا أي نسخة فحص، ولا متى أصبح حكمه قديماً. قد تنسخ كل الأجهزة الخطأ نفسه من المصدر نفسه.

أما المذكرات فتتطلب تحديث علاقة من طرفين. يوضع $memo على رسالة الملاحظة، ويوضع $hasmemo على الرسالة التي شُرحت. ويجب تعديل الطرفين عند الإنشاء أو الحذف. يوفّر RFC 8474 هوية للكائن والسلسلة تساعد على العنونة؛ لكنه لا يجعل عمليتي الكتابة معاملة ذرّية. إذا انقطع العميل بينهما، يبقى وسم صحيح الصياغة لعلاقة لم تعد موجودة.

لـ$istrusted أثر أشد. يضعه الخادم بوصفه إشارة إرشادية إلى أنه تحقق بدرجة ثقة عالية من اسم المرسل وعنوانه. يحذر RFC 9979 من أن سوء وضعه قد يدفع المستخدم إلى الوثوق برسالة احتيالية، وينص على أنه لا يجوز الاعتماد فقط على نجاح SPF أو DKIM أو DMARC.

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

ولا يحدد RFC 9979 خوارزمية عالمية أو عتبة رقمية لـ«الثقة العالية». يحق للمشغل استخدام معرفة محلية، وعليه في المقابل حفظ أصل الادعاء: الخادم، نسخة القاعدة، أصناف الأدلة، مستوى الثقة، الوقت، الانتهاء، سبب السحب، والمالك المسؤول. قد يختصر العميل ذلك في شارة، لكن لا ينبغي أن تكون قوة الشارة أكبر من قوة الملف.

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

في إلغاء الاشتراك، يشير $canunsubscribe إلى وجود آلية List-Unsubscribe متوافقة اجتازت أيضاً اختبارات السمعة الخاصة بالخادم. يعرّف RFC 8058 إشارة النقرة الواحدة. هذه أهلية لعرض الإجراء، لا إثباتاً لتنفيذه.

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

$new لا يثبت حداثة الرسالة. قد يوضع على رسالة قديمة خرجت من snooze كي تستعيد انتباه المستخدم. و$notify يطلب من عميل داعم إظهار تنبيه إذا سمحت تفضيلات المستخدم. الطلب والعرض والمشاهدة والاستجابة أربع وقائع، لا وسم واحد.

كذلك يحدد Snoozed مكان حفظ الرسائل المؤجلة مؤقتاً، ولا يعرّف آلية الإيقاظ أو واجهتها. ويحدد Scheduled الصندوق الذي توجد فيه رسائل يُراد إرسالها لاحقاً. وجود الرسالة هناك لا يثبت تشغيل المجدول أو قبول خادم النقل أو وصولها. يجب حفظ وقت الخطة، ومحاولة التنفيذ، ورد النقل، والنتيجة النهائية على حدة.

$followed و$muted متعارضان؛ وإذا اجتمعا يُعامل الخيط على أنه followed. القاعدة تمنع اختلاف التطبيقات في السلوك، لكنها لا تفسر كيف ظهر التضارب. ويذكر RFC 9979 أن من يسيطر على الحساب يستطيع كتم سلاسل يريد إخفاء ردودها، ويوصي عند استعادة الوصول بمراجعة أفعال الكتم وتأكيدها أو عكسها.

لهذا لا تكفي إعادة تعيين الاعتماد. الحالة المتزامنة تشمل قرارات تتحكم بما يراه صاحب الحساب. استرداد الهوية دون مراجعة mutes والفلاتر والتنبيهات يترك جزءاً من سلطة المهاجم يعمل بعد خروجه.

تحدد صفحة معلومات RFC وبحث التصحيحات النسخة الوثائقية. لا تثبتان تطبيقاً أو خوارزمية أو بريداً أو حادثاً أو نتيجة. كما أن جهة عمل المؤلف ليست دليلاً على نشر الميزة.

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

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

يجعل RFC 9979 الحالة قابلة للحمل. والمسؤولية هي ألا تُحمّل الحالة معها نتيجة لم تحدث.

المصادر