الخلاصة

  • سمح RFC 3516 لخادم IMAP بإزالة Content-Transfer-Encoding من مقطع MIME وإرجاع البايتات المفكوكة عبر BINARY، بما في ذلك NUL داخل literal8. كانت النتيجة عرضاً مشتقاً، لا تسلسل الرسالة الأصلي.
  • انتمى الحجم والإزاحة الجزئية إلى البيانات بعد الفك. أما التخزين وFETCH BODY ونهايات CRLF والرؤوس المرمّزة وحدود التحقق التشفيري فظلت أدلة منفصلة.

حلّ base64 مشكلة نقل بيانات اعتباطية عبر أنظمة بريد لا تحفظ كل البايتات. لكنه جعل عميل IMAP ينزّل أحياناً تمثيلاً أكبر كي يفكّه فور وصوله. رأى RFC 3516 أن هذه الزيادة مؤثرة في الوصلات اللاسلكية البطيئة وفي الوسائط المتدفقة.

نقلت الإضافة المنشورة في أبريل 2003 عملية الفك إلى الخادم. عندما يعلن الخادم BINARY في CAPABILITY، يستطيع العميل طلب FETCH BINARY، فيزيل الخادم ترميز النقل عن مقطع MIME المحدد ويرسل الناتج. خفّض ذلك الحركة والحساب، لكنه لم يحوّل الناتج إلى بايتات الرسالة كما استُقبلت أول مرة.

لكل مقطع متن في IMAP ترميز نقل MIME، مكتوب أو مفترض بقيمة 7bit. يحدد CTE في MIME خوارزمية الفك ومجال البيانات الناتجة. يغيّر base64 وquoted-printable شكل السلسلة. وقد لا يغيّر ترميز الهوية القيم، لكنه قد يعلن مجالاً لا يستطيع literal الأساسي تمثيله، مثل وجود NUL.

لذلك فصل RFC عمل الخادم إلى خطوتين منطقيتين: تنفيذ الفك المرتبط بـ CTE، ثم تحديد مجال البايتات الناتجة. الحصول على بايتات لا يكفي لاختيار عنصر البروتوكول الذي يحملها.

أدخل literal8 للمجال الأوسع. تبدأ الصيغة بعلامة tilde وعدد، ثم تسمح ببايتات اعتباطية تشمل NUL. إذا بقيت البيانات في مجال ثمانية بتات من دون NUL، فينبغي للخادم استخدام string عادية. وهكذا يعرف العميل المجال من الغلاف من دون فحص التدفق كاملاً.

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

فصل BINARY.PEEK حالة صندوق البريد. فهو يعيد العرض نفسه من دون تعيين \\Seen ضمناً. بقاء الرسالة غير مقروءة ضمان صحيح، لكنه لا يثبت أصل البايتات. ما عاد إلى العميل ما زال عرضاً أنشأه الخادم بعد الفك.

يعطي BINARY.SIZE طول المقطع بعد إزالة CTE، أي عدد البايتات المتوقع من طلب BINARY المقابل. لا يعطي طول المتن المرمز ولا مساحة التخزين ولا حجم الرسالة الكاملة. وحذر RFC من أن الحساب قد يكون مكلفاً إذا اضطر الخادم إلى فك المقطع كله لمجرد العد.

تعمل الطلبات الجزئية في إحداثيات البيانات المفكوكة. لا تشير إزاحة داخل نص base64 أو نتيجة FETCH BODY بالضرورة إلى الموضع نفسه. وقد يؤدي استخدام عداد استئناف من تمثيل آخر إلى مقطع صحيح نحوياً لكنه يبدأ من مكان منطقي خاطئ.

إذا لم يعرف الخادم CTE، مُنع من التخمين. يجب أن يفشل BINARY وBINARY.SIZE برد NO [UNKNOWN-CTE]. يثبت الرد عجز هذا الخادم عن التحويل المسمى، ولا يثبت تلقائياً فساد الرسالة.

حدّث RFC 4466 لاحقاً إطار رموز استجابة IMAP، وأدخل RFC 9051 آليات binary ضمن IMAP4rev2. تؤثر هذه الطبقات في تفسير الآثار الحديثة، لكنها لم تجعل الشكل المرمز والمقطع المفكوك والتمثيل المخزن سلسلة واحدة.

