العنوان الذي كان يجب أن يبقى فارغاً: كيف منع SMTP الأخطاء من مراسلة الأخطاء

الخلاصة

• تعيّن الرسالة العادية مساراً عكسياً لتقارير التسليم اللاحقة؛ أما رسالة الإشعار فتستخدم MAIL FROM:<> كي لا يؤدي فشلها إلى إشعار آخر ثم إلى حلقة.
• المسار الفارغ قيمة صحيحة في مغلف SMTP، وليس غياباً لحقل From: المرئي ولا دليلاً على الشرعية أو إعفاءً من الضوابط. يجب قبوله وفق معناه، وتبقى HELO وSPF سطحي تقييم للمضيف المرسل.
• أضافت DSN المهيكلة ربطاً ونتائج لكل مستلم، لكنها أبقت المرسل الختامي. عندما ينتهي التقرير البعيد، تنتقل مسؤولية الفشل الأخير إلى التشغيل المحلي ولا تختفي.

المشكلة الأصعب تبدأ بعد القبول

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

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

لو أعطيت هذه الرسالة الثانية صندوق مرسل عادي، نشأ وعد جديد: إن تعذر توصيل الإشعار، يُرسل إشعار إلى مرسله. وإن فشل ذلك الإشعار تكرر الأمر. تتحول آلية المساءلة إلى سلسلة لا حد لها.

رأى RFC 821 هذا الخطر منذ 1982. فقد وصف واجب الخادم الذي يقبل مهمة الترحيل ثم يعجز عن إتمامها، وحذّر من إرسال إشعارات عن مشكلات أصابت رسائل الإشعار. وكانت أداة الكسر المختصرة هي MAIL FROM:<>.

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

قبول الفراغ وطاعة النهاية التزامان متلازمان

حوّل RFC 1123 الوسيلة المبكرة إلى شرط على المضيف. يجب أن يدعم SMTP المسار العكسي الفارغ، ولا يجوز اعتبار MAIL FROM:<> صياغة تالفة لمجرد عدم وجود عنوان بريد تقليدي.

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

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

عنوان المغلف ليس From الظاهر للقارئ

المسار العكسي قيمة في معاملة SMTP. أما From: في رأس الرسالة فيشرح للقارئ جهة الإنشاء، وقد يوجّه Reply-To: جواباً بشرياً واعياً. يستطيع تقرير آلي أن يعرض اسم خدمة التشغيل في From وأن يحمل في الوقت نفسه MAIL FROM:<> في المغلف.

لا يوجد تناقض: الرؤوس تدير محادثة بشرية، والمغلف يوزع المسؤولية الآلية عن فشل التسليم. حين ينسخ برنامج From أو Reply-To إلى المغلف لأنه يرى قيمة فارغة، فإنه يعيد وصل الحافة التي حذفها البروتوكول كي يمنع التكرار.

يثبت RFC 5321 حد المسؤولية عند الرد الإيجابي بعد DATA. إذا توفرت أدلة الرفض أثناء المعاملة، كان الرفض المبكر أوضح: يتلقى العميل المتصل النتيجة، ولا تُرسل لاحقاً رسالة ارتداد إلى مسار عكسي ربما كان مزوراً.

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

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

انتهاء التقرير البعيد لا يعني محو العطل

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

ينبغي ألا يولد هذا المسار الداخلي DSN خارجياً آخر. فالتقرير البعيد يعيد نتيجة الالتزام إلى المجال الذي سمّى reverse-path، بينما يقول التنبيه المحلي للمشغل: «حتى تقريرنا النهائي لم يصل؛ افحص الطابور والتوجيه والإعداد». لا يخفي البروتوكول الخطأ، بل يحدد من يملكه في النهاية.

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

صارت DSN أدق من دون أن تفتح طريق عودة جديداً

كانت إشعارات عدم التسليم المبكرة نصوصاً مختلفة باختلاف المنتج واللغة، فصعب على البرامج ربطها بمعاملة ومستلم. أضاف RFC 3461 امتداد Delivery Status Notifications. يحمل ENVID معرّف مغلف للربط، ويحدد RET مقدار المحتوى الأصلي العائد، ويحفظ ORCPT المستلم قبل إعادة الكتابة. ويطلب NOTIFY حالات SUCCESS أو FAILURE أو DELAY، فيما تقف NEVER منفردة لطلب عدم الإشعار.

