الخلاصة

  • أتاحت RFC 2298 المنشورة في مارس 1998 للمرسل طلب إشعار عبر Disposition-Notification-To. يستطيع برنامج المستلم تجاهل الطلب بصمت أو إرسال denied في الصيغة الأصلية.
  • يسجل الإشعار أفعال البرنامج مثل العرض أو الإرسال إلى جهة أخرى أو المعالجة أو الحذف. أوصت المواصفة بقوة بموافقة المستخدم وحددت إشعاراً واحداً كحد أقصى لكل مستلم ورسالة. وفي RFC 3798 عام 2004 حُذفت حالتا denied وfailed لقلة استعمالهما.

سؤال صغير في ظرف إلكتروني

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

حددت RFC 2298 ما يسمى Message Disposition Notification أو MDN. يصف فصلها الثاني الترويسة بأنها طلب. يستطيع وكيل المستخدم لدى المستلم تركه بلا جواب. وكانت المفردات الأولى تتضمن denied، وهي طريقة صريحة للاحتفاظ بمعلومة مصير الرسالة. كما أوصت الوثيقة بقوة بالحصول على موافقة المستخدم قبل إرسال التقرير، إما بسؤال يظهر لكل رسالة، وإما بتفضيل محفوظ سلفاً. كان للمرسل حق القرع؛ وكان للمستلم حق فتح الباب.

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

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

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

كان عنوان العودة أكثر خطورة. يستطيع مرسل سيئ النية أن يطلب توجيه تقارير كثيرة إلى شخص ثالث لا علاقة له بالمحادثة. لذلك أوصت RFC بمقارنة عنوان Disposition-Notification-To مع Return-Path. اختلاف العنوانين، أو غياب مسار العودة، أو تعدد عناوين الطلب، يستدعي تأكيداً من المستخدم أو وقف الإرسال التلقائي. ذكرت الوثيقة دوائر البريد وقصف البريد أسباباً لذلك. يمكن لورقة طلب مهذبة أن تتحول إلى آلة إزعاج إذا أجابت البرامج بلا تدقيق.

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

ثم سحبت المراجعة التالية ختم الرفض الرسمي. حلت RFC 3798 محل RFC 2298 في مايو 2004 وحذفت denied وfailed بسبب غياب استعمال أو تنفيذ يُذكر لهما. بقي خيار الصمت. اختفت كلمة «لا» المطبوعة في خانة البروتوكول، وبقي الباب قادراً على البقاء مغلقاً.

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