الخلاصة

  • حددت IETF الساعة 22:00 بالتوقيت العالمي في 11 سبتمبر 2026 لانتقال بنية البريد التي تخدم ietf.org وiab.org وirtf.org وrfc-editor.org. قد تتأخر الرسائل حتى 60 دقيقة، وستتعطل واجهة Mailman3 على الويب، فيما يُفترض أن يظل Mailarchive والوصول عبر IMAP متاحين.
  • بعد انتقال مختلف في فبراير 2025، قالت IETF إنها تعتقد أن كل البريد المرسل خلال فترة التوقف سُلّم بعد انتهائها بقليل. لا تثبت هذه العبارة ضياع رسالة أو سوء تشغيل. لكنها تكشف الفرق بين تقدير حذر يصدر عن المشغّل وبين إقفال يمكن لطرف آخر إعادة فحصه.
  • البريد ليس خدمة مكتبية هامشية لدى IETF. فالمنظمة تقول إنها تدير أكثر من 500 قائمة وإن معظم عملها يجري عليها، كما يلزم BCP 25 فرق العمل بقائمة عامة وأرشيف علني. بقاء الأرشيف القديم قابلاً للقراءة لا يثبت أن رسالة جديدة وصلت إليه.
  • يجب أن يميز إثبات حفظ الرسائل بين الرفض على مستوى SMTP، والإسقاط المقرر بسياسة، وانتظار تأكيد المرسل، والإشراف، وقبول القائمة، والتسليم إلى مرحّل الخروج، والارتداد، والإدخال إلى الأرشيف. ويمكن نشر المجاميع والاستثناءات من دون كشف المتون أو العناوين أو القوائم الخاصة أو ضوابط الحماية.

فعل واحد حدّد درجة اليقين في 2025

في 24 فبراير 2025، أوقفت IETF مؤقتاً تسليم البريد إلى عدة نطاقات مرتبطة بها وإلى قوائمها، بينما كان المعالج ينتقل إلى بنية جديدة. امتدت النافذة، التي خُطط لها ساعتان، أربع ساعات من 09:00 إلى 13:00 بالتوقيت العالمي. وعندما عاد العمل، صاغ إعلان الإقفال نتيجته بحذر: قالت المنظمة إنها تعتقد أن كل البريد المرسل إلى عناوينها أثناء الانتقال سُلّم بعد اكتماله بقليل. وأضافت أنها ستواصل مراقبة النظام ودعت المشاركين إلى الإبلاغ عن أي سلوك غير متوقع.

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

مع ذلك، تظل كلمة نعتقد مهمة لأنها تعرّف مستوى المعرفة المنشور. فلا تخبر القارئ ما الذي عُدّ بريداً «مرسلاً»، وأين انتهت «عملية التسليم»، وكيف طوبقت طوابير النظام القديم بالجديد، وهل شملت النتيجة الرسائل المخزنة بانتظار تأكيد مرسل جديد، أو ما إذا تلقى الأرشيف نسخة من كل رسالة قبلتها القوائم.

انتقال سبتمبر 2026 أعمق. تصف IETF تصميماً حديثاً مقسماً إلى وحدات وحاويات، تعمل وظائفه المنفصلة في عنقود Kubernetes مخصص. ويخرج البريد، استثناءً، عبر عدة آلات افتراضية في شبكات ذات سمعة جيدة. أُعيدت كتابة postconfirm بالكامل، وهي الأداة التي تطلب التأكيد من المرسلين الجدد. سيحل Rspamd محل SpamAssassin، كما تتغير برمجيات إعادة كتابة العناوين، ومعالجة الرسائل المرتدة، وتوقيع DKIM، وإدارة الشهادات المستخدمة مع DANE.

الإعلان واضح في شأن التوافر: يبدأ العمل في 11 سبتمبر عند 22:00 بالتوقيت العالمي؛ قد يتأخر التسليم حتى ساعة؛ لن تتاح واجهة Mailman3 على الويب؛ ولن يتأثر الوصول إلى Mailarchive وIMAP. ووعدت المنظمة بتحديثات إضافية مع اقتراب الموعد.

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

قد يبقى الأرشيف مفتوحاً من دون أن تصله الرسالة الجديدة

لتوافر الأرشيف معنيان مختلفان. الأول أن يستطيع المستخدم البحث في نقاش قديم أو تنزيل رسالة أو فتح صندوق IMAP. والثاني أن تكون رسالة أرسلت في 22:03 قد اجتازت التأكيد والإشراف وتوسيع قائمة المستلمين ومرحّل الخروج ثم أُدخلت إلى الأرشيف.

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

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

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

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

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

بريد IETF جزء من الدليل الإجرائي

