المجلد البديل ليس مخزناً للفائض: حدود التحويل في Sieve

الخلاصة

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

من يقرر أين سيبحث القارئ عن الرسالة؟

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

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

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

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

المجلد الثاني ليس إذناً مفتوحاً بتغيير موضع البريد. إنه جواب عن حالة محددة في اختيار الوجهة.

الاسم والوظيفة لا يدلان دائماً على المكان نفسه

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

تعالج RFC 6154 هذا الجانب في IMAP بسمات مثل \Archive و\Drafts و\Junk. يستطيع العميل التعرف إلى وظيفة الصندوق بدلاً من استنتاجها من اسم مجلد قد لا يعرف لغته أو دلالته.

وتتيح RFC 8579 لمرشح Sieve استخدام هذه المعلومات عبر المعامل :specialuse. يبحث الإجراء أولاً في فضاء الأسماء الشخصي للمستخدم عن صندوق يحمل السمة المطلوبة. إذا وجده، يختاره بدلاً من الوجهة المحددة بالاسم في المعامل الاعتيادي.

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

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

الصندوق الممتلئ لم يختف

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

تبرر RFC 8579 منع التحويل بعد هذا النوع من الفشل بأنه يحول دون توزيع الرسائل بصورة غير متوقعة بين صندوقين عند وقوع أعطال عابرة أو متقطعة.

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

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

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

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

الاختبار الإيجابي ليس حجزاً للمساحة

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

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

وتحيل RFC 8579 إلى تعريف قابلية الإيداع في RFC 5490. هذه الوثيقة تنبه صراحة إلى أن نجاح اختبار الوجود لا يضمن نجاح الحفظ اللاحق: قد تؤدي الرسالة إلى تجاوز الحصة.

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

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

حين تشترك عدة صناديق في الاستخدام نفسه

الاستخدام الخاص ليس بالضرورة عنواناً فريداً. تسمح RFC 8579 بأن تحمل عدة صناديق في الفضاء الشخصي السمة نفسها.

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

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

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

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

تهيئة الاستخدام مهمة مستقلة عن دعم الميزة

سمات الاستخدام في RFC 6154 اختيارية. وإنشاء صندوق مع تعيين استخدام خاص يحتاج إلى قدرة منفصلة هي CREATE-SPECIAL-USE. كما أن السماح بتعديل التعيينات عبر البيانات الوصفية يعتمد على الخادم وعلى فحوص صحة التغيير التي يجريها.

تقدم سجلات تصحيح RFC 6154 مثالاً تاريخياً على ما يحدث حين لا تتحدد مسؤولية البداية. يصف السجل 4422 اختبار توافق غير رسمي في 19 يوليو 2015، افترض فيه خادم أن العميل سيهيئ تعيينات الاستخدام، وافترض فيه عميل أن الخادم سيفعل ذلك.

حالة السجل هي Held for Document Update، أي احتفاظ بالملاحظة لتحديث الوثيقة. اقتراحاته ليست متطلبات إلزامية جديدة نافذة، ولا يجوز استخدامها لتشخيص خدمات حالية لم تُفحص. لكنها توثق فجوة واضحة بين دعم الآلية وتكليف جهة بإقامة حالتها الأولية.

إذا غاب كل من الصندوق الخاص والصندوق الافتراضي، تنطبق قواعد الوجهة غير الموجودة. يطلب المعامل الصريح :create إنشاء الصندوق المحدد بالاسم عند الحاجة. وعندما يدعم الخادم CREATE-SPECIAL-USE، توصي RFC 8579 بإعطاء الصندوق الجديد السمة المطلوبة. التوصية ليست ضماناً موحداً لكل تطبيق.

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

توسيع البحث يوسع دائرة التأثير

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

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

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

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

حدود الأدلة

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

تتيح مقالة Lu Heng عن مشكلة الوكالة سؤالاً مناسباً: هل يتحمل صاحب القرار التكلفة التي ينقلها؟ قد يحسن الكاتب الآلي إحصاء نجاحه، بينما يتحمل القارئ والدعم تكلفة جمع مراسلات موزعة.

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