الخلاصة

  • تنص الفقرة 6.5 من draft-ietf-emailcore-as-30 على أن تكون تطبيقات استقبال SMTP قادرة على قبول البريد مع سرية النقل أو من دونها، ثم تترك تصرف المرسل أو المستقبل في ظرف معين للسياسة المحلية. الوثيقة ما زالت مسودة إنترنت في مرحلة «AD Followup»، وليست RFC منشورة.
  • كانت النسخة 29 تقول إن على المستقبلين ألا يشترطوا السرية على المرسلين. يناقش مشاركون في سبتمبر جدوى تحويل العبارة إلى متطلب لقدرة التنفيذ وحدوده؛ ولا تثبت المراسلات المنشورة قراراً نهائياً من IESG أو سلوك جميع المشغّلين.

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

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

ما زال مسار الاعتماد مفتوحاً. تسجل صفحة Datatracker النسخة 30 وثيقة نشطة في حالة «AD Followup»، وتظهر ورقة التصويت اعتراضات DISCUSS، بعضها قُدم على النسخة السابقة وبعضها يتناول مسائل أخرى. في 18 سبتمبر بيّن المحرر John Klensin، رداً على Roman Danyliw، أن أجزاء من شرحه رأي شخصي لم يُعرض بعد على مجموعة العمل. وفي 28 سبتمبر تساءل Eric Rescorla عن إبقاء مطلب إلزامي إن كان المدافعون عنه يعدّونه بلا أثر إضافي؛ وشدد Rob Sayre على الفرق بين قدرة التنفيذ واختيار المشغّل، مع توقع اتساع سياسات اشتراط TLS. هذه مواقف أصحابها، لا إجماع IETF ولا مسح ميداني لتهيئة خوادم البريد.

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

ولا يحل RFC 8689 هذا الخلاف. تتيح آلية REQUIRETLS لرسالة معينة أن تحمل شرطاً للسرية عبر المرحّلات الداعمة، فتفشل بدلاً من الرجوع إلى النقل غير المشفر. غطّى BTW هذا الخيار من منظور الرسالة نفسها. أما السؤال الحالي فهو عن الإمكانات التي ينبغي أن تبقى في برنامج الاستقبال عموماً. شرط الرسالة، وقاعدة خادم البريد العام، وقدرة المنتج، وقرار المشغّل عند الاتصال ليست تعبيرات متبادلة عن سياسة واحدة.

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

المصادر