الخلاصة

  • لا يجوز للعميل إعلان BODY=8BITMIME وإرسال ثمانيات ذات بت علوي إلا بعد أن يعلن الخادم 8BITMIME في رد EHLO الخاص بتلك الجلسة.
  • قبول الجسم يفرض حفظ كل البتات؛ وإذا كانت القفزة التالية غير قادرة، فعلى المرحّل إنشاء MIME صالح بسبعة بتات من دون فقد، أو تسجيل فشل دائم.

وصف الحمولة لم يوسّع الطريق

منح MIME البريد لغةً لتعريف نوع الوسائط ومجموعة المحارف وترميز النقل. لكنه لم يغيّر طريق SMTP تلقائياً. يفرّق RFC 2045 بين مجالات 7bit و8bit وbinary. قد يكون الجسم موصوفاً وصفاً سليماً، ومع ذلك يحتوي ثمانيات لم يتعهد الخادم التالي بالحفاظ على بتها الأعلى.

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

ثلاثة RFCs ثبّتت وعداً محدوداً

نشر RFC 1426 الامتداد الأول في فبراير 1993. حلّ RFC 1652 محله في يوليو 1994، ثم حلّ RFC 6152 محل RFC 1652 في مارس 2011. يثبت هذا التسلسل تاريخ المعيار، لا نسبة الانتشار الحالية.

يضع الخادم كلمة 8BITMIME في رد EHLO ناجح. يسجل سجل IANA لامتدادات SMTP الكلمة بلا معامل EHLO ويحيل إلى RFC 6152. ولا يضيف الامتداد فعلاً جديداً إلى SMTP.

يستطيع العميل إضافة BODY=7BIT أو BODY=8BITMIME إلى MAIL FROM. يصف BODY مجال ثمانيات الجسم المقبل عبر DATA؛ ولا يحدد لغة أو مجموعة محارف أو نوع وسائط. صلاحية النقل ومعنى المحتوى دليلان مختلفان.

الإذن يخص الاتصال الحاضر

قبل إرسال جسم بثمانية بتات، يجب على العميل الحصول على رد EHLO برمز 250 يتضمن القدرة. إذا غابت، يحظر إرسال ثمانيات خارج نطاق US-ASCII. قدرة TCP على حمل أي بايت، أو نجاح المنتج نفسه بالأمس، لا يعوّضان إعلان الجلسة الراهنة.

يغطي التعهد قفزة واحدة. قد يقبل مرحّل الرسالة ثم يجد أن الخادم التالي لا يعلن 8BITMIME. لا يتحدث الإعلان الأول باسم الثاني، ولا يضمن أن تطبيق المستلم سيعرض المحارف كما ينبغي.

القبول كان عهدة لكل بت

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

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

ثمانية بتات لا تعني ثنائياً اعتباطياً

يحتفظ DATA ببنية الأسطر وشفافية النقطة. السطر الذي يحوي نقطة وحدها ينهي النقل، والنقاط في بداية الأسطر ما زالت تضاعف. وتبقى حدود طول السطر؛ يسمح RFC 6152 بخادم لا يضمن أكثر من 1,000 ثمانية، بما فيها CRLF، في السطر الواحد.

لذلك يدعم 8BITMIME ترميز MIME المسمى 8bit، لا binary. وسّع القيم المسموح بها داخل السطر من دون إلغاء السطر. عالج CHUNKING وBINARYMIME لاحقاً مشكلة تأطير أخرى.

القفزة التالية تعيد فتح القرار

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

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

الإعلان نظّم سلسلة الدليل

BODY=8BITMIME قول للعميل، وليس حقيقة سحرية. تحتاج العمليات إلى فصل ما أعلنه النظير، وما صرّح به العميل، وما ظهر فعلاً في الجسم، وما حدث عند الحد التالي. بهذه السلسلة يمكن تمييز خطأ المرسل عن تحويل خطر أو فقد داخلي أو عطل عرض.

كان الإنجاز الدائم تحديد نطاق السلطة. يصف MIME الحمولة؛ ويقول اتصال SMTP هل يقبل هذا الحارس تمثيلها؛ ثم يسأل الاتصال التالي السؤال من جديد.

المصادر وحدودها

يأتي التسلسل من RFC 1426 وRFC 1652 وRFC 6152. يعرّف RFC 2045 مجالات MIME، ويحفظ سجل IANA القيد الحالي. لا تقيس هذه المصادر الانتشار أو الحجم أو تواتر التحويل اليوم.