الخلاصة

  • تذكر RFC 5383 أن فنادق وجهات وصول عامة كانت أحياناً تعترض اتصالات المنفذ 25 بصرف النظر عن المضيف المقصود، فتجعل مراسلات حساسة تصل إلى خادم طرف ثالث مجهول من دون علم المستخدم.
  • يخصص المنفذ 587 سطحاً لخدمة إرسال الرسائل من العميل، لكنه ليس وثيقة هوية. اختيار الوجهة، وهوية TLS، وصلاحية الحساب، وقبول الطابور، والترحيل، ووصول الرسالة أدلة مستقلة.

الدليل الذي بدأ بنجاح زائف

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

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

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

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

فصل الإيداع عن الترحيل

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

أنشأت RFC 2476 خدمة Message Submission مستقلة، وراجعتها RFC 4409، وخلفتها RFC 6409. أصبح المنفذ 587 علامة على باب الإيداع من العميل، بينما بقي المنفذ 25 مرتبطاً أساساً بنقل البريد. لذلك شددت RFC 5383 على تمكين العميل المتنقل من الوصول إلى 587 واستخدامه افتراضياً.

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

لا تختصر سبع حقائق في كلمة «متصل»

يختار التطبيق اسماً. يعيد DNS عنواناً. يصل TCP إلى نظير مرصود. قد تنشئ TLS قناة محمية وتتحقق من هوية مرجعية. قد تثبت SMTP AUTH حساباً وفق سياسة الخادم. يقبل الخادم المعاملة. ثم تبدأ رحلة الترحيل والتسليم.

أوصت RFC 8314 لاحقاً باستخدام TLS للوصول والإرسال، وسجلت خدمة submissions على المنفذ 465 مع الاعتراف بمسار STARTTLS القائم على 587. هذا التطور يمنع اعتبار 587 ضماناً أمنياً بذاته. لا تصبح الهوية دليلاً إلا إذا تفاوض العميل على الحماية، وطابق الشهادة مع الاسم الصحيح، ورفض الخطأ أو خفض الحماية.

لهذا ينبغي للسجل أن يحتفظ بالاسم المقصود، ونتيجة DNS، والنظير الفعلي، والمنفذ، ونمط TLS، وسلسلة الشهادة، ونتيجة التحقق، ولافتة SMTP وقدراتها، وآلية المصادقة، والهوية الحسابية، وأكواد الرد، ومعرف الطابور، والزمن. خانة واحدة باسم «نجح» تمحو أهم نقطة في الحادثة.

الرفض الصريح أفضل من نجاح لا يعلن صاحبه

قد تحظر الشبكة المنفذ 25 لمكافحة الرسائل المزعجة أو الأجهزة المصابة. لا تنكر RFC 5383 حق المشغل في سياسة أمنية. الفرق بين أن يرفض الاتصال بوضوح وأن يستبدل الخدمة سراً.

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

لا تعيد هذه المقالة أطروحة RFC 2979 العامة عن شفافية الجدران النارية ولا أطروحة الأنفاق عبر HTTP. سؤالها أضيق: ما الدليل على أن من أجاب هو خدمة الإيداع المقصودة؟

قبول الطابور لا يثبت وصول القارئ

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

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

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

المصادر