الخلاصة

  • في SMTP الأصلي قد لا يظهر فشل الحجم أو التخزين إلا بعد نقل DATA كاملة ثم التخلص منها.
  • سمح RFC 1870 للخادم بإعلان سقف ثابت في EHLO وللعميل بتقديم تقدير لعدد الثمانيات في MAIL FROM. عبّر 552 عن تجاوز دائم، و452 عن عجز مؤقت.
  • بقي الرقم دليلاً محدوداً: لا يحدد نهاية DATA، ولا يحجز تخزين المسار كله، ولا يحول نجاح MAIL إلى ضمان للتسليم.

الحكم الذي جاء بعد الكلفة

رتب RFC 821 المعاملة في MAIL ثم أمر أو أكثر من RCPT وأخيراً DATA. بعد جواب 354 يرسل الطرف المرسل الرأس والمتن وسطر النهاية، ثم يقرر المستقبل بشأن الكائن المكتمل.

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

إعلانان يملكهما طرفان مختلفان

ظهرت الفكرة في RFC 1427 سنة 1993، ونقحها RFC 1653، ثم استقرت في RFC 1870 سنة 1995. يضع الخادم SIZE في جواب EHLO، ويمكنه إرفاق أكبر رسالة تسمح بها قاعدته الثابتة.

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

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

القياس ليس تأطيراً

يشمل العد الرأس والمتن وأزواج CR-LF المنقولة بعد 354. ولا يشمل نقطة إنهاء DATA ولا النقاط الإضافية التي أدخلت فقط لشفافية SMTP.

يحظر RFC 1870 استخدام SIZE لمعرفة نهاية المحتوى. قد يغير التقدير الخاطئ قرار القبول، لكنه لا يجعل بيانات الرسالة أوامر. يحتفظ مُنهي DATA بسلطة الحد. يعالج SIZE الموارد، بينما تعالج شفافية النقطة وBDAT التأطير.

يترك 452 وقتاً ويغلقه 552

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

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

جواب 250 المبكر ليس إيصالاً

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

مع ذلك ينشئ RFC 1870 ثقة محدودة: بعد قبول الحجم المعلن، لا ينبغي للخادم إصدار 552 بعد DATA بسبب سقفه المعتاد وحده ما دام الحجم الفعلي لم يتجاوز الإعلان. تصبح الموافقة المبكرة مفيدة من دون اختراع حجز عالمي.

فرض RFC 5321 لاحقاً قبول 64 ألف ثمانية على الأقل، وأوصى بـSIZE للخوادم التي تحتاج قيوداً. لم يحدد حجماً عالمياً. بقي كل نظام مالكاً لكلفته، وشارك البروتوكول طريقة إعلان الحد في الوقت المناسب.

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

يقدم RFC 821 المعاملة الأصلية، وتوثق RFC 1427 وRFC 1653 وRFC 1870 الامتداد، ويقدم RFC 5321 خط الأساس اللاحق. لا تقيس هذه الوثائق الانتشار الحالي أو حدود المزودين. لا يصادق SIZE على المحتوى، ولا يثبت حصة تخزين، ولا يحجز كل قفزة، ولا يثبت التسليم. إنه تاريخ أضيق: دليل سعة محدود منع بعض العمل المحكوم عليه بالفشل من دون تركيز السلطة.