الخلاصة

  • يفرض RFC 9671 تجاهل بيانات التقويم المشوّهة، ورفض تمثيلات MIME المتعارضة، ومنع المعالجة إذا كان البريد أو المرفق المضمّن خبيثًا.
  • لا تثبت إشارات SPF أو DKIM أو DMARC أو S/MIME وحدها قصد المنظّم البشري أو سلامة كل محتوى مضمن.
  • تجمع قيمة updated التحديث والإلغاء والإزالة، ولذلك لا بد من قراءة لاحقة لـ UID والحالة والمشاركين والتنبيهات والمرفقات.

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

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

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

لا تبدأ العملية قبل أن يصبح الإدخال واحدًا وآمنًا

تضيف processcalendar إلى لغة Sieve القدرة على قراءة بيانات تقويم قابلة للمعالجة آليًا داخل رسالة MIME، ثم إضافة العناصر أو تحديثها أو إلغائها أو حذفها. البيانات المشوّهة يجب تجاهلها من دون فعل.

إذا احتوت الرسالة أجزاء MIME متعددة تحمل بيانات تقويم، فعلى التنفيذ التأكد من تكافئها دلاليًا. إن اختلفت، فلا يجوز معالجة الرسالة؛ وإن تطابقت، تُعالَج نسخة واحدة فقط. هذا يمنع أن يرى الإنسان وقتًا بينما يسجّل الجزء الآلي وقتًا آخر، أو أن تصبح تعددية الصيغ تعددية في الحقيقة.

كما لا يجوز للعملية أن تغيّر حالة مشاركة المستلم. إدخال الدعوة في التقويم ليس قبولًا للحضور. واجهة تعرض المشاركة على أنها مؤكدة بعد الإدخال وحده تنسب إلى المستخدم قرارًا لم يتخذه RFC 9671 نيابة عنه.

ويوصي المعيار بإزالة التنبيهات قبل التطبيق حتى لا تُطلَق إشعارات غير مرغوبة. لكن نتيجة :outcome لا تقول إن هذه الخطوة تمت. يلزم فحص التنبيهات بعد المعالجة.

مطابقة العنوان لا تكفي لإثبات السلطة

من دون :allowpublic يجب أن تكون الرسالة iTIP سليمة، وأن يطابق أحد عناوين المستلم الهدف الذي تحدده الطريقة: ORGANIZER في REPLY، وATTENDEE في REQUEST أو CANCEL أو ADD. وقد يأتي العنوان من ارتباط معروف بالحساب، أو من المستلم النهائي في الغلاف، أو من :addresses.

هذه مصادر مختلفة. عنوان ظاهر في رأس الرسالة ليس هو مسار التسليم النهائي بالضرورة. وإضافة alias في :addresses توسّع نطاق ما يعتبره script خاصًا بالمستخدم. أما تطابق ATTENDEE فيثبت جهة الاستهداف، لا صلاحية المنظّم ولا قبول المستلم.

يمكن لـ :organizers فرض قائمة خارجية للمنظمين. عند استخدامها، يجب أن تكون الرسالة iTIP صالحة وأن يطابق ORGANIZER القائمة. وعند غيابها لا ينفذ RFC 9671 هذا التحقق. وحتى عند التطابق، فالنتيجة تثبت سياسة محلية مهيأة، لا نية بشرية راهنة.

المصادقة دليل محدود وليست تفسيرًا كاملًا

يعترف RFC 9671 بأن تغيير التقويم بلا تفاعل من المستخدم قد يصبح قناة إساءة. البريد الموسوم spam أو malicious لا يجوز معالجته. وينبغي تفضيل مرسل معروف وتجنب مرسل محتمل الخبث أو غير موثوق. ويمكن أن تعتمد الثقة على S/MIME أو SPF أو DKIM أو DMARC.

لكل آلية موضوع خاص. SPF يصل عميل SMTP بسياسة تفويض النطاق. DKIM يتحقق من توقيع لنطاق على أجزاء محددة من الرسالة. DMARC يقيّم المحاذاة وسياسة المستقبل. S/MIME يتطلب فهم التوقيع والشهادة وربط الهوية.

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

كلمة updated لا تصف ما بقي

مع امتداد Variables يمكن أن تكون :outcome واحدة من no_action أو added أو updated أو error. ويمكن لـ :reason حمل تفسير، لكنه يكون سلسلة فارغة إذا لم يتوافر سبب. الفراغ نتيجة مسموحة ولا يجوز ملؤه لاحقًا بقصة غير مثبتة.

القيمة updated تشمل تعديل المحتوى، أو إلغاء العنصر، أو إزالته. إذا استُخدمت :deletecancelled فينبغي إزالة العنصر الملغى؛ وإذا لم تستخدم، يبقى العنصر موسومًا بالإلغاء. كلا المسارين قد ينتج updated، كما أن وجود الخيار لا يثبت أن الإزالة حدثت فعلًا.

:updatesonly يمنع إضافة UID جديد، وقد يجعل no_action دليلًا على أن الحاجز نجح. أما :calendarid فيحدد موضع العنصر الجديد، وبدونه يختار التنفيذ التقويم الافتراضي. نجاح الإضافة لا يثبت أن التقويم المختار هو الصحيح مهنيًا.

السجل القابل للدفاع يبدأ بمعرّف الرسالة، والمستلم النهائي، ونسخة script، وأحكام spam وmalware، وإشارات المصادقة، وكل أجزاء التقويم، وقرار التكافؤ، وطريقة iTIP، وUID، وORGANIZER، وATTENDEE، والقائمة، والخيارات، والتقويم المحسوم.

ثم تأتي قراءة الحالة الفعلية: هل يوجد UID؟ في أي تقويم؟ ما المراجعة وSTATUS؟ هل بقيت مشاركة المستلم بلا تغيير؟ هل أزيلت التنبيهات؟ هل فُك ترميز المرفقات وفُحصت قبل التعديل؟ هذه القراءة هي التي تميز قاعدة معلنة عن أثر وقع.

والبريد نفسه مسار منفصل. processcalendar لا تلغي implicit keep في Sieve. يمكن أن يتغير التقويم وتبقى الرسالة، أو يُحذف أحدهما ويبقى الآخر. وجود جانب لا يثبت مصير الجانب الثاني.

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

قوة RFC 9671 أنه يضع مواصفة دنيا مشتركة وحواجز واضحة. لا ينبغي تحويل هذه الحدود إلى ادعاء بأن علامة مصادقة أو كلمة نتيجة واحدة تحمل حقيقة النظام كلها.

Sources