الخلاصة

  • يعامل RFC 9787 المسودة المحفوظة والرسالة المرسلة كحالتين مختلفتين عملياً: يمكن حماية المسودة من خدمة صندوق البريد البعيدة، لكن تشفيرها يجب ألا يمنح المستلمين المقصودين قدرة على قراءتها قبل الإرسال الفعلي.
  • إذا حُميت المسودة، فيجب وفق لغة الوثيقة أن يكون تشفيرها لشهادة المستخدم نفسه أو لمفتاح سري مكافئ لا يملكه سواه، بينما لا يجوز لبرنامج MUA المتوافق توقيعها بمفتاح التوقيع العادي للمستخدم.
  • تظهر الفجوة التشغيلية الحاسمة عند تعدد برامج البريد: استمرار العمل على المسودة يتطلب وصول العميل الآخر إلى صندوق البريد وإلى مادة سرية قادرة على فك التشفير، فيما يقر RFC 9787 بأن المشاركة الآمنة للمفاتيح والشهادات بين عدة MUAs ليست محلولة في الوثيقة.
  • العلامات التي تسمي الرسالة «مسودة» في IMAP وJMAP تساعد على تمثيل حالة التخزين وسير العمل، لكنها لا تشكل بذاتها سياسة متكاملة تحدد من يستطيع فك النص أو متى يتحول إلى رسالة موجهة للمستلمين.

كائن واحد يغيّر سلطته أثناء الرحلة

RFC 9787، المنشور في أغسطس 2025 بوصفه RFC من فئة Informational وليس مواصفة Standards Track، يقدم إرشاداً لتنفيذ الحماية التشفيرية من طرف إلى طرف في البريد. وفي الفقرة 9.5 تصبح المسودة حالة أمنية قائمة بذاتها.

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

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

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

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

الاستئناف على جهاز ثان هو مشكلة مفاتيح أيضاً

عندما تعود المسودة إلى الظهور على جهاز آخر، لا يكفي أن يستطيع ذلك الجهاز رؤية صندوق البريد. عليه أيضاً أن يمتلك المفتاح السري القادر على فك المسودة. يربط RFC 9787 هذه المشكلة صراحةً بمسألة مشاركة الشهادات والمفاتيح المحلية بين عدة MUAs، ويضعها ضمن العمل المستقبلي في الملحق A.4.1.

الوثيقة تصف واقعاً بسيطاً: مستخدم واحد قد يشغل أكثر من MUA على الصندوق نفسه. لكنها لا تحدد بروتوكولاً معيارياً يوزع مادة المفتاح بين تلك البرامج بأمان. وتشير في الملحق A.4.2 إلى إمكانية الاعتماد على مفاتيح سرية محمولة ومدعومة بالعتاد بدلاً من نقل المادة السرية بين العملاء، مع الإقرار بأن الحاجة إلى تفاعل المستخدم عند الاستخدام قد تعقّد التجربة.

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

وجود تقنيات تشفير أساسية لا يملأ هذه الفجوة تلقائياً. S/MIME 4.0 يوفر آليات لإنشاء رسائل محمية تشفيرياً، كما يحدد OpenPGP بنى للتشفير بالمفاتيح العامة والسرية. لكن وجود هذين النظامين لا يقدم دليلاً على انتشار تنسيق معياري مشترك لمفتاح مسودة يتنقل بين برامج البريد المختلفة.

لماذا لا ينبغي توقيع النص غير المكتمل بالمفتاح المعتاد

الفاصل الآخر في الفقرة 9.5 يتعلق بالتوقيع. تقول الوثيقة إن MUA المتوافق MUST NOT أن يوقّع المسودة بمفتاح التوقيع العادي للمستخدم. تفسيرها تقني ودلالي في آن: التوقيع غير القابل للإنكار على نص لم يكتمل بعد يمكن أن يُستعمل، إذا تسربت المسودة، للقول إن صاحب المفتاح التزم بمحتوى لم يكن قد قرر الالتزام به.

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

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

علامات المسودة لا تحل مسألة السلطة

هناك بالفعل مفردات بروتوكولية تصف كون الرسالة مسودة. يعرف IMAP4rev2 علامة \Draft للرسالة التي لم يكتمل تأليفها. ويحدد RFC 6154 الخاصية \Drafts لصندوق مخصص عادةً للرسائل التي يجري إنشاؤها ولم ترسل بعد.

أما JMAP Mail فيعرف الكلمة $draft، ويعرض مثالاً لمسودة محفوظة يجري تقديمها للإرسال، ثم عند النجاح تزال حالة $draft وتنقل الرسالة من صندوق المسودات إلى صندوق المرسلة.

هذه الآليات مفيدة لأنها تجعل الانتقال قابلاً للتمثيل في حالة المخزن. لكنها لا تجيب وحدها عن الأسئلة التي يثيرها RFC 9787: هل النسخة المخزنة مشفرة؟ لمن؟ أي برنامج يمتلك مفتاح فكها؟ هل استُخدم مفتاح التوقيع العادي؟ ومتى، تحديداً، تحولت مجموعة مستلمين متوقعة إلى مجموعة يشفّر لها الكائن بالفعل؟

بعبارة أخرى، حالة «Draft» تستطيع وصف موقع الكائن أو وضعه في سير العمل. لكنها لا تثبت وحدها حدود السلطة التشفيرية.

اقتراح Daniel Kade: «إيصال حراسة نية المسودة»

هنا يمكن إضافة طبقة دليل صغيرة من خارج RFC 9787. ما يلي اقتراح تحريري لـ Daniel Kade، وليس مطلباً في RFC ولا معياراً قائماً: «إيصال حراسة نية المسودة».

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

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

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

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

من النص إلى التشغيل، لا العكس

يمكن استخدام ثلاث أفكار كتب عنها Heng Lu كعدسات تحريرية، لا بوصفها مبادئ لـ IETF أو متطلبات على RFC 9787.

عدسة Running-Code Primacy تذكر بأن التوصية المكتوبة ليست إثباتاً على وجود تنفيذ يعمل بين منتجات متعددة. في هذه القضية تحديداً، يقول RFC إن تقاسم المفاتيح بين عدة MUAs مهم ويترك تفاصيله خارج النطاق؛ لا يجوز للبحث الصحافي أن يحوّل الاعتراف بالمشكلة إلى ادعاء بأن الحل منشور ومتبنى.

وتفيد فكرة Minimum Initial Specification في إبقاء الحد المشترك صغيراً. فإذا استُخدم «إيصال حراسة نية المسودة»، ينبغي ألا يتحول إلى نظام يفرض شكلاً شاملاً على كل عميل وكل خدمة. أقل ما يحتاجه هو إثبات التحولات التي تفصل التخزين القابل للاستئناف عن الإرسال الفعلي.

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

وعند موعد هذا البحث، لم يظهر erratum مطابق لـ RFC 9787 في بحث RFC Editor عن errata. وتبقى صفحة معلومات RFC 9787 نقطة مرجعية لحالته المنشورة.

المصادر