الخلاصة

  • يقول تقرير Eric Allman المنشور عام 1994 إن العمل الأساسي على Sendmail توقف بعد فبراير 1987، ثم استؤنف في يوليو 1991 بعدما تراكمت نسخ متفرعة لدى المورّدين والمساهمين.
  • ذكر Allman أسباباً عدة للعودة، منها تغييرات Berkeley، وتباعد الإصدارات، وامتدادات SMTP التي رأى أنها لم تصل إلى معظم التطبيقات.
  • دعم Sendmail 8.6.6 بعض الامتدادات، مع بقاء قيود في غيرها. أتاح الإصدار العام فحص هذه الحدود، لكنه لم يثبت الانتشار أو الامتثال الكامل.

تحوّل التوقف الطويل إلى مشكلة إصدارات

كان Sendmail جزءاً من بيئة Unix في Berkeley قبل أن يصبح منتجاً لشركة أو رمزاً في النقاش حول اقتصاد البرمجيات مفتوحة المصدر. وتفيد سيرة Internet Hall of Fame بأن Eric Allman طوّر delivermail وSendmail في جامعة كاليفورنيا في Berkeley أثناء عمله على INGRES، وأن البرنامجين وُزّعا مع BSD. يوضح هذا السياق قيمة الشفرة العامة: استطاع بناة الأنظمة فحص موجّه البريد وتجميعه ضمن بيئاتهم الخاصة.

تقدم ورقة Allman لعام 1994، بعنوان «Changes in Sendmail Version 8»، وصفاً أدق لما تلا ذلك. فقد توقف العمل الأساسي على Sendmail عملياً بعد فبراير 1987، ولم يعد النشاط الفعلي إلا في يوليو 1991. قدم آخرون دعماً محدوداً خلال تلك السنوات، فيما أنشأ المورّدون والمساهمون من خارج المشروع نسخاً متباينة. وذكر Allman دوافع متعددة للعودة: احتاجت Berkeley إلى تعديلات للبريد تتناسب مع بنية النطاقات الفرعية ومع 4.4BSD؛ وكان قد راجع كتاب Bryan Costales عن Sendmail؛ وبرزت الحاجة إلى جمع الإصدارات المختلفة؛ كما تغيرت معايير SMTP.

لم يكن ذلك قراراً ذا سبب واحد. كان على الشفرة أن تواكب إصداراً جديداً من BSD، وأن توحّد الفروع، وأن تستجيب لتغيّر البروتوكول. وكتب Allman أن IDA-Sendmail تطور من ملفات إعداد إلى مجموعة كبيرة من التصحيحات، وأنه استُخدم على نطاق واسع لدى من كانوا يجمعون الشفرة المصدرية بأنفسهم. كما قال إن مجموعة IDA ومعظم المورّدين لم يدمجوا توضيحات SMTP وامتداداته الأحدث. هذا تقييم Allman بأثر رجعي عام 1994، وليس إحصاءً مستقلاً لكل مورّد أو عملية تثبيت.

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

أوضح الإصدار 8 حدود الدعم

استخدم Allman Sendmail 8.6.6 لإظهار أن الدعم ليس حالة ثنائية. تذكر الورقة أنه قدم أساسيات ESMTP الواردة في RFC 1425، وامتداد حجم الرسالة في RFC 1427، ودعماً محدوداً للمعامل BODY في RFC 1426. وتوضح أيضاً أن الإصدار لم يعلن 8BITMIME، ولم يحوّل الرسالة على نحو صحيح عند إرسالها إلى خادم SMTP لا يدعم بيانات الثمانية بت.

هذه تفاصيل أدق من القول إن «Sendmail 8 دعم معايير SMTP الجديدة»، لأنها تربط القدرات بإصدار محدد. يعرّف RFC 1425 تبادل قدرات ESMTP عبر EHLO، ويعرّف RFC 1427 الامتداد SIZE، بينما يعرّف RFC 1426 امتداد BODY المرتبط لاحقاً بـ8BITMIME. ويؤثر ما يعلنه الطرف المقابل، وما يختاره المرسل، وكيفية معالجة المستقبل، في نجاح النقل. ولا تحدد الورقة متى رقّت المنشآت إصداراتها أو مدى تكرار هذه المسارات في الإنتاج.

وتصف صفحة أخرى لتغييرات Sendmail Version 8 البرنامج بأنه «متوافق بشروط» مع RFC 1123، وتسرد المتطلبات المستوفاة والتحفظات الباقية. وتستشهد تلك الصفحة بأرقام أحدث لامتدادات RFC من الأرقام التي ناقشتها ورقة 1994. لذلك لا ينبغي دمج الوثيقتين في قائمة واحدة للميزات. وتبينان معاً أن أي ادعاء بالامتثال يحتاج إلى تحديد الإصدار والنص المعياري والاستثناءات.

لم تكن مساهمة Allman مجرد نشر رقم إصدار رئيسي جديد. فقد جعلت الورقة حدود التنفيذ قابلة للفهم: أي امتداد كان موجوداً، وأيها كان جزئياً، وأين استمر فشل التحويل. أما القفزة إلى الرقم 8 فلها تفسير عملي عادي: كانت ملفات توزيع 4.4BSD مرقمة بالفعل 8.1. ولم يكن ذلك إعلاناً عن حل كل مسائل البروتوكول.

أتاحت الشفرة العامة للمشغّلين شيئاً قابلاً للفحص

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

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

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

المصادر