الخلاصة

  • يعني الرد الإيجابي بعد علامة نهاية DATA في RFC 5321 أن خادم SMTP المستقبل قبل الرسالة وتحمل مسؤولية تسليمها أو ترحيلها. إنه انتقال للعهدة، لا إيصالاً من الوجهة النهائية.
  • لا يملك الرقم 250 معنى مستقلاً عن الأمر وحالة المعاملة؛ فهو قد يجيب EHLO أو MAIL FROM أو RCPT TO أو RSET أو NOOP، ولكل موضع واقعة مختلفة.
  • الإثبات المتين يربط الغلاف، ورد كل مستلم، ونهاية DATA، والطابور الدائم، وكل قفزة لاحقة، والنتيجة المحلية. أما موضع الرسالة وسياسة الترشيح وقراءة الإنسان فحقائق منفصلة.

نجاح له مالك جديد

المشكلة العملية ليست في أن 250 رد غامض داخل SMTP. المشكلة في أن لوحة المتابعة تنزعه من الجملة التي أجاب عنها ثم تسميه «تم التسليم».

يمكن أن يجيب الخادم بـ250 عن EHLO فيؤكد دخوله الحالة الابتدائية ويعرض الامتدادات. وقد يجيب به عن MAIL FROM، أي إنه قبل المسار العكسي وبدأ غلافاً. وقد يقبل به RCPT TO لمستلم بعينه. ويستطيع إرسال الرد نفسه بعد RSET، الذي يمحو حالة المعاملة، أو NOOP الذي لا يطلب عملاً أصلاً.

أما الواقعة محل هذا المقال فتقع بعد أن يرسل الخادم 354 سامحاً ببدء المحتوى، ثم يستقبل الرسالة وعلامة النهاية. عندئذ يقرر هل يقبل المعاملة من أجل التسليم أم يرفضها. الرد الإيجابي النهائي يعني أن المسؤولية انتقلت إليه. في نموذج SMTP الأساسي لا توجد عند هذه النقطة موافقة جزئية على المادة المرسلة.

هذه حدود الإسناد إلى John Klensin أيضاً. يعرّف ملف IETF الرسمي Dr. John C. Klensin، وكان يسرد 60 وثيقة RFC عند إجراء البحث. ويسميه RFC 5321 مؤلفاً. ذلك يثبت مساهمته في معيار جماعي، ولا يجعله مشغلاً لأي طابور قائم ولا شاهداً على مطابقة منتج بعينه.

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

يجب أن يسبق الحفظُ الوعدَ

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

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

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

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

الترحيل ليس صندوق البريد

الصياغة الحاسمة في RFC 5321 هي أن المستقبل يقبل مسؤولية التسليم أو الترحيل. العطف بين الفعلين مهم. فقد يكون الخادم Relay بعيداً عدة قفزات عن المستخدم. وبعد القبول يصبح بدوره عميلاً في معاملة SMTP جديدة ويطلب من الخادم التالي قبول عهدة جديدة.

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

حتى عبارة «التسليم النهائي» محدودة بنطاق SMTP: تخرج الرسالة من بيئة البروتوكول إلى مستخدم أو Mail Drop أو نظام آخر. قد يستمر بعد ذلك فحص أمني، أو حجر، أو قاعدة محلية، أو معالجة في منظومة أخرى. نهاية النقل ليست بالضرورة نهاية الأثر على الإنسان.

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

الصمت لا يملأ الفجوة

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

لكن قناة النفي ليست مضمونة. إذا كان المسار الأصلي فارغاً، فلا عنوان يعاد إليه فشل SMTP. وقد لا يستطيع Relay أو قائمة أو Alias أو خلل DNS مؤقت التحقق من المستلم أثناء المعاملة. وفي ظروف إساءة الاستخدام المعاصرة، قد يسمح بإسقاط بريد غير مرغوب فيه من دون تنبيه العنوان الظاهر، تفادياً لإغراق عنوان مزور برسائل مرتدة.

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

تضيف RFC 3461 وRFC 3463 وRFC 3464 طبقة DSN المنفصلة. يستطيع التقرير حمل إجراء لكل مستلم مثل failed أو delayed أو delivered أو relayed أو expanded. الطلب لا يضمن صدور التقرير، وrelayed لا يدعي الوصول النهائي، وdelivered لا يثبت القراءة. كما يحتاج التقرير نفسه إلى نقل ناجح.

الترتيب الزمني هو ما يحفظ المعنى: رد DATA النهائي يحدد حامل المسؤولية الجديد، ثم يصف DSN أو إيصال التسليم المحلي أو قبول القفزة التالية واقعة لاحقة. دمج الجميع في كلمة «وصل» يمحو من كان مسؤولاً وماذا حدث.

جواب ضائع قد يصنع نسختين

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

يمنح RFC 5321 انتظاراً طويلاً نسبياً للرد بعد نهاية DATA لأن الخادم قد يحتاج إلى معالجة كبيرة، ويطالبه أيضاً بألا يؤخر الرد من دون حاجة. هذا يقلل حالات الغموض ولا يلغيها؛ فقد تكون آخر واقعة شوهدت هي المادة أو الإقرار، وليس الاثنان معاً.

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

لكل بروتوكول عدد ردود مختلف

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

أما LMTP، وفق RFC 2033، فمصمم لتسليم محلي يستطيع إعلان نتيجة كل مستلم فوراً. بعد النقطة النهائية يرسل الخادم جواباً لكل أمر RCPT كان ناجحاً، وبالترتيب نفسه. الرد الإيجابي ينقل مسؤولية ذلك المستلم بالذات.

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

سجل عهدة لا شارة تسليم

الحد الأدنى المفيد يبدأ بهوية الاتصال والمعاملة، والطرفين كما تمت مشاهدتهما، وسياق TLS بوصفه حقيقة منفصلة. ثم يسجل MAIL FROM، وكل RCPT وردّه، و354، ونهاية DATA، والجواب النهائي، والطابع الزمني، ومعرّف الطابور إن وجد.

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

هذه Minimum Initial Specification وليست فرضاً لبنية موحدة. تبقى سياسات الطابور والخصوصية والاحتفاظ وإعادة المحاولة محلية. المشترك أضيق: لا تفصل الرد عن الأمر، ولا تسم العهدة تسليماً، ولا تورث يقين قفزة إلى القفزة التالية.

الخلاصة الصالحة للحادث أطول من 250 OK: قبل هذا الخادم هذا الغلاف وهذه المادة عند نهاية DATA؛ انتقلت المسؤولية إليه؛ رُصدت لاحقاً حالات الترحيل أو التسليم المحلي التالية؛ وما عداها من نتائج المستلم والمستخدم ما زال مجهولاً.

المصادر