الخلاصة

  • يتيح RFC 5232 لـ Sieve تكوين مجموعة علامات وفحصها للرسالة الجاري التعامل معها، ثم إرفاقها بالنسخة التي يسلّمها keep أو fileinto.
  • لا يحوّل ذلك المرشح إلى أداة عامة لتحرير مخزن IMAP: يجب تجاهل العلامات التي لا يستطيع صندوق البريد حفظها بصورة دائمة، من دون اعتبار ذلك وحده إخفاقًا وقت تشغيل النص.

العلامة ترافق قرار التسليم

تمر الرسالة الواردة بالتحليل والتوجيه، ثم تصل إلى صندوق بريد. وعلامة IMAP حالة مرتبطة برسالة مخزنة. ربط RFC 5232، المنشور في يناير 2008، لغة Sieve بهذه الحالة، لكنه لم يلغِ الفرق بين اختيار مصير الرسالة الجاري فحصها وبين إعادة كتابة صندوق كامل.

تفرض إضافة imap4flags أربع عمليات أو اختبارات: setflag وaddflag وremoveflag وhasflag، كما تضيف الوسيط :flags إلى keep وfileinto. تدير العمليات الثلاث الأولى مجموعة من العلامات، أما hasflag فيتحقق من وجود أسماء محددة. ويعبر وسيط التسليم بمجموعة العلامات إلى نسخة الرسالة الحالية التي تُودع في الصندوق المستهدف.

هذه المجموعة حالة محلية لتنفيذ Sieve واحد. تبدأ المتغيرات الداخلية فارغة؛ ويستبدل setflag المجموعة، ويضيف addflag إليها، ويحذف removeflag منها، بينما يفحص hasflag قيمتها الحالية. إذا دعم المحرك إضافة Variables المنفصلة، أمكن للنص استخدام مجموعات مسماة أيضًا. أما دونها، فيؤدي تمرير اسم متغير صريح إلى خطأ. أسماء العلامات غير حساسة لحالة الأحرف، ولا يجوز للنص افتراض الحفاظ على ترتيبها أو شكلها أو تكراراتها.

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

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

ويضع صندوق البريد المستهدف حدًا آخر. يحدد :flags العلامات المطلوبة للنسخة المسلّمة، لكنه لا يضمن أن كل مخزن يستطيع حفظها دائمًا. يجب على المفسّر تجاهل العلامات غير القابلة للحفظ الدائم، وألا يحوّل هذا القيد إلى إخفاق تشغيل في Sieve. يوضح RFC أن fileinto :flags "\\Deleted" يعادل fileinto بلا هذا الطلب إذا كان الصندوق لا يستطيع تخزين العلامة. وفي IMAP تشير \\Deleted إلى انتظار الطرد اللاحق للرسالة، ولا تثبت محوها فعليًا.

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

حتى عند اجتماع إجراءات تسليم عدة في نسخة واحدة، توجد أولوية محددة: إذا أزيلت النسخ المكررة الناتجة عن عدة إجراءات keep أو fileinto، فيجب أن تفوز آخر قائمة علامات. لذلك لا يلزم أن تضم النسخة الباقية كل ما أراده كل فرع سابق. ينبغي تتبع ترتيب الإجراءات وآلية التسليم، لا جمع كل استدعاء لـ addflag واستنتاج الحالة النهائية منه.

ينتمي RFC 5232 إلى عائلة Sieve إلى جانب اللغة الأساسية في RFC 5228، والمتغيرات في RFC 5229، والاختبارات العلائقية في RFC 5231. تشرح تلك المواصفات معالجة القواعد والقيم، ولا تبدل حدود التسليم. وفي RFC 9051 الأحدث، تمييز بين العلامات الدائمة وتلك المقصورة على الجلسة، مع إهمال \\Recent. فالعلامة المطلوبة ليست مرادفًا لحالة دائمة. يحدد المعيار عقدًا بروتوكوليًا؛ ولا يثبت تطبيق خادم بعينه له، أو وصول رسالة إلى قارئ، أو ظهور رمز في واجهة.

المصادر