الخلاصة

  • أتاح RFC 3461 طلب إشعارات النجاح أو الفشل أو التأخير لكل مستلم، وحمل مع الرسالة معرّفاً لمعاملة الظرف وآخر للمستلم الأصلي. ونظم RFC 3464 الجواب في حقول يفهمها الإنسان والآلة.
  • وضعت المفردات حدودها داخلها: لا تعني delivered أن الرسالة قُرئت، وتعلن relayed انتهاء مسؤولية الإبلاغ عن النجاح، كما يمكن تزوير DSN أو فقدها أو تقليصها لحماية عنوان تحويل سري.

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

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

فصلت RFC 3461 و3463 و3464، المنشورة في يناير/كانون الثاني 2003، بين الطلب وشكل التقرير ورمز الحالة. لم يكن الهدف صنع ضمان شامل، بل توزيع سلطة القول: المرسل يطلب نوع الدليل، والـ MTA يصف الفعل الذي اتخذه، والبوابة تعلن النقطة التي لا تعود بعدها قادرة على الرؤية.

أربعة معاملات فصلت الرغبة عن النتيجة

يعلن الخادم القدرة بالكلمة DSN في رد EHLO. لا يضيف الامتداد أفعال SMTP جديدة؛ بل يضيف RET وENVID إلى MAIL، وNOTIFY وORCPT إلى RCPT.

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

ولا يحدد DELAY مؤقتاً. فالـ MTA الذي يحتفظ بالرسالة يقرر متى صار الانتظار غير معتاد، مع بقاء المصير النهائي مجهولاً. قد ترافق حالة 4.x.x نفسها فعل delayed أثناء المحاولة، ثم failed بعد أن تتوقف الطابور عن المحاولة.

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

لم تكن هويات الرسالة شيئاً واحداً

يعرّف ENVID معاملة الظرف، ويمكن أن يعود في DSN باسم Original-Envelope-Id. لا يفسر نظام البريد قيمته؛ المرسل أو وكيله هو من يمنحها المعنى. لذلك يختلف عن Message-Id الموجود في الرأس: ذلك يعرّف المحتوى، وهذا يعرّف عملية تسليم بعينها. يمكن تقديم المحتوى نفسه مرات عدة، ويمكن لمعاملة واحدة أن تضم مستلمين بنتائج متباينة.

يحفظ ORCPT العنوان الأصلي الذي حدده المرسل. في التقديم الأول يجب أن يطابق RCPT TO. وبعد التحويل قد يتغير عنوان التشغيل ويبقى العنوان الأصلي موازياً له. يبين العنوان الحالي وجهة المحاولة التالية، بينما يربط ORCPT الدليل بمن قصده المرسل أولاً.

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

الفعل والسبب لم يكونا حقلاً واحداً

صاغ RFC 3464 الـ DSN في بنية multipart/report: شرح يقرأه الإنسان أولاً، ثم message/delivery-status ببيانات عامة ومجموعة حقول لكل مستلم، ثم نسخة اختيارية من الرسالة أو رؤوسها.

يحمل كل مستلم قيمة Action: إما failed أو delayed أو delivered أو relayed أو expanded. ويأتي Status من RFC 3463 بثلاثة أجزاء: 2.x.x للنجاح، و4.x.x للفشل العابر المستمر، و5.x.x للفشل الدائم، ثم تفصيل الموضوع والسبب.

لا يكرر الحقلان المعنى. قد يبقى فشل استعلام DNS في فئة 4.x.x حين تستمر المحاولة وحين تنتهي. تتغير Action من delayed إلى failed: الحالة تصف الظرف، والفعل يصف القرار التشغيلي.

failed نهائي، وdelayed غير نهائي. أما delivered فنهائي لذلك المستلم، لكنه قد يعني التسليم إلى موزع قائمة بريدية ولا يعني أبداً أن إنساناً قرأ الرسالة. وexpanded يعني أن اسماً مستعاراً متعدد المستلمين قبل الرسالة وأنشأ وجهات جديدة، ولذلك قد تأتي تقارير أخرى.

تكشف relayed حد المعرفة. انتقلت الرسالة إلى بيئة لا تتحمل مسؤولية إصدار تقرير نجاح نهائي. يستطيع الـ MTA إثبات التسليم إلى البيئة التالية، لا الوصول إلى صندوق البريد. سمى البروتوكول فقدان الرؤية بدلاً من اختلاق نجاح.

كان لا بد أن ينتهي فشل التقرير بصمت

الـ DSN نفسها رسالة بريد ويمكن أن تفشل. لو أن فشلها أنشأ DSN أخرى لأمكن لنظامين غير قابلين للوصول إنتاج سلسلة بلا نهاية من التقارير. لذلك تستخدم DSN المرسلة عبر SMTP مسار الرجوع الفارغ MAIL FROM:<>، ولا يولد فشلها تقريراً جديداً على الشبكة.

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

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

التنسيق المنظم لم يكن شهادة أصالة

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

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

تكمن القيمة التاريخية لـ DSN في قواعد سلطة محدودة. يحدد المرسل الطلب ومفاتيح الربط. تقرر عقد MTA القبول وإعادة المحاولة والتوقف، وتبلغ عن فعلها هي. تترجم البوابات إلى حدود قدرتها، وقد توقف السرية الإفصاح. أما قراءة الإنسان فتبقى خارج SMTP.

ما زال سجل IANA لامتدادات SMTP يربط DSN بـ RFC 3461. صار الإيصال مفيداً لأنه يحدد المعاملة والمستلم الأصلي والجهة المبلغة والفعل والتشخيص، من دون أن يحول ذلك إلى وعد بالوصول إلى صندوق الوارد أو انتباه إنسان. الحد جزء من الدليل نفسه.

المصادر