الخلاصة

  • حددت IETF يوم 11 سبتمبر 2026 لانتقال خدمات البريد، مع توقع تأخير قد يبلغ ستين دقيقة وتوقف مؤقت لواجهة Mailman على الويب. لم يقع الانتقال بعد؛ هذه خطة وتوقع وليست نتيجة تشغيلية.
  • عندما يجيب مرسل جديد عن التحدي يستطيع postconfirm إعادة الرسالة المحفوظة إلى نظام البريد. يثبت ذلك تحقق شرط محلي، ولا يثبت قبول القائمة أو صحة إعادة العنوان أو التوقيع أو جلسة DANE أو وصول الرسالة إلى المشترك.

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

يقول إعلان IETF في 28 أغسطس إن النقل يبدأ في 11 سبتمبر الساعة 22:00 بالتوقيت العالمي لخدمات نطاقات IETF وIAB وIRTF وRFC Editor. ستتعطل واجهة Mailman3، بينما يفترض استمرار الأرشيف وIMAP. أما تحسين معالجة الارتداد وتقليل الرسائل المزعجة وإغلاق احتمال relay مفتوح فهي أهداف تحتاج إلى قياس بعد التنفيذ.

كل خدمة تملك جزءاً من العهدة

تعمل الوظائف في حاويات يديرها Kubernetes وتتصل عبر milter، فيما يخرج البريد من عدة آلات افتراضية. وبذلك تصبح حدود postconfirm وRspamd وإعادة العنوان وDKIM وDANE ومعالجة الارتداد قابلة للتسمية.

يشرح مستودع postconfirm أن الرسائل المجهولة تُخزن أثناء التحدي ثم يعاد حقنها بعد الإجابة. ويفرق بين reject وdiscard؛ فقد يتلقى عميل SMTP نجاحاً مع إسقاط الرسالة في الحالة الثانية. لذلك لا قيمة لإشارة «نجاح SMTP» من دون منتجها ونوع فعلها وبصمة الرسالة.

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

العنوان المعاد كتابته هو ادعاء جديد

قد توزع القائمة البريد من بنية لا تشملها سياسة SPF الأصلية. يفحص النظام SPF وDMARC، ويعيد كتابة المرسل عند الحاجة، ثم يوقع بـ DKIM.

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

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

الشهادة التالية الجاهزة ليست جلسة بعيدة ناجحة

يراد بمخطط current + next 3 1 1 إبقاء شهادة صالحة لـ DANE أثناء الدوران. يعرض danebot حالتين منفصلتين للحالي والتالي. هذا دليل استعداد داخلي.

أما DANE لبروتوكول SMTP فينشئ دليلاً عند تحقق MTA المرسل من MX وTLSA عبر DNSSEC ومصادقة قفزة TLS التالية. لا يدعي RFC حماية كل البريد، ويعتمد على DNSSEC ضد التخفيض. المادة المقصودة، وسجل TLSA المرئي، والشهادة المقدمة، والمصافحة المكتملة أربعة إيصالات مختلفة.

القبول يبدأ مسؤولية محدودة

يفرض SMTP على من يرسل 250 OK بعد DATA مسؤولية التسليم أو الترحيل. لكنه لا يثبت القراءة. ويقول RFC 3464 إن delivered قد يعني الوصول إلى موزع قائمة بريدية؛ أما relayed وexpanded فلهما حدود أخرى.

ينبغي أن يتكلم MTA الداخل وpostconfirm وMailman وخدمة إعادة الكتابة والموقّع وrelay الخارج وMTA المستقبل وصندوق الاختبار كل بصوته. غياب الارتداد ليس وصولاً، وصحة الحاوية ليست تصريفاً للطابور التالي.

يفصل منهج Heng Lu في طبقات الواقع بين الإعداد والحالة والقبول والنتيجة. وتطلب أولوية الشيفرة العاملة شاهداً عند الحد القادر على الفعل. أما السيطرة العملية على البيانات فلمن يستطيع قراءة الطوابير وتغيير الهوية وتدوير المفاتيح واستعادة الرسالة.

يُثبت نجاح الانتقال عندما تتطابق إيصالات الحدود كلها. اجتياز التحدي يفتح الباب الأول فقط.

المصادر