الخلاصة

  • أوصت RFC 1204 بإرجاع 250 بعد USER صحيح الصيغة حتى إن لم يتعرف خادم الإيداع إلى الاسم. كان الرد يمنع حصر الحسابات، ولا يؤكد وجودها.
  • كان PASS 250 قرارًا آخر: جرى التحقق من ارتباط كلمة المرور بالاسم السابق. أما DATA 354 ففتح مدخل النص، وأثبت 250 بعد اكتمال الجسم دخوله في الطابور المحلي فقط.
  • استخدم NOOP 250 الرقم نفسه ليصف غياب خطأ داخلي في خادم الإيداع خلال الجلسة. لا يحدد الرمز وحده الواقعة من دون الأمر والحالة والمكوّن الذي أجاب.

أخفى الخادم معلومة بواسطة إجابة

تضع RFC 1204 قاعدة تبدو متناقضة للوهلة الأولى. يرسل العميل اسم المستخدم بأمر USER، ويأتي 250 بوصفه قبولًا للاسم. ثم تقول الوثيقة إن الخادم ينبغي أن يعطي الرد ذاته عندما لا يتعرف إلى الاسم، ما دامت صيغته سليمة.

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

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

تسجل صفحة RFC Editor نشر الوثيقة في فبراير 1991 وتصنيفها Experimental. وتوضح صفحة IETF Datatracker اليوم أنها وثيقة من مسار Legacy سبقت تسجيل المصدر الرسمي، ولا تحظى بتأييد IETF ولا بمكانة رسمية في عملية المعايير الحالية. إنها شاهد على آلية مقترحة، لا على انتشارها أو صلاحيتها المعاصرة.

لم يكن وسيط الإيداع هو منظومة البريد كلها

انطلقت الوثيقة من قيد تاريخي: أنظمة تشغيل الحواسيب الشخصية، بحسب وصفها، لم تكن توفر آلية لمصادقة المستخدم، مع أن البريد احتاج إلى تقليل انتحال المرسل. فوضع التصميم message posting server على مضيف خدمة البريد، يتحقق من مستخدم الحاسوب ثم يقدّم الرسالة باسمه إلى نظام تسليم مثل Sendmail أو MMDF.

توزعت السلطة منذ البداية. العميل قدّم الاسم والسر والنص. خادم الإيداع حكم على بيانات الاعتماد وامتلك الطابور المحلي. نظام التسليم امتلك المحاولة اللاحقة. استخدم Netix MPP اتصال TCP والمنفذ 218، واستعار بنية الأوامر والردود من SMTP وFTP.

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

نقل PASS الحكم إلى علاقة بيانات الاعتماد

بعد USER 250 يستطيع العميل إرسال PASS. إذا تحقق الخادم من أن كلمة المرور مرتبطة بالاسم الذي سبق تقديمه، أعاد 250 مرة أخرى. وإذا لم تطابقه أعاد 530، مع رموز أخرى لأخطاء الصيغة والترتيب والخادم.

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

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

جاءت RFC 4954 لاحقًا لتعرف SMTP AUTH بمفاوضة آلية SASL وردود مميزة. كما اشترطت إمكان رفض آليات كلمة المرور الصريحة من دون TLS أو حماية أخرى من التنصت. لا يجوز إرجاع هذه الضمانات إلى MPP بأثر رجعي؛ فهي تبين فقط أن المصادقة وحماية القناة سطحان مختلفان.

كان 354 إذنًا للقراءة لا سند حيازة

بعد نجاح كلمة المرور، يرسل العميل DATA. يعني 354 أن خادم الإيداع مستعد لاستقبال نص الرسالة. انتقل المحلل إلى حالة الجسم، لكن النهاية الكاملة لم تصل بعد، ولم يدخل كائن تام إلى الطابور.

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

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

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

وصف NOOP صحة محلية أضيق من الرسالة

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

هكذا أمكن للرقم نفسه أن يشير إلى أربع وقائع:

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

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

سَمّت المواصفات اللاحقة حد الإيداع بوضوح

نظمت RFC 6409 لاحقًا إيداع البريد على المنفذ 587. وميّزت Message Submission Agent، الذي يقبل الرسالة من برنامج المستخدم وقد يسلمها أو يمررها، من Message Transfer Agent. يسمح الفصل بسياسات وآليات أمن مختلفة للإيداع والترحيل.

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

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

المصادر