الخلاصة

  • يقرأ اختبار environment قيماً يوفرها مفسر Sieve عن سياق التشغيل؛ توحيد اسم العنصر لا يوثق مصدر قيمته ولا مقدار الثقة فيها.
  • يحذر RFC 5183 صراحة من أن remote-host قد يأتي من سجل PTR غير موثوق، لذلك لا يثبت تطابق اللاحقة أن الاتصال داخلي.

أظهر سجل التدقيق اسم المضيف الداخلي، ونوع الخدمة MS، والمرحلة post، واسم المنتج وإصداره. بدا السجل غنياً بما يكفي ليشرح القرار، لكنه كشف بنية المؤسسة أكثر مما أثبتها.

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

هذه حالة تحليلية وليست وصفاً لحادث مسمى. وهي تضع مفارقة RFC 5183 في مركز القرار: قد تزيد بيانات السياق مساحة الإفصاح من دون أن تزيد سلطة الدليل بالمقدار نفسه.

ما يقوله المفسر وما لا يقوله

تضيف المواصفة قدرة environment. يحدد البرنامج اسم العنصر وقائمة القيم التي يقارن بها، ويمكنه اختيار المقارن ونوع المطابقة. الافتراضيان هما :is وi;ascii-casemap.

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

تتوزع العناصر الأولية على طبقات. يصف domain نطاق DNS المرتبط بالسياق، ويصف host المضيف الذي ينفذ البرنامج. يصنف location الخدمة إلى MTA أو MDA أو MUA أو مخزن رسائل. يضع phase التنفيذ قبل التسليم النهائي أو أثناءه أو بعده. يصف name وversion المنتج، بينما يصف remote-host وremote-ip عميل SMTP أو LMTP أو Submission عند إمكان ذلك.

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

الغياب والقيمة الفارغة والثقة

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

يمكن استعمال مطابقة :contains مع سلسلة فارغة لمعرفة أن العنصر معروف، لأن كل سلسلة معادة تحتوي السلسلة الفارغة. لكن المعرفة لا تعني أن القيمة مفيدة. يعيد remote-host سلسلة فارغة عندما يتعذر الحصول على الاسم.

ومع امتداد العلاقات، تكون نتيجة :count صفراً إذا كانت المعلومة فارغة وواحداً إذا لم تكن. هذا عدّ لقيمة واحدة، لا قياس لموثوقيتها أو عدد مصادرها.

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

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

قد يختار الطرف غير الموثوق الاسم الذي يرضي القاعدة

تقول اعتبارات الأمن إن التطبيق يستطيع استعمال أي تقنية لتحديد remote-host، وإن موثوقية النتيجة تختلف. الطريقة الشائعة هي استعلام PTR لعنوان العميل، وقد تأتي المعلومة من مصدر غير موثوق.

من يملك السجل العكسي يستطيع نشر اسم يشير إلى نطاق يختاره. لذلك ليست قاعدة تطابق *.example.com طريقة سليمة لتحديد ما إذا كانت الرسالة جاءت من الخارج. يمكن أن تكون إجابة DNS صحيحة والمقارنة صحيحة، بينما تكون دلالة «داخلي» خاطئة.

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

remote-ip أقرب إلى ملاحظة النقل، لكنه قد يكون عنوان relay أو proxy أو خدمة إرسال مشتركة. يجب أن تصف البنية المحلية أي قفزة يمثلها العنصر، وأي صلاحية يمكن أن تنقلها تلك القفزة.

تقليل الإفصاح من دون إفقار الإثبات

ينبه RFC 5183 إلى أن عناصر البيئة قد تكشف تفاصيل بنية مقدم الخدمة أو المؤسسة. أسماء المضيفين والمنتجات والإصدارات ومواقع التنفيذ يمكن أن تساعد الخصم على رسم النظام.

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

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

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

المرحلة والموقع يحددان نقطة الملاحظة

يقول location=MS إن مخزن رسائل يقيّم البرنامج. لا يحدد العقدة أو النسخة أو المعاملة. ويقول phase=post إن المعالجة بعد التسليم النهائي وفق النموذج، لكنه لا يثبت النسخ أو الفهرسة أو رؤية العميل.

يوسع RFC 6785 النموذج لأحداث IMAP. يثبت location على MS وphase على post، ويضيف المستخدم والبريد والسبب وصندوق البريد والأعلام المتغيرة.

تبقى قيمة imap.mailbox ثابتة منذ بدء البرنامج، حتى إذا نفذ fileinto إلى مكان آخر. إنها وصف للبداية لا للنتيجة. وimap.changedflags لا يبين هل تم ضبط كل علم أم مسحه؛ يلزم اختبار الحالة الحالية.

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

السجل ينسق الأسماء ولا يصدر شهادات

تُعرّف العناصر القياسية في RFC معياري أو تجريبي، وتبدأ عناصر المورد بـ vnd.. يعرض سجل IANA الحالي العناصر الأصلية، وإضافات IMAP، ومساحة مورد.

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

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

يسمح RFC 5463 باختبار القدرات بواسطة ihave. وجود القدرة، ووجود عنصر البيئة، ووجود قيمة غير فارغة، والثقة في المصدر أربع دعاوى مختلفة. إدارة البرنامج عبر ManageSieve لا تثبت أي عامل نفذه لهذه الرسالة.

إيصال يحمي السرية والسلطة معاً

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

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

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

المصادر

  1. RFC 5183 — HTML
  2. RFC 5183 — نص مجرد
  3. صفحة معلومات RFC Editor
  4. صفحة الوثيقة في IETF Datatracker
  5. سجل الوثيقة في IETF Datatracker
  6. مراجع الوثيقة في IETF Datatracker
  7. تصويبات RFC 5183
  8. RFC 5228 — مواصفة Sieve الأساسية
  9. صفحة معلومات RFC 5228
  10. RFC 5231 — الامتداد العلاقي
  11. RFC 5598 — معمارية بريد الإنترنت
  12. RFC 6785 — أحداث IMAP في Sieve
  13. صفحة معلومات RFC 6785
  14. RFC 5804 — ManageSieve
  15. RFC 5463 — امتداد Sieve ihave
  16. سجل IANA لامتدادات Sieve
  17. سجل IANA لعناصر بيئة Sieve
  18. Heng Lu — طبقات الواقع
  19. Heng Lu — المواصفة الدنيا والتبني الطوعي
  20. Heng Lu — أولوية الشيفرة العاملة