الخلاصة

  • سمح RFC 5335 التجريبي بإرفاق عنوان ASCII بديل بعنوان بريد غير ASCII. وعند غياب قدرة النقل اللازمة، أمكن لعملية الخفض أن تستخدم البديل، مع أن العنوانين قد يصلان إلى صندوقين أو شخصين مختلفين.
  • أثبتت التجربة أن الارتباط لا يساوي تطابق الهوية. يسجل RFC 6530 تعذر توثيق أزواج العناوين على نحو مرضٍ، ومشكلات التشغيل البيني وتعقيد الخفض أثناء النقل؛ لذلك أزال التصميم المعياري اللاحق ذلك الجسر.

نجاح جلسة SMTP لم يحفظ مقصد المرسل

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

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

لهذا كان تحذير RFC 5335 حاسماً: العنوان الدولي والبديل ASCII قد ينتهيان عند صندوقين مختلفين أو شخصين مختلفين. كما يمكن لقدرات وكلاء نقل البريد أن تحدد أيهما يُستخدم. أصبح شكل المسار عاملاً في تحديد من يتلقى الرسالة.

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

البديل ادعاء يحتاج إلى صاحب سلطة

وضعت بنية RFC 5335 العنوانين معاً. كان ذلك كافياً للتمثيل النحوي، لكنه لم يحمل هوية من أنشأ الرابط أو نطاق التفويض أو تاريخ انتهاء العلاقة.

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

ويمكن أن ينشأ البديل من نقل سجل قديم أو تحويل آلي للاسم أو قرار إداري غير موثق. تبدو النتيجة في الحقل مماثلة، لكن لا توجد حجة بأن الشخصين واحد.

ينطبق هنا فصل Lu Heng بين وجود السجل والسلطة التي تُنسب إليه. وظيفة الدليل أن ينسق معلومات يمكن الرجوع إليها. لا يمنح وجود صف فيه قيّمه حق التصرف في الشخص الذي تصفه البيانات. وبالمثل، يحمل ALT-ADDRESS علاقة مقترحة؛ ولا يصبح تفويضاً لمجرد أن بروتوكولاً يستطيع قراءته.

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

عجز المرحّل لا يعطيه حق اختيار شخص آخر

شرح RFC 5504 الأثر التنفيذي. إذا احتوى path غير ASCII على ALT-ADDRESS أمكن استبداله بالعنوان ASCII عند الخفض. وإذا اختلف النطاق، وجب التحقق من صلاحية الاتصال الحالي للوجهة الجديدة، أو حل النطاق وفتح طريق آخر.

قد تنقل العملية الرسالة إلى مزود مختلف، وسياسة حفظ مختلفة، وحدود إدارية وقانونية أخرى. ومع ذلك بدأ القرار من ملاحظة محدودة: الخادم التالي لا يعلن القدرة التجريبية المطلوبة.

يحق للخادم أن يرفض تنسيقاً لا يفهمه. لا يمنحه هذا الرفض وكالة لتغيير المستلم. المعرفة التقنية عن القناة لا تنتج سلطة على هوية الطرف الآخر.

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

سجل الخفض لا يوثق صحة الخفض

أنشأ RFC 5504 حقول Downgraded-* للاحتفاظ ببعض المعلومات الأصلية. تساعد هذه الحقول في رؤية أن تحويلاً حدث وفي مقارنة الشكلين.

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

ظهر تعارض آخر في الرسائل متعددة المستلمين. كتابة عنوان كل مستلم الأصلي في رأس مشترك قد تكشفه للآخرين. لذلك حظر الإجراء إضافة Downgraded-Rcpt-To في هذه الحالة. كانت حماية الخصوصية صحيحة، لكنها تعني أن النسخة النهائية قد لا تحمل السلسلة الكاملة للتحقيق.

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

الفشل المرئي قد يكون أكثر أماناً من نجاح صامت

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

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

ينبغي أن يعرض النظام العنوان الأصلي، والعقدة التي افتقدت القدرة، وصاحب قرار الاستبدال، ودليل الربط، والعنوان والنطاق الفعليين، ورد الخادم النهائي، وحالة الصندوق. عبارة واحدة مثل «تم» تخفي موضع الخطر.

أزال المعيار الجسر بدلاً من توسيع سلطته

نُشر RFC 5335 بوصفه Experimental عام 2008، ثم حل RFC 6532 محله في مسار المعايير عام 2012. يراجع RFC 6530 التجربة بوضوح: كان النموذج السابق يقرن العناوين غير ASCII بمكافئات ASCII للخفض أثناء النقل. لكن الربط لم يكن قابلاً للتوثيق بصورة كافية، وظهرت مشكلات تشغيل بين التطبيقات، وأصبحت المتطلبات والآثار طويلة الأجل أعقد من أن تكون مرضية.

أزال التصميم المعياري الخفض أثناء النقل. يعتمد RFC 6532 رؤوس UTF-8 أصلية من طرف إلى طرف في بيئة 8-bit-clean يضمنها النقل، ويحتاج إلى SMTPUTF8 عند استخدام SMTP. لا يعد عبور بنية سباعية البت باختيار هوية أخرى.

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

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

المصادر