ترخيص Sender ID بلا رسوم، ومع ذلك رفضت Apache شحنه

الخلاصة

• أعلنت Apache في رسالتها المفتوحة بتاريخ 2 سبتمبر 2004 أن ترخيص Microsoft لبراءة Sender ID، بصيغته آنذاك، يمنع مشروعيها SpamAssassin وJAMES من تنفيذ التقنية أو تشغيلها. اعترضت المؤسسة على شروط إعادة الترخيص والتوزيع اللاحق.
• نشرت IETF مواصفات Sender ID وSPF عام 2006 بوصفها تجارب، وحذّرت من ضياع بريد مشروع بسبب تضارب تفسير سجلات DNS. سجل تقييم 2012 انتشار SPF وضعف استخدام Sender ID، ثم نُقلت وثائق الأخير إلى حالة Historic عام 2020.

أي مرسل تصادق عليه السياسة؟

قد يرى القارئ عنواناً في خانة From، بينما يستخدم خادم البريد عنوان MAIL FROM خلال محادثة SMTP، ويعلن اسماً آخر في EHLO. وتزيد إعادة التوجيه المسافة بين هذه الهويات. عندما ينشر نطاق في DNS أسماء الأجهزة المسموح لها بإرسال بريده، لا تكفي معرفة القائمة؛ على الخادم المستقبل أن يقرر أي هوية سيربط بها الإذن.

جعل ميثاق فريق MARID لدى IETF هذا الاختيار أول مهمة له. عدّد From وSender في الترويسات، وMAIL FROM وEHLO في بروتوكول النقل. استعمل Sender ID خوارزمية PRA لاستخراج عنوان المسؤول المفترض من الترويسات، بينما فحص SPF هوية جلسة SMTP. وضع السياسات في DNS أعطى الحلين مظهراً متشابهاً، لكنه لم يجعل موضوع الفحص واحداً.

رسوم صفرية وباب يملكه صاحب البراءة

في رسالة سبتمبر 2004، قالت Apache إن شروط Microsoft الحالية لا تتفق مع Apache License 2.0. سمّت مشروعين يعملان في البريد فعلاً: مرشح الرسائل المزعجة SpamAssassin وخادم JAMES. وكان قرارها صريحاً: لن تنفذ Sender ID ولن تنشره بموجب تلك الشروط.

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

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

نشرت IETF خلافاً لم تتم تسويته

في أبريل 2006، ظهرت وثائق Sender ID وSPF معاً في فئة Experimental. قالت ملاحظة IESG إن توافقاً تقنياً عاماً لم يتحقق وإن محاولات التوفيق فشلت. وحذّرت من أن خادم Sender ID قد يقرأ سجلاً نُشر من أجل SPF، ثم يطبق عليه هوية مختلفة فتضيع رسالة صالحة. وأشارت إلى مشكلة أخرى في إعادة التوجيه الآلي وترويسات Resent-*.

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

فحص تقرير IETF لعام 2012 الانتشار بعد سنوات من التشغيل. وجد SPF واسع الاستخدام، في حين لم تجذب مكونات PRA وSUBMITTER في Sender ID قاعدة قوية. وتوفرت برامج للنهجين؛ وقرر التقرير أن غياب البرامج لم يكن العامل الحاسم في الاختيار. التقرير رصد ما نُشر وشُغّل، ولم يمنح أحد التصميمين شهادة تفوق نظري. دخل SPF مسار المعايير عام 2014، وانتقلت وثائق Sender ID الثلاث إلى Historic في 2020.

أغلق رفض Apache عام 2004 طريق تنفيذ محدداً. ووصفت مراجعة IETF لاحقاً نتيجة اختيار أوسع لدى مشغلي البريد. بين السجلين بقي تحذير 2006: الإذن المكتوب في DNS يفقد قيمته إذا اختلف المستقبلون على هوية المرسل التي يمنحها ذلك الإذن.