الخلاصة

  • جعل RSET الرسالة غير المكتملة معاملة قابلة للمحو داخل جلسة أطول: يُزال المرسل والمستلمون والبيانات، لكن الاتصال لا يُغلق.
  • يؤكد رد 250 OK اكتمال إعادة الضبط، لا تسليم الرسالة. ولا يلغي معاملة انتهت سابقًا، ولا يمحو TLS أو هوية الجلسة أو سجلها التشغيلي كله.

مستلم مقبول بقي في ظرف لم يعد مطلوبًا

يرسل العميل MAIL FROM ثم أمرين من RCPT TO. يقبل الخادم العنوان الأول ويرفض الثاني. غير أن قاعدة التطبيق تقول إن الرسالة لا قيمة لها إلا إذا وصلت إلى الاثنين معًا.

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

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

كان النسيان جزءًا من SMTP منذ 1982

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

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

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

تنظيف العميل لا يثبت تنظيف الخادم

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

يفرض RFC 5321 رد 250 OK على RSET من دون معاملات، ويسمح بإرساله في أي وقت. إن لم تكن هناك معاملة مفتوحة فلا يكاد يغير شيئًا؛ وإن وُجدت، تُحذف معلومات المرسل والمستلمين والبيانات. ولا يجوز للخادم أن يغلق الاتصال بسبب الأمر، فالإغلاق وظيفة QUIT.

معنى 250 يتحدد بالأمر الذي يجيب عنه. بعد RSET يثبت نجاح التنظيف، لا قبول محتوى الرسالة السابقة. ولا يضمن مسح كل أثر مادي أو سجل تدقيق. الضمان هو أن حالة الظرف الملغى لن تتحكم في المعاملة التالية.

ما يُمحى وما يبقى

قد توحي عبارة تنظيف جداول الحالة بفقدان ذاكرة الجلسة كلها، لكن قواعد SMTP تفصل الطبقات.

يبقى اتصال TCP. لا يعيد الخادم التحية. لا يلزم اكتشاف جميع قدرات EHLO من جديد بسبب ظرف ملغى. يظل TLS قائمًا ولا تعود الهوية الموثقة مجهولة. ويمكن بقاء قياس المعدل وسجل إساءة الاستخدام. الذي يجب ألا يبقى هو مرسل المعاملة السابقة أو مستلموها أو جزء من متنها.

يذكر RFC 5321 أن EHLO جديدًا مقبولًا يصفر حالة المعاملة كما يفعل RSET. لكنه يعيد أيضًا عمل التحية والقدرات، ولذلك يكون أعلى كلفة عادة. التشابه يخص إلغاء الظرف المفتوح، لا الغرض الكامل للأمرين.

يعرض STARTTLS حدًا أوسع. يطلب RFC 3207 بعد نجاح المصافحة أن يتخلى الطرفان عن المعرفة التي اكتسباها قبل TLS وأن يبدأ العميل بـ EHLO جديد. تغيّر سياق الأمان، فتعاد معرفة قدرات الجلسة. إلغاء رسالة عادية لا يحتاج إلى هذا الاتساع.

الإلغاء لا يعيد الزمن

تبدأ معاملة البريد بـ MAIL، ثم واحد أو أكثر من RCPT، وتنتهي بنقل المحتوى. يعمل RSET على الوحدة التي ما زالت مفتوحة. إذا قُبلت البيانات النهائية فقد اكتملت معاملة مستقلة؛ reset لاحق يهيئ التالية ولا يسحب المسؤولية السابقة.

الجلسة الطويلة ليست معاملة قاعدة بيانات واحدة تشمل كل الرسائل. لكل رسالة مكتملة نتيجتها. استمرار الاتصال لا يجعل تاريخ القبول قابلًا للرجوع الجماعي.

لهذا تكون لوحة تجمع كل ردود 250 بلا الأمر المقابل مضللة. قبول مستلم وقبول المحتوى ونجاح reset ثلاثة ادعاءات عن ثلاثة أشياء.

قرّب PIPELINING الحدود ولم يلغها

سمح RFC 2920 بإرسال مجموعات من الأوامر من دون انتظار كل رد. يمكن أن يظهر RSET وأوامر المرسل وRCPT TO داخل المجموعة. ويمكن حتى أن تشترك نهاية محتوى رسالة مع reset والمرسل الجديد للرسالة التالية في إرسال TCP واحد.

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

كلما ازدادت السرعة ازدادت أهمية دفتر الحالة. تفريغ مخزن العميل يثبت استعداده فقط؛ رد الخادم المرتبط يثبت أن الطرف الآخر عبر الحد نفسه.

تنظيف حالة كتلة غير محسومة

ينقل RFC 3030 المحتوى في كتل BDAT. كتلة بعد BDAT LAST، أو خلط DATA وBDAT في المعاملة نفسها، أو فشل يترك الحالة غير محسومة، كلها حالات تتطلب RSET قبل مواصلة أوامر البريد.

يزيل reset الأجزاء المرتبطة بالمحاولة. لا يمحو الاتصال أو TLS أو سجل التشغيل؛ يمنع البايتات الجزئية من أن تصبح جزءًا من رسالة لاحقة.

ويحمي RFC 4954 نطاقًا آخر: لا يجوز تنفيذ AUTH داخل معاملة بريد مفتوحة، ويجب رفضه بـ 503. لا يمكن تبديل هوية الجلسة بين المرسل والمستلمين والمحتوى. يجب أولًا إنهاء الظرف أو إلغاؤه.

الاستعادة ذات النطاق المحدد

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

لم يصبح SMTP عديم الحالة. بل تعلّم تقسيم الحالة: يمكن نسيان رسالة غير مكتملة من دون نسيان المحادثة، ويمكن استمرار المحادثة من دون إعادة كتابة نتائج الرسائل المكتملة.

المصادر