خادم البريد كان يقلّ الغرباء مجاناً

الخلاصة

• سمح SMTP في 1982 لخادم يتلقى البريد بأن يقبل مهمة الترحيل إلى خادم آخر، فيصير هو المرسل في المرحلة التالية.
• أوجب RFC 2505 عام 1999 تمكين وكيل نقل البريد من رفض الترحيل غير المأذون؛ فتحية HELO وعنوان MAIL FROM ادعاءان يسهل تزويرهما.

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

في RFC 821 الصادر في أغسطس 1982 كان الترحيل عملاً طبيعياً لخادم SMTP المتلقي. يستطيع قبول نقل رسالة إلى خادم تالٍ أو رفضه. وإذا قبل، صار المرسل في المرحلة التالية. فصل النص بين عنوان صندوق البريد النهائي والطريق الذي تسلكه الرسالة. كانت هذه القدرة تعين البريد على عبور الشبكات والبيئات المختلفة.

بحلول نهاية التسعينيات أصبحت المسألة من يحق له طلب تلك المرحلة الإضافية. وصف RFC 2505 الصادر في فبراير 1999 ضمن Best Current Practice 30 الترحيل بلا إذن بأنه استهلاك لموارد صاحب الخادم وتهديد لسمعته. وطالب بأن يستطيع برنامج نقل البريد ضبط الخدمة ورفضها. لم يُلغ عمل المراسل، بل وضع التفويض عند باب المرآب.

رتّب النص أربع إشارات في جلسة SMTP بحسب قوتها. اسم الجهاز في HELO يقوله المتصل، ويسهل انتحاله. وعنوان MAIL FROM الذي يدّعيه المرسل يسهل تزويره كذلك. يحدد RCPT TO الجهة المقصودة، ويرى الخادم عنوان الشبكة الذي جاء منه الاتصال. من يمنح حق الترحيل اعتماداً على التحية وعنوان المرسل يمنح مفاتيح الشاحنة لمن كتب لنفسه بطاقة تعريف.

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

كان في كتابة العناوين باب خلفي يستحق الانتباه. ذكر RFC 2505 مسارات المصدر من هيئة @a,@b:، وحيلة %، ومسارات UUCP التي تستعمل !. قد يبدو العنوان قريباً عند فحصه بسرعة، ثم يكشف التحليل الكامل أنه يطلب رحلة أخرى. وكانت بوابات بريد مشروعة تستعمل بعض الأشكال غير المألوفة أيضاً. لذلك دعا النص إلى جرد طرق التوجيه المستخدمة قبل إغلاق الترحيل. الحارس الذي لا يقرأ العنوان كاملاً يترك المحتال يدخل ويمنع الزبون المعروف.

في يونيو من السنة نفسها خاطب RFC 2635 المسمى DON'T SPEW مزودي الخدمة. نصحهم بألا يتركوا خوادمهم مفتوحة لترحيل بريد الغرباء، وأن يعلنوا سياسة استخدام، ويتحققوا من إساءة الحساب قبل معاقبته، ويخصصوا من يقرأ بريد abuse وpostmaster. قاعدة الخادم تستطيع رفض معاملة. الشكوى والعقد والخطأ في اتهام مستخدم تتطلب أشخاصاً وإجراءات وراء القاعدة.

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

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