الخلاصة

  • أمّن STARTTLS اتصال SMTP واحداً، لكن الرسالة بقيت بعده في الطوابير وانتقلت عبر اتصالات جديدة. منح RFC 8689 الرسالة نفسها شرطاً محفوظاً: توثيق كل قفزة تالية، وإعادة تمرير REQUIRETLS، ومنع الرجوع إلى النص المكشوف.
  • إذا لم يحقق أي خادم MX الشروط، وجب على المرحّل الامتناع عن الإرسال وإنتاج إخطار محمي بعدم التسليم. لا يوفر ذلك تشفيراً من طرف إلى طرف؛ فخوادم MTA المشاركة ما زالت ترى المحتوى.

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

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

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

وضع STARTTLS حدوداً حول جلسة واحدة

أدخل RFC 2487 عام 1999 أمر STARTTLS إلى SMTP. واجه البريد العام تفاوتاً كبيراً في قدرات خوادم MX. لو أصبح TLS شرطاً فورياً لكل تبادل، لانقطعت مسارات كثيرة؛ لذلك بقيت قابلية التسليم أولوية، وظل التشفير في حالات كثيرة فرصة لا التزاماً.

حل RFC 3207 محل المواصفة الأولى عام 2002. يعلن الخادم STARTTLS في EHLO، ويطلبه العميل، ثم تبدأ المصافحة بعد جواب 220. عند اكتمالها ينسى الطرفان كل معرفة اكتسباها قبل TLS، ويرسل العميل EHLO جديداً داخل القناة المحمية.

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

ظهرت لاحقاً سلطات ينشرها نطاق المستلم. يربط RFC 7672 ‏SMTP DANE بسجلات TLSA المثبتة عبر DNSSEC. ويعرّف RFC 8461 ‏MTA-STS، وهي سياسة يجلبها المرسل عبر HTTPS ويخزنها مؤقتاً لتحديد أسماء MX المقبولة وشروط الشهادة. تعبّر الآليتان عن طلب النطاق المستلم، ولا تمنحان المرسل تلقائياً تمييز رسالة حساسة عن سائر البريد.

دخل الشرط من بوابة الغلاف

نشر RFC 8689 عام 2019 امتداد REQUIRETLS. لم يضف فعلاً جديداً إلى SMTP؛ بل أضاف قدرة في EHLO ومعاملاً بلا قيمة إلى أمر الغلاف القائم:

MAIL FROM:<sender@example> REQUIRETLS

لا يجوز للعميل وضع المعامل لمجرد أنه شاهده في تحية مكشوفة. يجب أن تكون الجلسة نفسها محمية بـTLS، وأن تُثبت هوية MX عبر DNSSEC أو MTA-STS، وأن تنجح الشهادة عبر سلسلة ثقة مقبولة أو DANE، وأن يعيد الخادم إعلان REQUIRETLS في EHLO التالي للمصافحة.

الإعلان الثاني دليل على أن الطرف الذي أنهى TLS هو نفسه الذي يقبل واجب حفظ الشرط. أما إعلان ما قبل التشفير فيمكن حذفه أو تبديله ولا يكفي لبناء الالتزام.

عند قبول الرسالة يجب أن يضع الخادم عليها علامة داخلية. لا يحدد RFC اسم عمود أو صيغة ملف طابور؛ فالتمثيل شأن تنفيذي. المطلوب هو النتيجة: حين يرسل الخادم الرسالة لاحقاً، يعيد التحقق ويضيف REQUIRETLS إلى MAIL FROM الجديد.

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

لم يكن القفل الأخضر دليلاً واحداً كافياً

يختار المرحّل وجهته وفق قواعد RFC 5321. إذا لم تكن إجابة MX موثقة بـDNSSEC، استخدم MTA-STS ليتأكد أن الاسم مسموح. بعد ذلك ينشئ TLS، ويفحص شهادة الخادم، ثم يبحث عن REQUIRETLS في EHLO المحمي.

تجيب كل خطوة عن سؤال مختلف. يحجب التشفير البايتات عن المراقب. تربط الشهادة أو DANE المفتاح بهوية. يحدد DNSSEC أو MTA-STS أي اسم يحق له تمثيل نطاق المستلم. ويثبت الإعلان الأخير أن الحارس التالي يعرف كيف يحتفظ بالعلامة وينقلها.

قد يكون الاتصال مشفراً لكنه متجه إلى MX مزيف. وقد تكون الشهادة صحيحة لكن الخادم لا يدعم استمرار الشرط. لذلك يخفي حقل واحد اسمه «استُخدم TLS» مسار السلطة الحقيقي.

ينتهي البحث في قائمة MX قبل أن يبدأ النص المكشوف

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

إذا انتهت القائمة من دون خادم مؤهل، حُظر إرسال الرسالة إلى النطاق. يوصي RFC 8689 بالحالة 5.7.30 عندما لا يدعم الخادم REQUIRETLS، وبالحالة 5.7.10 عندما يتعذر إنشاء جلسة TLS المطلوبة. ثم ينشئ المرحّل إخطاراً بعدم التسليم إلى مسار الرجوع الأصلي.

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

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

احتاج خبر الفشل إلى حماية أيضاً

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

لذلك يجب أن تحمل كل رسالة ارتداد ناتجة من رسالة REQUIRETLS الشرط نفسه، حتى لو كان سبب الفشل بعيداً عن TLS. ويُعامل الارتداد كما لو أن خيار DSN المسمى RET=HDRS موجود؛ وإذا طُلب RET=FULL يُتجاهل حتى لا يعود المتن كله عبر مسار غير مضمون.

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

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

قال الحقل السلبي No من دون أن يطلب النص المكشوف

عرّف RFC 8689 أيضاً الحقل TLS-Required: No. يطلب من المرحّل ألا يجعل سياسة DANE أو MTA-STS التي نشرها المستلم سبباً لفشل التسليم. من أمثلته إرسال بلاغ إلى مسؤول بأن شهادة خادمه معطلة؛ فلا يحجب العطل نفسه الرسالة التي تصفه.

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

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

الوسيط قد يتحول من ناقل إلى منشئ جديد

يحفظ المرحّل العادي الرسالة نفسها. أما قائمة البريد أو قاعدة Sieve أو خدمة التحويل أو الرد التلقائي فقد تنشئ رسالة جديدة. تتغير العناوين والرؤوس والمسؤولية. يطلب RFC من هؤلاء الوسطاء تطبيق اختيار الرسالة الواردة على الناتج الجديد قدر الإمكان.

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

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

بقيت الخوادم الوسيطة قادرة على قراءة الرسالة

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

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

يثبت سجل SMTP لدى IANA تخصيص اسم REQUIRETLS وربطه بالمواصفة. لا يثبت نسبة الانتشار أو حجم الاستخدام أو التزام منتج بعينه.

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