الخلاصة

  • تسمح RFC4865 للعميل بأن يطلب من خادم تقديم البريد الاحتفاظ برسالة إلى وقت لاحق. الالتزام بعدم إطلاقها مبكراً لا يضمن إطلاقاً في اللحظة الدقيقة، ولا وصولاً إلى صندوق المستلم أو قراءةً بشرية.
  • عند الجمع مع DELIVERBY يجب أن يجعل العميل مهلة التسليم لاحقة لوقت الإطلاق على نحو صارم. وللخادم شرط رفض مصاغ بصورة مختلفة؛ وتظل الساعة والحصص ونمط انتهاء المهلة وسجلات النتيجة مسؤوليات منفصلة.

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

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

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

هذا هو المدخل المفيد إلى RFC4865 المنشورة في مايو2007. تعرف الوثيقة Future Message Release لتقديم البريد عبر SMTP، بحيث يستطيع العميل نقل انتظار الرسالة إلى الخادم عندما لا يملك تخزيناً محلياً مناسباً أو لا يستطيع البقاء متاحاً حتى الموعد.

تنتقل مع الراحة أعباء حقيقية: محتوى يجب حفظه، وسعة تُستهلك الآن، وعمل لا يمكن تنفيذه إلا لاحقاً. قبول هذه الأعباء لا يجعل خادم التقديم مالكاً لقرارات كل الخوادم التي ستحمل الرسالة بعد ذلك.

ما الذي تعنيه ساعة يختارها المستخدم؟

يعلن الخادم FUTURERELEASE في استجابة EHLO مع حدين: أطول مدة انتظار وأبعد تاريخ ووقت يسمح بهما. على العميل التحقق من الدعم أولاً ثم إدراج معامل انتظار واحد فقط في أمر MAIL.

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

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

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

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

كذلك لا يحمي HOLDFOR الخدمة تلقائياً من اضطراب الساعة. تحذر RFC4865 من أن وقت الخادم غير الدقيق أو المتغير قد يؤدي إلى إطلاق مبكر أو متأخر في كلتا الطريقتين. اختيار صيغة نسبية مناسبة للعميل ليس شهادة بصحة أساس الزمن لدى المشغل.

عندما لا تتسع النافذة للالتزامين

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

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

تنص الفقرة5.2.1 من RFC4865 على أن العميل الذي يجمع الإضافتين يجب أن يجعل وقت التسليم النهائي أبعد في المستقبل من وقت الإطلاق المحدد أو المستنتج من المدة. العلاقة صارمة: يجب أن يكون التسليم النهائي لاحقاً، لا أن تكون القيمتان فقط في المستقبل.

أما الفقرة5.2.2 فتقول إن الخادم الداعم للإضافتين يجب أن يرفض MAIL إذا تبين له أن وقت الإطلاق يأتي بعد مهلة التسليم. وتوصي بالاستجابة501 ورمز الحالة المحسن5.5.4 لهذه الحالة.

من المهم إبقاء الفرق في الصياغة. لا يجوز تحويل شرط الخادم المكتوب إلى «بعد أو مساوٍ» من دون أساس. وفي الوقت نفسه، لا تسمح هذه الصياغة الأضيق للعميل بطلب وقتين متساويين؛ فهو لا يزال ملزماً بوضع المهلة بعد الإطلاق على نحو صارم.

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

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

انتهاء المهلة لا يعني دائماً إيقاف العمل

تميّز RFC2852 بين نمطي Return وNotify. في Return، إذا لم تقع عملية التسليم أو الترحيل المعنية قبل المهلة، فلا يجوز الاستمرار في محاولات التسليم. ويجب إنشاء إشعار الفشل المناسب للمستلمين الذين تنطبق عليهم شروط الإشعار.

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

قد تختصر الواجهة الحالتين في عبارة «انتهت المهلة»، لكن نظام الاستعادة يحتاج إلى النمط. الاستمرار في كل الحالات قد يخالف Return، والتوقف في كل الحالات قد يقطع عملاً كان يفترض أن يستمر تحت Notify. عدد الرسائل التي وصلت ليس مقياساً كافياً لصحة القرار.

وتختلف أيضاً شروط المرحلة التالية. لا يجوز تمرير رسالة Return إلى خادم لا يدعم DELIVERBY، أو إلى خادم يتجاوز الحد الأدنى الثابت لديه الوقت المتبقي. أما Notify فيمكن أن يعبر مرحلة غير داعمة، مع النتائج المتعلقة بالإشعار التي تحددها RFC2852.

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

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

حتى كلمة «قُبلت» تحتاج إلى مرحلة. فالاستجابة الإيجابية لأمر MAIL ليست إثباتاً على اكتمال قبول الرسالة كلها، فضلاً عن تسليمها. قد تتبين استحالة الوفاء أثناء معالجة المستلمين أو عند اكتمال البيانات، كما تذكر RFC2852. تجميع كل الاستجابات الإيجابية في عداد واحد يخفي هذه الفروق.

المستخدم المصرح له لا يملك مخزناً بلا حدود

الانتظار على الخادم يستهلك موارد بينما يظل بعض العمل ممنوعاً من المغادرة. المصادقة تعالج جانباً من استخدام غير المصرح لهم، لكنها لا تمنع مستخدماً مشروعاً من ملء المخزن برسائل مستقبلية.

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

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

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

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

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

يطرح Lu Heng في Note32 مشكلة الوكالة عندما ينفصل التحكم عن النتائج الاقتصادية. وعند تطبيق هذا المنظور هنا، تصبح الأسئلة: من يوسع أفق الحجز؟ من يمول مخزون الالتزامات؟ ومن يجيب عن التنفيذ؟ لا يثبت ذلك سوء نية شركة أو مهندس. وتؤكد Note36 بشأن BTW.Media ضرورة وصف البنية بدلاً من تحويل التحليل إلى دفاع عن طرف.

الطلب الأصلي ليس شهادة على التنفيذ

إذا أنشأ خادم التقديم DSN بشأن رسالة تحمل طلب إطلاق مستقبلي، تلزمه RFC4865 بتضمين Arrival-Date وFuture-Release-Request في الجزء المقروء آلياً. يحفظ الحقل الثاني قيمة الانتظار الأصلية بالشكل الذي تعرفه الإضافة.

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

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

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

تحل RFC6409 محل RFC4409 وتفصل تقديم البريد عن ترحيله. يستخدم التقديم عادة المنفذ587. والسماح العام بتعيين خدمات معينة على25 للتقديم لا يمنح خادم ترحيل عادي ترخيصاً بإعلان FUTURERELEASE. تظل الإضافة محكومة بنطاقها الخاص بالتقديم.

حدود ما نعرفه

تصحح الملاحظة التحريرية2040، المتحقق منها لـRFC4865، قاعدة تاريخ ووقت كانت غير معرفة، لتحيل إلى date-time في RFC3339. وإشارة مقدم التصحيح عام2010 إلى خادم يعمل لديه شهادة تاريخية منسوبة إليه، لا مسحاً لانتشار التنفيذ اليوم.

أما التصحيح التحريري2300 لـRFC2852 فمحفوظ إلى حين تحديث الوثيقة، ويتناول المسافات في القواعد النحوية. لا يغير سلوك المهل أو الأنماط. حالة التصحيح نفسها جزء من الدليل، وليست تفصيلاً يجوز إسقاطه.

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

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

المصادر