John Levine يضع تاريخاً لانتهاء البريد. مفتاح الحذف يبقى مع صاحبه

Summary

• نشر John Levine وBenjamin Billon RFC 10080 في أكتوبر 2026 لتصبح ترويسة Expires قابلة للاستخدام في البريد الإلكتروني العادي. كان RFC 4021 قد سجّلها مع تقييد الاستخدام العام.
• يحق للمرسل كتابة تاريخ انتهاء واحد. يمكن لبرنامج البريد تخفيف ظهور الرسالة بعده، لكن المواصفة تمنع رفض الرسالة أو إسقاطها بسبب الترويسة وحدها، وتجعل حذفها رهناً بإعداد يختاره مالك الصندوق عمداً.

التاريخ الذي يعرفه البائع

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

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

رسم Levine وBillon الحدود بدقة: حقل Expires واحد على الأكثر؛ تخفيف العرض أو إخفاء الرسالة خيار عند جهة الاستقبال؛ الرفض أو الإسقاط اعتماداً على هذا الحقل وحده محظور. ويحتاج الحذف إلى قاعدة أعدّها صاحب الصندوق بقصد. انتهى العرض؟ هذه معلومة مفيدة. اختفت الرسالة التي وعدت به؟ تلك مسألة سلطة مختلفة.

سجّلوا الحقل، وتركوا القرار للناس

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

تُظهر صفحة John R. Levine في IETF سجلّه الطويل في معايير البريد. في هذا العمل المشترك مع Billon، يتجاوز أثره سطر التاريخ: المرسل يصف صلاحية محتواه، والمتلقي يحتفظ بحق مراجعة ما تسلّمه. الدليل العملي التالي هو وصف من مزود بريد يوضح كيف يجد المستخدم الرسالة المنتهية وكيف يبلغ عنها وكيف يختار الاحتفاظ بها.

المصادر: RFC 10080؛ RFC 4021؛ سجل IANA؛ صفحة IETF.