الخلاصة

  • في SMTP يقبل الرد الإيجابي بعد البيانات الرسالة كوحدة واحدة، وينقل إلى الخادم مسؤولية التسليم الكامل أو معالجة الإخفاق اللاحق.
  • جعلت RFC 2033 خادم LMTP يرد بالترتيب على كل أمر RCPT ناجح، فيحتفظ مدير الطابور بالمستلمين غير المحسومين فقط؛ لكن ضياع رد بعد إتمام التسليم قد يظل سببا للتكرار.

كانت الحقيقة متعددة والجواب واحدا

يسلم مدير طابور رسالة إلى وكيل محلي لمستلمين. ينجح أمرا RCPT أولا. بعد وصول النص كاملا، يودع الوكيل الرسالة في الصندوق الأول، بينما يعيد الصندوق الثاني حالة مؤقتة بسبب الحصة.

لا يستطيع SMTP العادي إنهاء DATA بردين مختلفين. تنص RFC 5321 على أن قرار نهاية البيانات لا يقبل فشلا جزئيا: إما أن يقبل الخادم الرسالة للتسليم أو يرفضها. وإذا أعاد 250 تولى المسؤولية الكاملة. أما إخفاق مستلم لاحقا فيعالجه بطابوره أو بإشعار لاحق.

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

صمم LMTP لهذا الحد الضيق، لا ليحل محل SMTP عبر الإنترنت.

غير عدد الردود موضع المسؤولية

نشرت RFC 2033 سنة 1996 بوصفها RFC معلوماتية. وبعد النقطة النهائية لـ DATA، تعيد LMTP ردا لكل أمر RCPT نجح سابقا، وبالترتيب نفسه.

إذا وصل 250 النهائي الخاص بالمستلم A وصار ثابتا لدى الطابور، تنتهي مسؤوليته عنه. وإذا عاد 452 للمستلم B، يبقى B وحده لإعادة المحاولة. يقدم الوكيل المحلي حقيقة الصندوق من دون أن يرث آلة انتظار ثانية.

المطابقة موضعية. لا يدخل مستلم رفض قبل DATA في سلسلة النهاية. وإذا نجح مسار forward-path نفسه مرتين، فله موضعان وردان. ويعد الرد متعدد الأسطر ردا واحدا. لذلك لا يجوز إعادة بناء المطابقة لاحقا بجمع نصوص العناوين.

كما أن نجاح RCPT الأولي ليس وعدا بالتسليم. إنما ينقل الرد الإيجابي المقابل بعد البيانات المسؤولية لذلك المستلم.

أعلن LHLO أي قواعد جواب تعمل

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

لهذا استبدل LMTP أمري HELO وEHLO بـ LHLO. ولا يجوز لخادم LMTP أن يقبل تحيات SMTP إيجابيا، ولا أن يستخدم منفذ خدمة SMTP رقم 25. الغرض كشف اختلاف العقد قبل إرسال المحتوى.

وتفرض RFC 2033 دعم PIPELINING ورموز الحالة المحسنة. تحفظ RFC 2920 ترتيب الأجوبة مع إرسال الأوامر مسبقا، وتفصل RFC 2034 وRFC 3463 معنى الإخفاق. غير أن الرمز الدقيق لا يحدد وحده موضع RCPT؛ لا غنى عن السجل المرتب.

عند استخدام CHUNKING يعيد BDAT LAST السلسلة نفسها لكل مستلم، بينما يحتفظ BDAT غير النهائي برد واحد. تتعلق التعددية بإكمال الرسالة لا بكل كتلة بايتات.

بقيت فجوة بين الفعل ووصول دليله

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

يقسم LMTP هذا الغموض حسب المستلم، لكنه لا يجعل كتابة الصندوق ورد الشبكة عملية ذرية. إذا ثبت رد A أمكن إغلاقه. وإذا أودعت رسالة B ثم ضاع رده، فلا يملك العميل دليلا على انتقال المسؤولية. تلزمه RFC 2033 بمعالجة الردود التي وصلت واعتبار البقية إخفاقات مؤقتة.

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

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

لم يكن الرد الفوري إشعار DSN

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

لا يثبت ذلك أن إنسانا قرأ الرسالة أو أن واجهة عرضتها أو أن العنوان يحدد الشخص المقصود. إنه حساب لمسؤولية النقل لا للهوية أو الانتباه.

المصادر والحدود

تقتصر الحزمة على RFC 1047 وRFC 2033 وRFC 2034 وRFC 2920 وRFC 3463 وRFC 5321. تثبت هذه النصوص القواعد وحدود المسؤولية، لا الانتشار الحالي أو إعدادات المنتجات أو مقبسا موحدا. RFC 2033 معلوماتية وليست أمرا عاما باستخدام LMTP.