الخلاصة

  • تنشئ RFC 5364 من قائمة URI موسعة سجلاً مختلفاً لكل مستلم. غياب copyControl يعني bcc؛ وتختفي النسخ العمياء من سجلات الآخرين، بينما قد يبقى من الإدخالات المجهولة عنوان بديل وعدد فقط.
  • يفترض أن ينتج URI المكرر طلباً واحداً على الأكثر، وتُحسم الفئة وفق to ثم cc ثم bcc. كما تتقدم bcc على anonymize، لذلك تحتاج المطابقة وقرارات الإفصاح إلى إيصالات منفصلة.
  • جزء recipient-list-history اختياري للتوافق، ولا يثبت وجود العنوان أو إمكان الوصول إليه أو القبول أو المشاركة أو الفوترة. حماية النقل تحفظ الحيازة ولا تمنح الإسقاط حقيقة أو اكتمالاً.

القائمة تصف الإفصاح لا الواقع

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

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

لا تصلح القائمة وحدها للفوترة أيضاً. الدعوة ليست استهلاكاً، وإنشاء الطلب ليس قبولاً، والسطر الظاهر لا يقيس مدة أو مورداً أو مسؤولية مالية.

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

يجب حفظ نتائج لاحقة مستقلة: الطلب الخارج، جواب endpoint، الانضمام الموثق، حركة الوسائط، المدة، استخدام الموارد وحدث الفوترة. يجوز ربطها، لكن لا يجوز استبدالها بعضوية قائمة.

السؤال الذي يجيب عنه التاريخ هو: «ما صورة الإفصاح التي رافقت هذا الطلب؟» لا: «من كان حاضراً؟».

كل مستلم يرى إسقاطاً مختلفاً

الوثيقة الأصلية مدخل للتنفيذ، وليست نصاً مشتركاً يرسل إلى الجميع. بعد التوسيع وحل التعارضات، يصنع relay جزء recipient-list-history لكل طلب خارج.

قد تبقى عناصر to وcc مرئية. أما bcc فتُحذف من نسخ الآخرين. ويمكن أن تتضمن النسخة المرسلة إلى المستلم الأعمى URI الخاص به وحده كي يعرف أن الرد على الجميع قد يكشفه.

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

اربط hash القائمة الأصلية بنتيجة التوسيع، ثم بالتصنيف المحسوم، ومعرف الطلب الخارج وhash التاريخ الخاص به. إن اختزال ذلك كله إلى جدول مستلمين واحد يمحو الدليل على من رأى مَن.

لمنشئ القائمة سلطة طلب العملية، وللوسيط مسؤولية تنفيذ الإفصاح، ولا يحصل المستلم إلا على المشهد المسموح له. هذه سلطات منفصلة.

الحقل الغائب يتحول إلى bcc

إذا غابت سمة copyControl، فالقيمة الافتراضية هي bcc. لا تمنح قائمة قديمة أو أداة لا تعرف الامتداد أو عملية ترحيل ناقصة إذناً بعرض العنوان.

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

احتفظ ببايتات XML وhash، وإصدار schema، ووجود السمة أو غيابها، وإصدار parser، وقاعدة القيمة الافتراضية والفئة النهائية. إذا ملأت مرحلة التطبيع الحقل ثم محَت أثر الغياب، تضيع إشارة مهمة إلى جودة المصدر.

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

الإخفاء الكامل ليس كإخفاء الهوية

تزيل bcc الإدخال من سجلات المستلمين الآخرين. أما anonymize=true فيمكن أن يستبدل URI الحقيقي بعلامة SIP المجهولة التي تحددها المواصفة، مع count يمثل عدة إدخالات.

تختفي الهوية، لكن يبقى الوجود وربما العدد. معرفة أن هناك خمسة مستلمين مجهولين قد تؤثر في تفاوض أو اجتماع حساس، حتى من دون اسم واحد.

إذا اجتمعت bcc وanonymize، تتقدم bcc. إخراج placeholder مجهول في هذه الحالة يكشف وجوداً كان يفترض أن يظل محجوباً.

اختبر تسرب الهوية وتسرب العدد كلّاً على حدة. وسجل السمات الأصلية وقاعدة الأولوية ومجموعة المحذوفين والمجموعة المجهولة والعدد والجسم النهائي.

وصف كل هذه الحالات بكلمة «خاص» في واجهة المستخدم يخفي الفرق الجوهري بين عدم معرفة الاسم ومعرفة أن شخصاً ما موجود.

URI المكرر قد يحمل نيتين متعارضتين

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

ترى RFC 5364 أنه لا يوجد استعمال معقول لإرسال طلبات متعددة إلى المستلم نفسه. ينبغي إرسال طلب واحد على الأكثر. وعند اختلاف الفئات، تتقدم to ثم cc ثم bcc.