ترميز الرؤوس طبقة أخرى. تسمح encoded-words في RFC 2047 بنص غير ASCII في مواضع محددة من الرؤوس، لكنها ليست CTE لمتن MIME. لذلك منع RFC 3516 تحويلها استجابةً لـ BINARY FETCH أو APPEND. طلب فك متن لا يمنح حق إعادة كتابة كل ما يبدو مرمزاً.

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

صرحت الوثيقة بحد التخزين. يستطيع الخادم حفظ المحتوى الثنائي من دون ترميز، ومع ذلك يجب أن تصف BODYSTRUCTURE الرسالة كما لو استخدمت CTE يقبله IMAP الأساسي، وأن يعيد FETCH BODY الشكل الموصوف. الواجهة عقد تشغيل مشترك، لا كشف مباشر للذاكرة.

يسير APPEND في الاتجاه المقابل. يستطيع العميل إضافة literal8 يحوي NUL. إذا عجز صندوق الوجهة عن التخزين الثنائي وجب رفض الطلب بـ UNKNOWN-CTE. وإذا استطاع، جاز للخادم تغيير CTE بشرط ألا تفقد الحمولة بيانات.

عدم فقدان الحمولة لا يعني ثبات الرسالة المتسلسلة. قد يمثل base64 وquoted-printable والشكل المباشر المحتوى نفسه ببايتات مختلفة. يدخل اسم CTE وطيّ الرؤوس ونهايات الأسطر في التسلسل. ولذلك قد يبطل تحويل أمين للمحتوى تجزئةً أو توقيعاً محسوباً على ذلك التسلسل.

حذر RFC نفسه من أن تغيير الترميز بلا ضرورة يجعل معظم العمليات التشفيرية المنفذة على الرسالة غير نافعة. لا تعارض بين القاعدتين: إحداهما تحمي استعادة المحتوى، والأخرى تعتمد على بايتات ورؤوس دقيقة. عبارة «من دون فقد» لا تسجل مدخلات أداة التحقق.

ولم تعف الإضافة العميل من فهم MIME. كانت تحسيناً لحالات معينة، لا صيغة تخزين عالمية. أوصى RFC بأن يبقى العميل قادراً على فك CTE بنفسه. إعلان capability طريق سريع، لا مبرر لإلغاء الطريق العادي.

يساعد فصل Heng Lu بين الواقع الرمزي والتشغيلي في ترتيب الأدلة. BINARY داخل CAPABILITY إعلان قدرة. BINARY.SIZE وعد بطول عرض واحد. literal المعدود تسلسل ملاحظ على اتصال. بايتات التخزين ورسالة RFC 5322 وحمولة MIME والعرض ومدخلات التوقيع طبقات مترابطة لا تحل إحداها محل الأخرى.

تبدأ سلسلة إيصالات كافية بمعرف الرسالة وسياق القراءة، ثم تحفظ BODYSTRUCTURE والمقطع وCTE والأمر وأثر \\Seen ورمز الرد والمجال والطول والإزاحة وتجزئة البايتات المعادة. إن كانت هوية الرسالة مهمة، تحفظ قراءة raw مستقلة وتجزئتها. وإن كان التوقيع مهماً، تسجل canonicalization والتسلسل الدقيق الذي قرأه المدقق.

عندئذ لا تتعارض حقيقتان: أعاد الخادم المتن المفكوك بصورة صحيحة، ومع ذلك لم تطابق تجزئة الملف تجزئة الرسالة المتسلسلة. عرّف RFC 3516 التحويل بينهما ولم يَعِد بمحو الفرق.

كان الإنجاز التاريخي عملياً: لم يعد المحتوى الثنائي يدفع في كل قراءة IMAP كلفة ترميز صُمم لمسار آخر. أما الدرس الأعمق فهو ضبط الادعاء. فكّ الخادم المتن وحصل العميل على بايتات مفيدة؛ وظلت الرسالة الأصلية محتاجة إلى قراءة وتجزئة وإثبات خاص بها.

المصادر