قد تكون هذه المطابقة مبالغة لقائمة تسويق عادية. لكنها تتناسب مع المكانة التي منحتها IETF نفسها للبريد.

تقول الصفحة الرسمية إن المنظمة تشغّل أكثر من 500 قائمة وإن معظم عملها يجري عليها. وتسمح غالبية قوائم فرق العمل وفعاليات BoF بالاشتراك والنشر العامين، مع استثناءات معلنة، وتعرض أرشيفاً عاماً. ويمكن اليوم الوصول إلى ذلك السجل عبر موقع Mailarchive أو تنزيله بواسطة rsync أو قراءته عبر IMAP.

ويذهب BCP 25 إلى أبعد من وصف الممارسة. تلزم RFC 2418 كل فريق عمل بقائمة بريد عامة على الإنترنت، وتقول إن معظم العمل سيجري عليها، وتوجب حفظ أرشيف علني. كما أوصت بنسخة أرشيفية منفصلة لتعزيز المتانة. بعض تفاصيل التنفيذ في وثيقة تعود إلى 1998 تاريخية، لكن الوظيفة المؤسسية ما زالت واضحة: القائمة مكان العمل، والأرشيف وسيلة مراجعته.

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

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

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

يمكن تطبيق تمييز Heng Lu بين العملية وطبقة الواقع هنا على نحو محدود. القائمة البريدية ليست سلطة تشريعية، والمشاركة فيها لا تولد سيادة. لكن حين تستخدم مؤسسة سجلاً لتبيين ما طُرح وما عورض وكيف جاء الرد، يجب أن يصوّر السجل الحدث التشغيلي بأمانة. حفظه لا يرفع المشغّل فوق المجتمع؛ بل يحصر سلطته في الوصاية على الدليل.

إثبات الحفظ جدول مطابقة، لا عبارة احتفالية

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

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

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

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

للأرشيف نفسه ثلاث واجهات عامة. ينبغي أن تعرض Mailarchive ونسخة rsync وIMAP المجموعة ذاتها بعد انقضاء المدة المعلنة، حيثما ينطبق ذلك. وإذا تأخرت واجهة، تسجل الفجوة بعددها وعمرها والمسؤول عنها وموعد المراجعة، بدلاً من إذابتها في إعلان نجاح عام.

إعادة كتابة العناوين تعقّد المطابقة. فقد يتغير ظرف الرسالة أو حقل المرسل الظاهر للتوافق مع SPF وDMARC قبل إضافة توقيع DKIM جديد. الاعتماد على From الظاهر وحده لا يكفي. يمكن اشتقاق ملخص مشفّر ومملّح من هوية داخلية تسبق التعديل واستخدامه للربط بين المراحل. لكن نشر أي طريقة من هذا النوع يجب أن يسبقه اختبار لاحتمال ربطها بشخص أو تخمين نشاطه.

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

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

كلما كان الإثبات علنياً، وجب أن يكون أضيق

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

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

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

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

الاعتراضات ترسم حدوداً واقعية للإثبات

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

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

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

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

والاعتراض الخامس أن الاستناد إلى كلمة «نعتقد» يظلم فريق 2025. العكس هو الأصح: كان إعلان عدم اليقين أفضل من يقين مصطنع. تستطيع IETF هذه المرة أن تدعم الحذر نفسه بأدلة قابلة لإعادة الفحص.

حدود الأدلة

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

يصف README العلني لـpostconfirm حالات البرنامج وقيمه الافتراضية. مهلة اليوم الواحد الافتراضية لبعض الرسائل المخزنة ليست دليلاً على قيمة الإنتاج. وتدل مستودعات الشهادات وإعادة الكتابة على عمل برمجي، لا على الحالة المنشورة يوم التنفيذ. كما أن بقاء Mailarchive وIMAP متاحين يصف الوصول، ولا يحدد هل سيستمر إدخال الرسائل الجديدة أم يتأخر أم يخضع لمطابقة منفصلة.

ولا تثبت عبارة 2025 ضياع البريد. إنها تحدد فقط مستوى الإقفال الذي نُشر آنذاك.

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

المصادر

  1. إعلان IETF في 28 أغسطس 2026 عن انتقال بنية البريد
  2. المدونة التقنية لـIETF عن الانتقال المقرر في 11 سبتمبر
  3. تدوينة IETF عن اكتمال انتقال 24 فبراير 2025
  4. صفحة القوائم البريدية لدى IETF
  5. RFC 2418 / BCP 25
  6. بيان الخصوصية لـIETF وIRTF وIAB
  7. IETF Note Well
  8. مستودع postconfirm لدى IETF Tools
  9. تحديث مشروع انتقال بنية تقنية المعلومات