الخلاصة

  • أضاف DELIVERBY إلى غلاف SMTP عدداً من الثواني وخيارين عند انتهاء المهلة: يوقف R المحاولات ويعيد فشلاً، بينما يرسل N إشعار تأخير ويترك سياسة الطابور تواصل التسليم.
  • على كل مرحّل داعم أن يطرح الزمن المستهلك ويرسل الرصيد فقط. لم يكن الامتداد شراءً للأولوية ولا ضماناً للتسليم أو لإعادة DSN قبل الموعد.

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

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

نشر Deliver By SMTP Service Extension في يونيو 2000. لم يمنح المرسل أمراً لإدارة الموارد البعيدة. منح كل خادم فرصة إعلان ما يقبله، ثم ألزم من يقبل بأن يحفظ نتيجة انتهاء المهلة وأن يمرر زمناً أقل إلى العقدة التالية.

الإعلان حدّد حق الرفض

يضع الخادم DELIVERBY في رد EHLO، ويمكن أن يضيف حداً أدنى ثابتاً للزمن الذي يقبله في وضع Return. يضيف العميل معامل BY إلى MAIL FROM. لا يوجد فعل SMTP جديد.

يعمل الحد الأدنى كحد قبول لا كدعاية سرعة. إذا بقيت 98 ثانية وأعلن الخادم التالي أنه لا يقبل Return بأقل من 240 ثانية، فلا يستطيع حمل الالتزام. يمكن للمرحّل أن يبحث عن مسار مشروع آخر، لكنه لا يستطيع تجاهل الفارق وتسميته توافقاً.

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

وقد ينجح MAIL FROM ثم يفشل الطلب في RCPT TO أو DATA أو عند نهاية البيانات. معلومات المستلمين والمحتوى تظهر تدريجياً. لذلك لا يثبت الرد الإيجابي المبكر أن كل مستلم سيُخدم ضمن المهلة؛ يثبت فقط قبول ما عُرف في تلك المرحلة.

الزمن النسبي عبر الحدود الإدارية

يحمل BY عدداً عشرياً موقّعاً من الثواني، ووضع R أو N، ويمكن أن يحمل T للتتبع. يمتد المجال من سالب إلى موجب 999,999,999 ثانية.

القيمة فرق زمني وليست تاريخاً مطلقاً. يضيفها الخادم إلى وقته المحلي فينشئ deliver-by-time. وقبل أن يرسل الرسالة إلى خادم داعم آخر، يحسب الثواني الباقية قريباً قدر الإمكان من MAIL FROM الجديد.

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

ولا تعني القيمة “سلّم بعد هذا الوقت”. إنها حد أعلى لا تأجيل متعمد. ولا تمدد مدة الاحتفاظ المعتادة؛ يستطيع MTA أن يفشل أبكر إذا كانت سياسته المحلية تنهي الرسائل غير القابلة للتسليم قبل الموعد المطلوب.

R يسحب الإذن وN يحفظه

في Return، لا يصح الصفر ولا الرقم السالب. إذا وصل deliver-by-time قبل التسليم أو الترحيل، فلا يجوز إجراء محاولة أخرى. ينشئ MTA إشعار DSN بحالة failed ورمز 5.4.7، delivery time expired، للمستلمين الذين تنطبق عليهم تقارير الفشل.

في Notify، لا تنهي المهلة الحيازة. يستمر الخادم وفق سياسة موقعه، ويرسل DSN بحالة delayed ورمز 4.4.7 للمستلمين المعنيين. الصفر والرقم السالب صحيحان لأن كون الموعد قد فات يظل معلومة حتى مع استمرار التسليم.

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

لا تختفي قواعد الفشل الأخرى. يمكن للفشل الدائم أن ينهي المعاملة مبكراً، وللفشل المؤقت أن يبرر إعادة المحاولة، ولسياسة الاحتفاظ الأقصر أن تعمل. يضيف DELIVERBY حداً ولا يعيد كتابة كل SMTP.

لا يرث المرحّل الزمن الأصلي

عندما يدعم الخادم التالي DELIVERBY، يجب أن يحتفظ المرحّل بالوضع ويرسل عدد الثواني المتبقية. إذا تلقى 120 ثانية واستهلك 22، يرسل 98. إعادة 120 تجعل كل نطاق يمحو كلفة النطاق السابق وتحول المهلة إلى وعد لا ينتهي.

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

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

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

التقرير منفصل عن القرار

يستخدم DELIVERBY مفردات DSN للفشل والتأخير والترحيل، ويضيف Deliver-By-Date إلى التقرير. ويمكن لـ T طلب تقارير ترحيل في كل قفزة؛ وهذه ليست نتائج نهائية.

تصف DSN عملاً اتخذه النظام. أما DELIVERBY فيحدد العمل الذي تفرضه نهاية الوقت. لذلك لا تختزل هذه القصة في قصة الإيصال السابقة: موضوعها المركزي هو من يحتفظ بحق المحاولة بعد انقضاء الموعد.

والتقرير نفسه رسالة جديدة. قد تنتهي رسالة BY=60;R بعد ستين ثانية، لكن DSN الفشل لا يضمن العودة إلى المرسل خلال ستين ثانية. للمسار العائد طوابيره وأعطاله. يستطيع البروتوكول تقييد القرار الأمامي من دون ادعاء السيطرة على كل معرفة لاحقة.

المهلة أداة رصد أيضاً

يكشف T عمليات الترحيل. وحتى بدونه، يمكن إرسال رسائل بمهل قصيرة متدرجة ومقارنة الرفض والتأخير لاستنتاج عتبات أو زمن تقريبي. ذكر RFC 2852 هذا الاحتمال في اعتبارات الأمن.

لا تكفي الإشارة لحكم واسع. القيمة السالبة في Notify تقول إن الموعد المحلي مضى، لا من سبّب التأخير. 5.4.7 يقول إن التزام Return انتهى، لا إنه يثبت الإهمال. relayed يثبت تسليماً إلى نظام آخر، لا الوصول النهائي.

لا يزال سجل IANA لامتدادات SMTP يدرج DELIVERBY ويحيله إلى RFC 2852 بمستوى MAY. يثبت السجل وجود تعريف معياري، لا نسبة التطبيق الحالية.

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

لم تنتقل المهلة لأن المرسل حكم الطريق. انتقلت لأن كل مرحّل حمل رصيداً قابلاً للنقصان، لا وعداً يستطيع ابتداءه من جديد.

المصادر