الخلاصة

  • تشير قيمة id في سجل TXT الخاص بـ MTA-STS إلى ضرورة إعادة جلب السياسة. وهي لا تحتوي السياسة ولا توقّعها، ولا تثبت أن جميع المرسِلين جلبوها، ولا تلغي كل النسخ الأقدم دفعة واحدة. ما يملكه كل مرسِل داعم هو جسم محدد جُلب عبر HTTPS موثق، مع وقت جلب معلوم ومدة max_age لم تنقضِ.
  • يربط القرار القابل لإعادة البناء بين نطاق السياسة، والتحقق من هوية مضيفها عبر PKIX، والبايتات الدقيقة، وسلسلة التخزين المؤقت، وترتيب MX، وSTARTTLS، والشهادة، وحالة قائمة الانتظار، وإعادات المحاولة، والنتيجة النهائية. وضع enforce قاعدة نقل لدى MTA مرسِل، وليس إثباتاً للتسليم أو السرية بين الطرفين أو هوية صاحب الصندوق أو صلاحية إجراء تجاري.

قد يختلف مرسِلان ويكون كلاهما مصيباً

المشهد الافتتاحي اختبار توضيحي صُمم للتحقق من الحد الفاصل، وليس تقريراً عن حادثة. يرى المستقبِل أن السياسة الجديدة هي الحالية لأنه حدّث خادم الويب وسجل TXT. يلاحظ المرسِل A المعرّف الجديد، ويوثق mta-sts.<النطاق>، وينزّل الملف، ويبدأ مدة تخزين جديدة. وتشمل قائمته المطبقة خادم MX الاحتياطي.

أما تحديث المرسِل B فيفشل. لا تطلب RFC 8461 منه إسقاط سياسة سابقة ما دامت صالحة لمجرد تعذر الاستكشاف المباشر. عند وجود نسخة غير منتهية يجب تطبيقها. ولأن خادم MX الجديد غير مدرج فيها، يعدّه B مرشحاً غير صالح ويؤجل التسليم.

لا تكفي حالة DNS وصفحة الويب الحاليتان لدى المستقبِل لمراجعة القرارين. المطلوب هو حالة المرسِل لحظة اتخاذ القرار. السؤال الأول الأدق ليس «ما السياسة الآن؟»، بل «أي بايتات موثقة كان لهذا المرسِل حق تطبيقها في هذه المحاولة؟».

المعرّف إشارة تغيير وليس نص القاعدة

يحمل سجل TXT عند _mta-sts.<نطاق-السياسة> القيمة v=STSv1 ومعها id. يدفع تغيّر المعرّف إلى محاولة جلب جديدة، لكنه ليس تجزئة لملف HTTPS، ولا قائمة MX، ولا آلية إلغاء عالمية. يلاحظ كل مرسِل DNS ويتم جلب السياسة بنجاح في توقيت مختلف.

إذا لم توجد نسخة صالحة ثم نجح TXT وفشل جلب HTTPS، يتصرف المرسِل كما لو أن النطاق لم يطبق MTA-STS. أما إذا كانت هناك نسخة صالحة، فيبقي الفشل نفسه القاعدة الأقدم نافذة. لهذا فحدث «رؤية المعرّف الجديد» منفصل عن حدث «تطبيق السياسة الجديدة»، ويجب ألا يندمجا في خانة رصد واحدة.

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

يوثق HTTPS جسماً محدداً للسياسة

يوجد الملف على مضيف السياسة mta-sts.<نطاق-السياسة>، في المسار الثابت /.well-known/mta-sts.txt. يجب أن تكون شهادة المضيف صالحة زمنياً، مطابقة لاسمه، وقابلة للبناء حتى جذر يثق به المرسِل. ويحتوي الجسم version وmode ومدخلات mx وmax_age؛ ويمكن أن تغيب قائمة MX في وضع none.

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

تنشئ max_age أكثر من حاضر صحيح

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

