الخلاصة

  • وضع SMTP AUTH تبادل SASL قبل معاملة البريد، فأصبح خادم الإرسال قادراً على منح الترحيل لهوية جرى التحقق منها وتفويضها، بدلاً من مساواة عنوان الشبكة بالإذن.
  • ظل النجاح حقيقة تخص حدود الجلسة: هوية المصادقة، وهوية التفويض، ومرسل الظرف، والمؤلف الظاهر، والمحتوى، والطريق اللاحق بقيت ادعاءات منفصلة.

الاتصال بالخادم لم يكن دليلاً على صاحب الرسالة

صُمم SMTP في بيئة تنقل فيها آلات متعاونة البريد فيما بينها. يستقبل الخادم الرسائل الموجهة إلى نطاقاته، وقد يرحّل غيرها وفق سياسته. لكن حين أصبحت القدرة على الوصول إلى خادم عام كافية للترحيل إلى أي وجهة، تحول الخادم إلى مرحّل مفتوح قابل للاستغلال.

لم يكن تقييد الترحيل بعناوين IP حلاً مناسباً للمستخدم المتنقل. يفقد المشترك المشروع إذنه عندما يسافر، بينما لا تثبت الآلة الموجودة داخل نطاق مسموح أن مستخدمها مخوّل بانتحال عنوان مرسل بعينه. أما POP-before-SMTP فربط تسجيل دخول حديثاً في بروتوكول آخر بعنوان ومهلة زمنية؛ لم يربط التفويض بعملية إرسال الرسالة نفسها.

نقلت إضافة المصادقة المنشورة عام 1999، والتي استبدلتها RFC 4954 لاحقاً، السؤال إلى جلسة SMTP. يعلن الخادم AUTH وقائمة آليات SASL في رد EHLO، ويختار العميل آلية وينجز التبادل قبل MAIL FROM. لا تنتج عن النجاح شهادة شاملة، بل حقيقة محدودة: قبل الخادم عملية مصادقة واشتق هوية تفويض وفق سياسته المحلية.

تكفي هذه الحقيقة لفتح الترحيل. ولا تكفي لمعرفة من كتب النص.

فصلت SASL بين هويتين

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

قد تدخل قائمة انتظار إلى الخادم بحساب خدمة وهي تحمل رسائل مستخدمين كثيرين. وقد يُسمح لمساعد بالإرسال عن صندوق واحد دون صندوق آخر. ويمكن لبيانات اعتماد مسروقة أن تكون صحيحة تقنياً بينما تطلب نطاقاً لم يُمنح لها. لذلك لا يصبح اسم الدخول تلقائياً هو MAIL FROM أو ترويسة From أو المؤلف البشري.

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

أصبح للإرسال حد مستقل عن النقل

عرّفت RFC 6409 خدمة الإرسال من عميل المستخدم إلى وكيل إرسال الرسائل MSA بوصفها علاقة تختلف عن النقل بين وكلاء MTA. يستقبل MSA على المنفذ 587 رسالة جديدة، ويرفض أو يصحح بعض الأخطاء المحلية، ثم يدخلها في شبكة النقل.

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

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

تتغير الآليات المقبولة بعد حماية القناة

لا تحمي آلية المصادقة السر تلقائياً. تمنع RFC 4954 إعلان الآليات التي تكشف كلمة المرور من دون حماية كافية، وتسمح لقائمة الآليات أن تتغير في EHLO جديد بعد STARTTLS. لذلك لا يُختصر دعم AUTH في قيمة واحدة؛ فحالة TLS والشهادة والآلية وقبول العميل للتخفيض تحدد ما يمكن استخدامه بأمان.

اعتبرت RFC 8314 لاحقاً النص الصريح متقادماً في إرسال البريد والوصول إليه، ونظمت STARTTLS على المنفذ 587 وTLS الضمني على 465. يحمي التشفير تبادل بيانات الاعتماد ومحتوى تلك القفزة. لكنه لا يحولها إلى توقيع مؤلف من طرف إلى طرف.

يحفظ AUTH=<> معنى «غير معروف»

أتاحت RFC 4954 في MAIL FROM المعامل AUTH= لنقل هوية المُرسل الأصلي المزعومة. إذا لم يستطع الخادم تحديدها على نحو موثوق، فعليه استخدام AUTH=<>. لا يملأ الفراغ باسمه ويحول غياب الدليل إلى يقين.

ينبغي تمرير الادعاء فقط بين خوادم تربطها ثقة مناسبة. كما أن النوعين ESMTPA وESMTPSA المسجلين في RFC 3848 يقولان إن قفزة الاستقبال استعملت المصادقة، أو المصادقة مع TLS. لا يثبتان الطريق كله ولا المؤلف.

نجح التصميم لأن تسجيل الدخول بقي أصغر من التوقيع. يستطيع فتح البوابة واختيار سياسة وترك دليل قابل للتدقيق عن قفزة واحدة. ولا يستطيع تصديق كل حقول المرسل أو نية الإنسان أو نص الرسالة أو المرحّلات التالية.

المصادر