الخلاصة

  • عرّفت RFC 3503 الكلمة المشتركة $MDNSent كي تعرف برامج البريد المتعددة التي تستخدم صندوق IMAP واحداً أن عليها ألا تولّد إشعار تصرّف آخر.
  • لم تكن العلامة سجلاً مؤكداً للإرسال؛ فقد تُكتب بعد رفض المستخدم، أو على نسخة مرسلة، أو على رسالة غير مكتملة، أو بعد معالجة آلية لم ينتج عنها إشعار فعلي.

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

عالجت RFC 3503، المنشورة في مارس 2003، المشكلة بأداة صغيرة. لم تضف أمراً جديداً إلى IMAP ولا استجابة جديدة. عرّفت كلمة خاصة بالصندوق هي $MDNSent، وطلبت من وكلاء مستخدم البريد قراءة هذا السجل المشترك واحترامه. صار الصندوق يحمل الحد الأدنى من الذاكرة اللازمة بين عملاء مستقلين.

يوحي الاسم بأن إشعار التصرّف قد أُرسل. إلا أن قواعد الكتابة لا تسمح بهذا الاستنتاج. عند المعالجة الآلية كان العميل يضع العلامة سواء أُرسل MDN أم لم يُرسل. وإذا رفض المستخدم الإشعار، جاز للعميل وضع العلامة كي لا يرسله برنامج آخر لاحقاً. وعند حفظ نسخة من رسالة مرسلة كان ينبغي وضعها، وكذلك عند حفظ رسالة غير مكتملة.

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

قبل الاعتماد على الحالة المشتركة، كان على العميل فحص PERMANENTFLAGS. على الخادم أن يدعم $MDNSent بعينها أو الكلمات التعريفية الاعتباطية. لكن إعلان القدرة لا يساوي نجاح كل كتابة. قد يرفض الخادم STORE بالجواب NO لأن الصندوق بلغ الحد الأقصى للكلمات التي يستطيع الاحتفاظ بها.

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

لم يكن من المقبول إعادة استخدام الأعلام القائمة كيفما اتفق. حظرت المواصفة الاعتماد على \Recent لأن IMAP لا يحدد، عند اختيار اتصالات متعددة الصندوق نفسه، أي اتصال سيرى الرسالة حديثة. المعلومة التي لا تظهر لكل المشاركين لا تصلح لتوزيع المسؤولية. يمكن أن يساهم \Seen في قرار عدم الإرسال، بينما يمنع \Draft إشعار رسالة ناقصة، لكن لكل منهما معنى مستقل. وإذا حضرت $MDNSent وجب تجاهل بقية الأعلام لهذا القرار.

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

كان النسخ نقطة ضعف محتملة. ينبغي للعميل التحقق من أن COPY يحافظ على $MDNSent. وعند النسخ بين خادمين بواسطة APPEND يجب إضافة الكلمة بصورة صحيحة. وصول المحتوى من دون حالة المنع يجعل فقدان البيانات الوصفية يبدو كأنه إذن جديد.

أظهرت قاعدة ACL فصل السلطات. ظل الخادم ملزماً بالتحقق من حق العميل في نسخ الرسالة. لكن إذا كان النسخ مسموحاً، أوصت RFC 3503 بالحفاظ على $MDNSent حتى عندما لا يملك العميل حق الكتابة العام على الأعلام. حق نقل الكائن ليس حق تعديل أي حالة، وحفظ خاصية التنسيق ليس منحة سلطة إضافية.

ولا تنشئ حالة الأحرف حالات مستقلة. تعاملت الأمثلة مع $MdnSENt و$MdnSENT و$mdnsent على أنها كلمة واحدة. لو رأى كل عميل تهجئة مختلفة ككيان مستقل لانقسمت الذاكرة المشتركة وفشل الغرض منها.

أما MDN نفسها فلها سلسلة أدلة أخرى. عرّفت RFC 2298 الصيغة المبكرة، ثم نقحتها RFC 3798، وأصبحت RFC 8098 معيار الإنترنت STD 85. حتى قيم التصرّف فيها محدودة: displayed تعني أن برنامج البريد عرض الرسالة لشخص ينظر في الصندوق، ولا تضمن أنه قرأ المحتوى أو فهمه. وقد يعني processed قاعدة آلية بلا إنسان، ولا يعني deleted أن الرسالة لم تُر من قبل أو لن تُستعاد.

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

جعل RFC 5788 المعنى أوضح حين سجل الكلمة: $MDNSent كلمة مشتركة تحدد أنه يجب عدم إرسال MDN لرسالة تحملها. هذا تعريف لمنع لاحق، لا شهادة على إرسال سابق.

ربط RFC 9007 في JMAP الإجراء بالحالة بصورة أوثق. يجب أن تقترن MDN/send بتحديث $mdnsent، وعلى الخادم رفض العملية إذا لم تؤد إلى هذا التحديث، ويمكنه إرجاع mdnAlreadySent عند وجود العلامة. يقلل ذلك الفجوة داخل JMAP، لكنه لا يثبت القراءة البشرية أو وصول الإشعار، ولا يغير متطلبات أنظمة 2003 بأثر رجعي.

المراجعة السليمة تفصل درجات السلم. PERMANENTFLAGS إعلان قدرة، وSTORE OK قبول لتغيير حالة، ووجود $MDNSent أمر بوقف التوليد لاحقاً. إنشاء الإشعار وتقديمه ونقله ووصوله تحتاج سجلات مستقلة. قيمة التصرّف ادعاء محدود. الانتباه والفهم والفعل البشري أبعد من ذلك.

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

كلما بدا اسم الحقل كأنه نتيجة نهائية، وجب فحص جميع الطرق التي تكتبه. في حالة $MDNSent، قد تكون العلامة صحيحة تماماً لأن القرار كان ألا يخرج أي إشعار. إنها تقول «توقف»، لا «حدث الإرسال».

المصادر