الاحتفاظ بأول صف يجعل المعنى رهناً بالترتيب. والإرسال مرتين قد يمنح terminal نفسه تاريخين متناقضين. إزالة التكرار هنا قرار إفصاح، لا تنظيف محايد للبيانات.

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

يعالج مقال RFC 5363 المنشور التوسيع العام والتضخيم والنتائج الجزئية. أما هذه المقالة فتملك السؤال الأضيق: أي نية رؤية تبقى عندما تشير الإدخالات إلى الهوية نفسها؟

الرد على الجميع قد يفضح المستلم الأعمى

يمكن للوسيط أن يطبق bcc بصورة صحيحة ثم يفشل السر في endpoint. فإذا استخدم المستلم الأعمى «الرد على الجميع»، قد يضيف عنوانه إلى الرسالة الجديدة ويكشف نفسه للمجموعة.

لهذا توجّه RFC العميل إلى منع الرد الجماعي أو تقييده حين لا يظهر URI الخاص بالمستلم في التاريخ أو يظهر كنسخة عمياء.

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

احفظ الجسم المستلم، ونتيجة parser، والهوية المحلية المختارة، ونتيجة المطابقة، وحالة الزر والعناوين التي خرجت فعلاً. نجاح server في الحجب ليس إثباتاً لنجاح terminal.

تنتهي التجربة عند الرسالة الصادرة، لا عند لقطة شاشة لواجهة تبدو آمنة.

قد يصل الطلب ويُهمَل التاريخ

يحمل الجزء disposition باسم recipient-list-history ويفترض أن يكون handling=optional. وبذلك يستطيع عميل قديم قبول طلب SIP الرئيسي وإهمال multipart الذي لا يفهمه.

قبول الطلب واستهلاك التاريخ نتيجتان منفصلتان. قول «سُلّم مع التاريخ» قد يعني فقط أن relay أرفق بايتات؛ ولا يثبت الحفظ أو التحليل أو العرض أو استخدام التاريخ في سياسة الرد.

احتفظ ببناء MIME وboundary وdisposition والمعامل وقدرة endpoint ونتيجة التحليل والعرض وfallback. إسقاط الجزء المسموح به يجب أن يكون حدثاً مرئياً.

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

TLS وS/MIME يثبتان أمراً آخر

تكشف قوائم المستلمين علاقات حساسة. لذلك تفيد المصادقة والتفويض وTLS وS/MIME في حصر الوصول وحماية hop أو المحتوى وفق نموذج كل منها.

لكنها لا تثبت أن relay قرأ الإصدار الصحيح، أو قارن URI بصورة صحيحة، أو طبق الأولويات، أو حسب العدد بدقة، أو عرض endpoint التاريخ كما ينبغي.

سجل peer والشهادة أو المفتاح ونتيجة التحقق ونطاق الحماية. وبصورة مستقلة، سجل hash الإدخال وإصدار محرك التحويل والقواعد وhash كل إسقاط.

يمكن لقناة آمنة أن تنقل إسقاطاً خاطئاً بأمانة كاملة. سلامة الطريق لا تمنح المحتوى اكتمالاً أو حقيقة.

دفتر الإسقاط يحتفظ بما لم يظهر أيضاً

تجمد الطبقة الأولى principal المرسل والتفويض وXML وسياق الطلب. وتسجل الثانية رسم التوسيع، والثالثة مقارنة URI ومجموعات التصادم.

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

ثم تأتي إيصالات terminal والعالم الفعلي: معالجة الجزء الاختياري، العرض، منع الرد الجماعي، نتيجة التسليم، المشاركة والفوترة.

حفظ الإسقاط وحده لا يثبت ما حُجب. وحفظ القائمة الأم وحدها لا يثبت ما كُشف. يلزم الطرفان وسلسلة التحويل بينهما.

الاختبار يقارن البايتات لكل مراقب

ينبغي أن تشمل fixtures سمة غائبة، وto وcc وbcc، وإخفاء هوية مفرداً ومجمعاً، واجتماع blind مع anonymize، وURI متكافئة بسمات متعارضة، ونسخة المستلم الأعمى نفسه، ونسخة المستلم المرئي، وعميلاً يهمل الجزء الاختياري.

لكل حالة، تحقق من عدد الطلبات ومن بايتات كل تاريخ. ثم اختبر التعرف إلى URI الذاتي والعرض ومنع الرد. وأخيراً تأكد من أن أنظمة الحضور والفوترة لا تستخدم عضوية التاريخ بدلاً من الحدث الحقيقي.

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

نشر RFC 5364 في أكتوبر 2008 بصفة Proposed Standard وعدم ظهور نتيجة مطابقة في صفحة errata الملتقطة حقيقتان وثائقيتان فقط. لا تثبتان اعتماد منتج حالي أو حادثة واقعية.