الخلاصة
- أقرت IESG في 8 مايو 2026 الوثيقة
draft-ietf-mailmaint-expires-06بصفتها Proposed Standard. يحدد الحقل تاريخاً تفقد الرسالة بعده صلاحيتها، من دون فرض نتيجة تشغيلية واحدة. - لا يجوز لبرمجيات البريد رفض الرسالة أو إسقاطها بسبب
Expiresوحده، ولا ينبغي حذف رسالة ذات تاريخ منقض ما لم يكن مالك صندوق البريد قد أعد هذا السلوك عمداً.
الإشارة يكتبها طرف له مصلحة
قد تنتهي فائدة رسالة قبل أن تنتهي قيمتها كسجل. العرض التجاري يتوقف، والفعالية تمر، والتنبيه الاجتماعي يصبح قديماً، والنشرة الدورية تستبدل. من المفيد ألا تزاحم هذه المواد الرسائل العاجلة إلى الأبد.
يوفر Expires وقتاً واضحاً لهذه الغاية. يتبع الحقل صيغة date-time في RFC 5322، ولا يجوز لمنشئ الرسالة أن يضع أكثر من حقل واحد. بعد الموعد المعلن، تفقد الرسالة صلاحيتها وفق التعبير الذي اختاره المعيار.
لكن كلمة الصلاحية لا تعني الحذف أو الرفض أو الإخفاء أو الاستدعاء. لم يتوصل العمل الفني إلى معنى معياري أدق، كما أن التطبيقات السابقة لم تتصرف بطريقة موحدة. الإقرار بهذا الحد أدق من اختراع أمر لم يتفق عليه أحد.
والسبب العملي أهم من الصياغة. المرسل هو الذي يختار التاريخ. قد تستفيد شركة من اختفاء شروط عرض قديم، وقد يفضل مصدر تعليمات محل نزاع أن يصعب العثور عليها لاحقاً. لذلك يظل الموعد ادعاءً من المنشئ، لا موافقة من المتلقي على التصرف في سجله.
ما أقرته IESG وما لم ينشر بعد كـ RFC
صدر إعلان الموافقة عند الساعة 22:11 بالتوقيت العالمي في 8 مايو 2026. الوثيقة من إنتاج Mail Maintenance Working Group، ومسارها المقصود Standards Track بدرجة Proposed Standard. عند تثبيت أدلة هذا المقال، كانت المراجعة 06 في طابور RFC Editor وتنتظر أول محرر، وكانت حالة إجراء IANA هي RFC-Ed-Ack.
يسجل سجل Message Headers لدى IANA حقل Expires الخاص بالبريد بوصفه standard، ويحيل إلى المسودة الحالية. وهناك سجل مستقل للحقل في Netnews. تشابه الاسم لا ينقل قواعد نظام رسائل إلى نظام آخر.
للفكرة تاريخ في مواءمة X.400 وفي تسجيلات أقدم لرؤوس البريد. كما ظهرت سلوكيات مختلفة في البرمجيات. لا تمحو المواصفة الجديدة هذا التاريخ ولا تقدمه كأمر موحد. إنها تحدد أقل معنى مشترك وتضع قيوداً على أخطر تفسير افتراضي.
هذه طريقة منضبطة لبناء معيار. الطبقة المشتركة تحمل الإشارة اللازمة للتشغيل البيني. أما التطوير المستقبلي في العرض والبحث والتنظيف فيبقى محلياً، حيث توجد معرفة صاحب الصندوق والمسؤولية عن النتيجة.
فرق بين تقليل البروز وإتلاف الدليل
تستخدم معمارية البريد مصطلحي Message Creator وMessage Reader. قد يكون Reader وكيلاً للتخزين أو تطبيقاً للمستخدم. ويمكنه تقليل بروز الرسالة المنتهية، أو إخراجها من العرض المعتاد، أو تقديم قواعد تنظيف يضبطها المستخدم.
مع ذلك، تمنع المواصفة رفض الرسالة أو إسقاطها اعتماداً على الحقل وحده. كما توصي بألا تحذف الرسالة لمجرد أن تاريخها في الماضي، إلا إذا اختار مالك الصندوق هذا السلوك قصداً.
هناك سلسلة من الأفعال يجب ألا تختفي خلف كلمة واحدة. النظام يقرأ التاريخ، ثم يقرر طريقة العرض، وقد يضع علامة حذف، ثم قد يزيل البيانات بصورة دائمة. أول فعل يصف مدخلاً، والأفعال التالية تحتاج قواعد منفصلة وتزداد خطورتها كلما صعب الرجوع عنها.
يوضح IMAP4rev2 هذا الفصل. توضع العلامة \Deleted على الرسالة، ثم يزيل EXPUNGE الرسائل التي تحملها بشكل دائم، بينما يقيد UID EXPUNGE العملية بمعرفات UID محددة. ليست كل مخازن البريد مبنية على IMAP، لكنها تحتاج إلى أثر مماثل للقرار والنتيجة.
إذا اختصرت المنصة هذه المراحل كلها في «انتهاء تلقائي»، فلن يستطيع المشغل تحديد ما إذا كان ما حدث اختيار عرض، أم سياسة محلية، أم إزالة نهائية. عندها تصبح الراحة غطاءً لغياب المساءلة.
التوقيع يثبت المصدر ولا يمنح التفويض
يمكن لتوقيع DKIM أن يقدم دليلاً على أن نطاق التوقيع تحمل بعض المسؤولية عن أجزاء مختارة من الرسالة. وإذا شمل التوقيع Expires، فقد يكشف تعديلاً لاحقاً ضمن شروط DKIM.
لكنه لا يثبت أن التاريخ معقول أو صادق أو مناسب لمصلحة المستلم. ولا يمنح النطاق الموقع سلطة على مدة احتفاظ شخص آخر برسائله. إثبات هوية القائل لا يوسع صلاحيات قوله.
يتكرر هذا الخلط في البنية التحتية الرقمية. تبدو القيمة المعيارية أو الموقعة جاهزة لتشغيل الشيفرة، فتتحول في الواجهة إلى قرار. لكنها تظل دليلاً في نطاق محدد، ولا تصبح إذناً لنتيجة تقع خارجه.
يمكن للأتمتة أن تستخدم التاريخ مع سياق المصادقة وسجل المرسل ونوع الرسالة وتفضيلات المالك. الشرط هو أن يظهر أي حكم محلي حوّل هذه الأدلة إلى تغيير في العرض أو إلى إزالة.
للمهاجم حرية اختيار الساعة أيضاً
يفترض تحليل التهديد أن المنشئ قد يختار تاريخاً بعيداً في الماضي أو قريباً جداً أو بعيداً في المستقبل. لا يستطيع Reader، من دون معرفة إضافية، افتراض أن القيمة دقيقة أو حميدة.
قد يجعل التاريخ الماضي الرسالة المزعجة أقل ظهوراً قبل الإبلاغ عنها. وقد يجعل موعد قريب شكوى أو تعليمة أصعب في البحث بعد اتخاذ إجراء. أما التاريخ البعيد فقد يستخدم للمطالبة بحضور طويل في صندوق الوارد. لذلك لا يرجح أن يحدد الحقل وحده ما إذا كانت الرسالة مرغوبة أو احتيالية.
لا يلغي ذلك فائدته في العرض. يمكن القول إن «الموعد الذي أعلنته الرسالة قد مضى». هذه ملاحظة عن الدليل. أما عبارة «الحذف آمن» فهي قرار يحتاج إلى سياسة محلية وصاحب مسؤولية معروف.
الفصل في اللغة يحمي الفصل في السلطة. حين تخفي الواجهة الفرق، تخفي أيضاً الطرف الذي سيتحمل الخسارة.
المصادر
- IETF Datatracker — Updated Use of the Expires Message Header Field
- IETF Datatracker — تاريخ الوثيقة
- IETF Datatracker — تقرير المسؤول
- Lu Heng — Minimum Initial Specification
- Lu Heng — Running-Code Primacy
- أرشيف بريد IETF — إجراء IESG
- IANA — سجل Message Headers
- Internet-Draft، المراجعة 06
- RFC 2156 — مواءمة MIXER
- RFC 4021 — تسجيل رؤوس البريد وMIME
- RFC 5322 — صيغة رسائل الإنترنت
- RFC 5536 — صيغة مقالات Netnews
- RFC 5598 — معمارية بريد الإنترنت
- RFC 6376 — توقيعات DKIM
- RFC 9051 — IMAP4rev2
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
