السطر الذي بدا نهاية: كيف جعل SMTP علامة الإنهاء شفافة

الخلاصة

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

كان على قناة واحدة تبديل دورها

يتبادل RFC 821 الأوامر والردود. تحول DATA التدفق مؤقتاً إلى محتوى، ولذلك يجب تحديد موضع انتهاء الرسالة واستئناف الحوار.

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

الشفافية وعد بين الطرفين

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

يتغير الشكل المنقول ثم تعاد الرسالة الأصلية عند التسليم. شدد RFC 821 على قابلية العكس، خصوصاً عبر المرحلات. إذا أهمل طرف دوره انتهت الرسالة مبكراً أو اكتسبت حرفاً.

دخل الاستثناء الصغير كل السلسلة

يحافظ RFC 5321 على القاعدة ويستثني النقطة المضافة من حد 1000 ثمانية للسطر. يجب أن تعرف المخازن والسجلات والمرحلات والاختبارات هل ترى الشكل المخزن أم القياسي أم شكل السلك.

أزال العد السطر المحظور

يعرّف RFC 3030 الأمرين CHUNKING وBDAT. يعلن كل BDAT عدد الثمانيات التالية، وتحدد LAST الكتلة الأخيرة. لا يبحث المستقبل عن علامة داخل المحتوى، فتفقد نقطة السطر سلطتها الخاصة.

ليس بديلاً عاماً: يعلن الخادم القدرة، ويستخدمها العميل بعد الاتفاق، ويبقى DATA مدعوماً. تضاف الآلية من دون إلغاء فهم الأطراف القديمة.

صار العد صاحب القرار

الطول الخاطئ يحرك الحد، فيبتلع مادة داخل الكتلة أو يعرض البيانات لمحلل الأوامر. لذلك يعتمد BINARYMIME على CHUNKING؛ لا تناسب الثمانيات العشوائية علامة DATA المعتمدة على السطور.

لم تختف الثقة، بل انتقلت من تحويل المحتوى إلى الحساب الدقيق والتفاوض السابق.

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

المصادر هي RFC 821 وRFC 5321 وRFC 3030. لا تقيس الانتشار، ويظل DATA مطلوباً. الشفافية ليست تشفيراً أو مصادقة.