الخلاصة

  • صاغ RFC 3028 ترشيح البريد كلغة إجراءات محدودة، وأضاف الحفظ الضمني عندما لا ينفذ النص إجراءً يلغي التسليم الافتراضي.
  • أوامر keep وfileinto وredirect وdiscard والرفض كانت قرارات عند حدود المفسر، لا دليلاً على تخزين دائم أو قبول بعيد أو نتيجة تسليم نهائية.

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

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

الحالة التي لم تطابق قاعدة احتاجت إلى حماية

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

لهذا عرّف RFC 3028 الحفظ الضمني. إذا لم يقع إجراء يلغيه، ينفذ النظام تصرفه الاعتيادي، وغالباً ما يضع الرسالة في صندوق المستخدم الرئيسي.

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

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

كل إجراء سلّم التحكم إلى مكوّن آخر

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

حدد fileinto مجلداً. أوصى RFC 3028 بدعمه مع اعترافه بأن بعض البيئات لا تستطيع توفيره. كان الاسم تعليمة لوكيل التسليم، لا شهادة بوجود المجلد أو دوام الكتابة.

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

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

تفاعل الإجراءات كان حوكمة للآثار

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

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

حل RFC 5228 محل RFC 3028 مع إبقاء الحفظ الضمني وبنية الإجراءات، ووضح الأخطاء والحدود. ثم أنشأ RFC 9122 سجل IANA لإجراءات Sieve، وفيه حقول للتفاعل ولما إذا كان الإجراء يلغي الحفظ الضمني. يوثق السجل العقود، لا نجاح رسالة بعينها.

كشف الرفض كلفة القبول قبل القرار

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

أضاف RFC 5429 إجراء ereject الذي يفضل الرفض أثناء جلسة SMTP أو LMTP متى أمكن. ووضح أن الرفض يلغي الحفظ الضمني، ومنع أكثر من رفض واحد، ونصح بعدم جمعه مع إجراءات التسليم. السبب هو صدق النتيجة: لا ينبغي للنظام أن يعلن عدم التسليم ثم يخزن الرسالة أو يحولها.

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

وضع ManageSieve في RFC 5804 سطحاً إدارياً منفصلاً لرفع النصوص وفحصها وسردها وتفعيلها. النص الفعال لا يثبت أنه عالج رسالة محددة، واختيار الإجراء لا يثبت نتيجته. الإدارة والقرار والأثر سجلات مستقلة.

المصادر

لم يكتب Lu Heng أو يؤيد RFC 3028 أو RFC 5228 أو RFC 5429. تستخدم مقالاته هنا كعدسات تحليلية معلنة.