الإزالة السليمة تحترم هذا التداخل أيضاً. ينشر المشغّل سياسة موثقة في وضع none ومدة قصيرة، ويغير المعرّف، وينتظر انتهاء أطول مدة قديمة قبل حذف TXT ونقطة HTTPS. حذف مسارات الإصلاح أولاً قد يترك مرسِلين عالقين في enforce قديم من دون وسيلة لاستبداله.

موضوع التحقق هو MX داخل اتصال بعينه

في enforce يجب أن يطابق المضيف المرشح نمطاً من أنماط mx. لا يطابق حرف البدل إلا الوسم الكامل الواقع أقصى اليسار، ولا يشمل أصل النطاق أو مستويات متعددة. يستمر المرسِل في ترتيب أولوية MX المعتاد، ويعامل المرشح غير الصالح كما لو كان غير متاح مؤقتاً. وقد يظل غياب خادم احتياطي عن السياسة مخفياً حتى يفشل الخادم الأساسي.

يجب أن يعلن الخادم المختار STARTTLS ويقدم شهادة PKIX غير منتهية، مطابقة لاسم MX، ومتسلسلة إلى جذر موثوق. يحمل SNI أثناء جلب HTTPS اسم مضيف السياسة، بينما يحمل في اتصال SMTP اسم MX المختار. الخلط بين الاسمين يربط دليلاً بخطوة تحقق لا تخصه.

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

تمنح قائمة الانتظار القاعدة أثرها

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

ينبغي لعمليات الفحص الاصطناعية أن تختبر: معرّفاً جديداً وجلباً ناجحاً؛ ونسخة قديمة صالحة عند فشل التحديث؛ ونسخة منتهية بلا بديل؛ والانتقال إلى MX احتياطي؛ والإزالة بوضع none. المقارنة الصحيحة تكون مع تجزئة السياسة التي طُبقت فعلاً، لا مع إعداد المستقبِل الحالي وحده.

TLSRPT شهادة مجمّعة

تطلب سياسة _smtp._tls في RFC 8460 تقارير قد تسجل السياسات المكتشفة والأعداد الإجمالية وعينات الفشل. تساعد هذه البيانات المستقبِل على التمييز بين خطأ عادي وتدخل، وعلى مقارنة المناطق أو تطبيقات المرسِلين. توثق Microsoft وGoogle أسطحاً حالية لـ MTA-STS والتقارير في منتجاتهما؛ وهذا دليل على الواجهات المعلنة لتلك المنتجات، لا على سلوك كل MTA.

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

يرسم DANE وREQUIRETLS حدود سلطات مجاورة

يوثق MTA-STS السياسة بواسطة HTTPS وPKIX ولا يشترط DNSSEC، ومن ثم يمكن حجب استكشافه الأولي. أما DANE فيثبت حد تخفيض مختلفاً داخل DNSSEC. ولا يجوز لنتيجة MTA-STS مريحة أن تتجاوز فشلاً في تحقق DANE.

تعبّر REQUIRETLS في RFC 8689 عن قصد منشئ رسالة بعينها عبر المرحلات الداعمة. أما MTA-STS فيعبّر عن سياسة نطاق المستقبِل لدى المرسِلين الداعمين. سياسة النطاق، وقصد الرسالة، ودليل الاتصال أشياء مستقلة للسلطة، ولا يرث أحدها ادعاءات الآخر.

قرار يمكن إعادة بنائه

يربط السجل الأدنى نطاق السياسة؛ والمحلل والزمن وبايتات TXT وTTL وحالة DNSSEC والمعرّف؛ وعنوان HTTPS ووقت الجلب وبايتاته وشهادته؛ والنسخة والنمط وMX وmax_age والتجزئة والانتهاء؛ وتجزئة النسخة السابقة وصلاحيتها؛ ومجموعة MX وترتيبها؛ والمضيف والعنوان وSNI وSTARTTLS ونتيجة PKIX؛ وقائمة الانتظار والمحاولات والمصير؛ ونتيجة DANE المنطبقة؛ وشهادة TLSRPT.

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

المصادر