أعلن الخادم عن قدرة، لكن المصادقة غيّرت الإجابة: RFC 2449

الخلاصة

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

يبدو سؤال «ماذا يستطيع هذا الخادم أن يفعل؟» مفرداً، لكن جواب POP3 كان يتبدل بحسب السياق. اختلفت الأوامر الاختيارية وآليات المصادقة وسلوكيات الخوادم، بينما تعلم العملاء عنها غالباً بتجربة الأوامر أو تفسير رسائل موجهة للبشر أو مطالبة المستخدم بتغيير إعدادات التوافق. نُشر RFC 2449 في نوفمبر 1998 ضمن مسار المعايير تحديثاً لـ RFC 1939، وأضاف CAPA ليحصل العميل على قائمة قابلة للتحليل قبل اختيار امتداد.

لم تتحول القائمة إلى ملف تعريف دائم للخادم. يتاح CAPA في حالة AUTHORIZATION قبل تسجيل الدخول وفي حالة TRANSACTION بعد المصادقة. ويجب أن يحدد وصف كل قدرة الحالات التي تُعلن فيها والحالات التي تصح فيها أوامرها. فالقدرة المتاحة قبل المصادقة يجب أن تُعلن في الحالتين، لكن معاملاتِها قد تصبح أدق بعد معرفة المستخدم. الاسم والقيمة والفعل الذي تتيحه حقائق مترابطة وليست حقيقة واحدة.

يوضح LOGIN-DELAY وEXPIRE سبب التحفظ. إذا اختلف LOGIN-DELAY بين الحسابات، فعلى الخادم قبل المصادقة إعلان أكبر فترة انتظار ممكنة، ثم ينبغي له بعد ذلك إعطاء المستخدم قيمة أدق. أما EXPIRE فيعني الحد الأدنى المضمون لمدة الاحتفاظ، لا موعد حذف رسالة بعينها. وإذا اختلفت السياسة بحسب المستخدم، وجب أن تكون القيمة قبل المصادقة أقصر مدة ممكنة، ثم يقدّم الخادم قيمة أكثر دقة بعد الدخول. فالإجابة العامة تحمي من الوعد بمعاملة أفضل مما يستطيع الخادم ضمانه.

قد تغيّر المصادقة أيضاً السياق الأمني. يوصي RFC 2449 بإعادة طلب CAPA إذا تفاوضت المصادقة على طبقة لحماية التكامل، بغرض كشف خفض نشط للمستوى. ثم أوضح RFC 5034 الحدّ بالنسبة إلى طبقات أمان SASL: ينبغي للعميل إسقاط معلومات الخادم التي تعلّمها سابقاً، بما فيها قائمة القدرات القديمة. فما جُمع خارج السياق المحمي لا يتحول تلقائياً إلى دليل داخله.

حتى القائمة الإيجابية لا تضمن أن كل مستخدم يستطيع تنفيذ كل إجراء. فوسم USER يعلن دعم USER وPASS، لكن RFC 2449 ينبه إلى أنهما قد لا يتاحان للجميع. وقد تفشل آلية SASL المعلنة بسبب بيانات الاعتماد أو السياسة المحلية؛ وقد ينجح الدخول من دون الحصول على صندوق البريد. وإذا ردّ CAPA بـ -ERR، فهذا يعني أن أمر الاكتشاف غير منفذ وعلى العميل العودة إلى التجربة السابقة. تقلل الآلية الجديدة التخمين لكنها لا تمحو عدم اليقين الموروث.

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

لم يكن إسهام RFC 2449 وعداً بقابلية تبادل خوادم POP3 أو إعلاناً بانتهاء التجربة. بل رسم حدود ما يمكن للخادم ادعاؤه، وفي أي حالة، ووفق قواعد كل امتداد. توجه القائمة القرار التالي؛ أما معرفة ما حدث فعلاً فتحتاج إلى الأمر التالي وردّه ثم ملاحظة لاحقة لصندوق البريد. ولا تثبت صفة RFC أو قيد في سجل IANA التنفيذ أو الانتشار الشامل.

المصادر

RFC 2449؛ سجل RFC 2449؛ تصويبات RFC 2449؛ RFC 1939؛ RFC 1957؛ RFC 5034؛ RFC 1734؛ RFC 4422؛ سجل IANA لامتدادات POP3؛ RFC 2384؛ Heng Lu، أولوية الشيفرة العاملة؛ Heng Lu، المواصفة الأولية الدنيا والتبني الطوعي.