هذه المعلمات تشرح تفضيلات التقرير، ولا تغيّر قبول MAIL أو RCPT الصحيحين. كما أنها لا تتفوق على قاعدة النهاية: لا ينشئ MTA تقرير DSN لرسالة كان MAIL FROM فيها صفرياً، حتى لو ظهر مرسل محتمل في الرؤوس.

وعندما تُرسل DSN يكون عنوان مرسلها صفرياً. لا تستخدم معاملتها RET، وإذا استخدمت NOTIFY فلا تكون إلا NEVER. وهكذا يمكن أن يكون التقرير غنياً بالأدلة، بينما يكون طلب التقرير عن نفسه صفراً.

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

تتعلق DSN واحدة برسالة أصلية واحدة، لكنها قد تحمل كتلاً منفصلة لعدة مستلمين. يميز Action بين failed وdelayed وdelivered وrelayed وexpanded، ويحمل Status رمزاً منظماً. لذلك لا تختزل نتيجة نجحت لشخص وتأخرت لآخر وفشلت لثالث في عبارة غامضة واحدة.

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

روبوتات الإجازة ترث مشكلة النهاية نفسها

تقارير التسليم ليست الآلات الوحيدة التي قد تتبادل الاستجابات. يمكن لردود الإجازة وخدمات المجموعات ومكاتب المساعدة ومعالجات المحتوى أن تفعّل بعضها. يعمم RFC 3834 الانضباط: لا يولد المستجيب الآلي جواباً ستكون وجهته عنواناً صفرياً، وعادة يستعمل Return-Path في المغلف بدل التخمين من From أو Reply-To المخصصين للبشر.

إذا لم يكن للرد الآلي جواب مفيد، جاز أن يستخدم MAIL FROM:<>، ومع امتداد DSN يستحسن NOTIFY=NEVER. لكن إغلاق الحلقة ليس دليلاً على التفويض. يسهل تزوير عناوين العودة، ولذلك لا ينبغي لخدمة إرسال رد كبير أو إحداث أثر جانبي من دون سبب للاعتقاد أن الطرف المتأثر أجاز الطلب.

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

يغيب صندوق المرسل ولا يغيب سطح تقييم المضيف

يفحص SPF عادة نطاق MAIL FROM. يحدد RFC 7208 عند المسار الصفري بناء هوية MAIL FROM من postmaster في نطاق هوية HELO. يبقى بذلك ممكناً تقييم علاقة المضيف المرسل بالنطاق، ولو لم يوجد صندوق مرسل.

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

كما أن null MX شيء آخر. فهو إعلان DNS بأن نطاقاً لا يقبل البريد. أما null reverse-path فهو حالة في مغلف رسالة تُنقل فعلاً، ويمنع فقط تقريراً جديداً عن فشل تلك المعاملة. الأول يغلق قدرة الوجهة، والثاني يغلق تراجع الأخطاء.

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

يرد إشعار عدم التسليم الأصلي وكاسر الحلقة MAIL FROM:<> في RFC 821: https://www.rfc-editor.org/rfc/rfc821.html

يرد وجوب دعم المسار الفارغ ومنع إشعار عنوان عودة صفري في RFC 1123: https://www.rfc-editor.org/rfc/rfc1123.html

ترد معلمات مغلف DSN ومعاملة المرسل الصفري وNOTIFY=NEVER في RFC 3461: https://www.rfc-editor.org/rfc/rfc3461.html

ترد صيغة DSN المهيكلة وحقول الرسالة والمستلم وحدود الخصوصية في RFC 3464: https://www.rfc-editor.org/rfc/rfc3464.html

ترد قواعد ردود الإجازة والمجموعات والخدمات في RFC 3834: https://www.rfc-editor.org/rfc/rfc3834.html

ترد حدود مسؤولية SMTP الحالية وفئات المرسل الصفري ومسار postmaster المحلي في RFC 5321: https://www.rfc-editor.org/rfc/rfc5321.html

يرد الاستخدام المشروع للمرسل الصفري عند submission في RFC 6409: https://www.rfc-editor.org/rfc/rfc6409.html

ترد هوية SPF المعتمدة على HELO للمسار الصفري في RFC 7208: https://www.rfc-editor.org/rfc/rfc7208.html

تثبت هذه الوثائق التزامات البروتوكول، لا صحة DSN بعينها ولا سلوك مزود حالي. لا يدعي المقال أرقاماً راهنة لحجم الارتداد أو الرسائل المزعجة أو الرفض أو الانتشار.