الخلاصة

  • حدّد IETF يوم 11 سبتمبر 2026 عند الساعة 22:00 UTC للانتقال بخدمات البريد الخاصة بـ ietf.org وiab.org وirtf.org وrfc-editor.org. قد يتأخر التسليم حتى ستين دقيقة، وستتوقف واجهة Mailman3 على الويب، بينما يُفترض أن يبقى الأرشيف وIMAP متاحين.
  • الأهم ليس مدة الصيانة، بل سلسلة الحيازة: القبول والحفظ والتحدي والإطلاق وإعادة الكتابة وتوقيع DKIM والتحقق عبر DANE والطابور الخارجي والأرشفة قرارات منفصلة، ولا يثبت نجاح إحداها التسليم النهائي.

يصف إعلان IETF الصادر في 28 أغسطس وظائف موضوعة في حاويات منفصلة، يدير Kubernetes جدولتها داخل عنقود مخصص، وتتصل عبر milter. سيحل Rspamd محل SpamAssassin، وستوجد خدمة جديدة لإعادة كتابة العناوين ومعالجة أفضل للشهادات وDANE. أما البريد الصادر فيُرحَّل عبر عدة آلات افتراضية في شبكات ذات سمعة جيدة، لا عبر الحاويات نفسها.

هذه الهندسة تجعل عبارة «البريد يعمل» غير كافية. قد يظل الأرشيف قابلاً للقراءة بينما لا تدخل رسائل جديدة. قد تغيب واجهة Mailman3 ويبقى IMAP. وقد تكون كل الحاويات سليمة فيما يتراكم البريد في آلة خروج. يجب أن يذكر كل مؤشر السطح الذي يقيسه.

خبر 2026 ليس تكراراً لانقطاع 2024

يحتفظ BTW بمقال عام عن نافذة أغسطس 2024، وانتقال الإرسال الأساسي نحو Amazon SES، وتعديل SPF، واحتمال تعذر استرداد بعض الرسائل. يظل ذلك السجل صحيحاً ومستقلاً.

قال IETF في إعلان فبراير 2025 إن معالجة البريد الأساسية بقيت إلى حد بعيد كما كانت، وإن الاستفادة الأعمق من تقنيات السحابة ستأتي لاحقاً. إعلان 2026 يصف تلك المرحلة اللاحقة: إعادة بناء postconfirm، ومحرك مكافحة رسائل جديد، وخدمة تحويل عناوين، وأتمتة DANE، وفصل الوظائف عن مسار الخروج.

إذن ليست الأطروحة «انقطاع آخر». إنها انتقال حق الاحتفاظ بالنسخة التشغيلية وتغييرها من مكوّن إلى آخر.

القبول والحفظ والإطلاق ثلاثة ادعاءات

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

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

لذلك لا بد من ثلاث سجلات: ما قيل للمرسل عند الدخول، وما حُفظ فعلاً، وما أُطلق أو مُسح لاحقاً. استجابة 2xx ليست دليلاً على إدخال الأرشيف. تحديث صف القبول لا يثبت أن البايتات أُعيدت إلى النظام. وعدم ظهور الرسالة لا يحدد إن كانت انتهت أو حُذفت أو لم تصل إلى القائمة أصلاً.

القيم الافتراضية في المستودع ليست إعدادات الإنتاج. مدة الاحتفاظ الفعلية، وبنية PostgreSQL، ونسخة البرنامج وجدول التنظيف غير معلنة. يجب إثباتها من النظام بعد الانتقال.

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

إعادة كتابة العنوان تصلح المحاذاة ولا تنقل التأليف

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

يفحص milter الجديد SPF وDMARC. إذا لم يغط SPF عناوين الخروج، يمكنه تحويل envelope From إلى عنوان قابل للعكس تحت نطاق dmarc.* يديره IETF. وإذا كانت سياسة DMARC quarantine أو reject يمكنه أيضاً تغيير header From الذي يراه القارئ. ثم تُوقَّع الرسالة بـ DKIM تحت نطاق IETF المناسب.

يعترف RFC 9989 بأن مثل هذه الحلول أصبحت واقعاً مستقراً للقوائم البريدية. إنها تنشئ هوية تقنية متوافقة للمُعيد، ولا تجعل القائمة مؤلفاً. ووفق RFC 6376، يحمل النطاق الموقّع مسؤولية الأجزاء الموقعة، من دون إثبات الشخص أو التحدي أو التسليم.

يجب أن يحتفظ السجل بعنوان الكاتب الأصلي، وenvelope/header بعد التحويل، والسياسة التي سببت التغيير، ونسخة الربط وراهنيتها، ونطاق DKIM وselector. بقاء From الجديد وحده يجعل الأرشيف يخلط بين من كتب ومن أعاد الإرسال.

في DANE يصبح الزمن جزءاً من الثقة

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

نجاح روبوت تجديد الشهادة لا يكفي. يجب وصل الشهادة بسجل TLSA، وDNSSEC، وTTL، وما يقدمه كل endpoint، ونتيجة handshake، وعمر الطابور. لم يحدث انتقال سبتمبر بعد، ولا يثبت الإعلان أن كل مرسل خارجي يفرض DANE.

الحاويات تقلل نطاق العملية وتزيد حدود الإثبات

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

آلات الخروج تضيف مجالاً مستقلاً للطابور والسمعة. قد ينهي العنقود كل المرشحات ولا يقبل النطاق البعيد البريد. يعرّف RFC 5321 SMTP كتخزين وتمرير بين قفزات، لا كمعاملة ذرية من الكاتب إلى القارئ.

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

الأرشيف وIMAP شاهدان مهمان، لا إيصالاً عاماً. الرسالة المحفوظة للتحدي لم تُنشر بعد؛ والمنشور المؤرشف قد يفشل عند بعض المشتركين. ينبغي وصل رد الدخول، وبصمة النسخة، والتحدي، والإطلاق أو purge، والتحويل، والتوقيع، وتوسيع القائمة، والأرشيف، وطابور الخروج، ورد SMTP البعيد وbounce. ولأن البايتات تتغير، يجب أن يذكر كل hash مرحلته.

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

تنجح الوحدات حين تقسم السلطة إلى مسؤوليات قابلة للقياس، لا حين تقسم القصة إلى لوحات لا تتصالح.