الخلاصة

  • يسرد تحديث IETF في 25 سبتمبر ثمانية أعطال بعد الانتقال قالت المنظمة إنها أصلحتها، من إرسال المرسلين المؤكدين إلى المراجعة إلى إسقاط البريد الجماعي وفشل التسليم المرتبط بـDMARC.
  • كشفت مشكلة الارتدادات عن تراكم قديم. وعندما بدأت المعالجة الجديدة تعطيل المشتركين استناداً إلى ارتدادات ربما كانت خاطئة، أوقفت IETF المعالجة وأعادت تفعيل العناوين المتأثرة إلى حين إصلاحها.

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

ذلك سجلٌّ لعملية الانتقال، لا تقريرٌ عن التشغيل.

وصل تقرير التشغيل في 25 سبتمبر. قال Jay Daley، المدير التنفيذي لـIETF، إن معظم المشكلات حُلّت، ثم حدد ثمانية أعطال أصلحتها المنظمة واثنين ما زالا قيد المعالجة. وكشف أيضاً أن مشروع تصميم البنية وتنفيذها كُلّف به فريق قبل ثلاث سنوات، ثم أُسند إتمامه إلى متعاقد جديد بعد مشكلات متكررة. بقي مكوّن محوري من العمل السابق من دون إعادة كتابة، ولم تُكتشف مشكلاته قبل الإطلاق. وكتب Daley: «كان ذلك خطأنا».

لم تكن هناك واقعة انقطاع واحدة مدوية. بل تعطلت قواعد صغيرة عند الحدود بين القوائم والمرسلين الفعليين. عنوان مؤكد يرسل إلى قائمة من دون أن يشترك فيها لم يظهر في قائمة السماح العامة، فأُحيلت الرسالة إلى المراجعة. أُسقط بريد Precedence: Bulk من دون إخطار، وكان ذلك يؤثر أساساً في رسائل IANA. وساء التعامل مع عناوين BATV. وطُلب من العناوين المؤكدة التي تتضمن أحرفاً كبيرة أن تؤكد هويتها مجدداً. وتعذر الوصول إلى مجموعة قواعد للمرسلين غير المعتادين. وقُسّمت بعض أسماء From في Outlook إلى جزأين، وأُلحق نطاق IETF خطأً بالجزء الأول. كما صدرت إشعارات Postorius من عنوان مؤقت لأن خانة مالك الموقع كانت فارغة. وفشلت إعادة كتابة DMARC في بعض حالات التسليم بحسب عدد المستلمين.

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

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

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

وسجل التحديث نفسه مفاجأة أداء أخرى: أدى وضع VERP الافتراضي في Mailman إلى إطالة أوقات معالجة البريد أربعة إلى خمسة مراتب أسية، وفقاً للتقرير. لذلك عُطّل VERP أثناء التحقيق. ولا يذكر الإعلان زمناً مرجعياً أو حملاً للاختبار أو تأخيراً مطلقاً. وظل مرشح Rspamd الجديد قيد الضبط لأن كمية زائدة من الرسائل المزعجة كانت تمر.

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

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

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

المصادر