المستقبِل الذي اختار ما يأتي أولاً

الخلاصة

• عرّف RFC 772 وRFC 780 نمط R للمستلمين أولاً ونمط T للنص أولاً. يقترح المرسل، لكن المستقبِل يحدد ما يستطيع تشغيله.
• يكشف MRSQ القدرة ويختار ويعيد ضبط الحالة. ويعالج MRCP مستلماً، غير أن نجاحه يعني حفظ الاسم في R وتطبيق نص محفوظ في T.
• استبدل RFC 788 وRFC 821 المسارين بـMAIL ثم RCPT واحد أو أكثر ثم DATA. بقيت كفاءة مشاركة النص، واختفت ازدواجية الحوار الخارجي.

سؤال يغيّر الحالة التي يسأل عنها

في RFC 780، يطلب MRSQ ? تفضيل R أو T. ويعيد MRSQ بلا وسيط إلى حالة «لا نمط» ويؤكد وجود الميزة. ويمكن للمستقبِل رفض نمط معين لا يستطيع استخدامه.

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

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

R يحتفظ بالأسماء قبل النص

في recipients-first، يرسل الطرف الأول عدة أوامر MRCP TO:<path>. يجيب المستقبِل على كل اسم ويحفظ المقبولين. رفض عنوان لا يلغي ما سبقه أو ما يمكن قبوله بعده.

بعد القائمة، ينقل MAIL FROM:<sender-path> بلا TO نصاً واحداً. النجاح النهائي يشمل المجموعة المحفوظة، والفشل النهائي يُعامل كفشل للمجموعة. ثم تُمسح القائمة.

يناسب ذلك نظاماً يجمع الأسماء والنص في حزمة واحدة لمكوّن مركزي. لا يعبر المحتوى السلك لكل شخص.

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

T يحتفظ بالنص قبل الأسماء

في text-first، يصل MAIL بلا مستلم ويحفظ النص. بعد ذلك يطبق كل MRCP النسخة المحفوظة على عنوان واحد ويعيد نتيجة منفصلة، من دون إعادة نقل المحتوى.

يبقى النص حتى يستبدله MAIL آخر أو يمحوه MRSQ. يحقق T الهدف نفسه لكنه يختار النص، لا جدول الأسماء، كحالة دائمة.

هذا مفيد للتسليم التدريجي. يمكن أن يظهر امتلاء صندوق أو تعارض وصول في نتيجة المستلم نفسه.

لكن النص يُقبل قبل معرفة وجود عنوان صالح. وMRCP قبل تخزين النص يشبه محاولة رسالة فارغة وقد تقبله بعض التطبيقات أو ترفضه. المعنى يتبع ترتيب الحالة.

لا يُفهم الرد من دون النمط

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

يزيد reset الخطر. يمحو MRSQ الحالة، وMAIL العادي ذو الوجهة يعيدها أيضاً. حذف سطر واحد من السجل قد يربط MRCP بنص أو قائمة لم تعد موجودة.

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

المستقبِل يملك معرفة الورشة

يشرح RFC 780 أن R يخدم نظاماً يسلم معلومات مكتملة إلى mailer مركزي، بينما يناسب T نظاماً يعالج شخصاً بعد شخص ويرجع قيود كل صندوق.

لا يرى المرسل هذه البنية. يطلب كفاءة، لكنه لا يعرف جدول الطرف الآخر أو مخزنه. من يدفع تكلفة الذاكرة ويتحمل الفشل يحدد النمط الممكن.

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

جعل SMTP الترتيب الخارجي واحداً

حدد RFC 788 ثلاث مراحل: يبدأ MAIL FROM ويعرّف المرسل، وتتفاوض أوامر RCPT TO المتكررة على المستلمين، ثم يحمل DATA النص. الحوار lock-step ويجب اتباع الترتيب.

لا يظهر MRSQ ولا MRCP البريدي. لا يستطيع المستقبِل طلب النص أولاً. رفض RCPT يخص ذلك العنوان ولا يلغي بالضرورة الباقين.

حافظ RFC 821 على البنية. لا تفرض أن تكون طوابير الخوادم متطابقة؛ تفرض فقط ما يراه الطرفان على السلك.

يستطيع الخادم أن يغير معالجة الدفعات داخلياً من دون أن يعلّم جميع العملاء حواراً آخر. فقد اختيار الترتيب الخارجي، لا حرية التنفيذ.

استمر نص واحد لعدة أشخاص

كان هدف R وT تجنب إعادة نقل المحتوى لكل عنوان. أبقى SMTP الهدف في تسلسل واحد: MAIL واحد، RCPT متعددة، DATA واحدة.

يشجع RFC 788 وRFC 821 نسخة بيانات واحدة للمستلمين في المضيف نفسه. ويؤكد RFC 1123 استعمال RCPT, RCPT, ... RCPT, DATA بدلاً من تكرار RCPT, DATA.

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

تقليل الانتظار لا يعيد T

يخلق lock-step زمناً لانتظار الردود. يسمح PIPELINING اللاحق بإرسال أوامر مسموحة قبل وصول كل رد، لكنه لا يضع DATA قبل RCPT.

كان MRSQ T يغير الحالة الموجودة أولاً. يغير PIPELINING توقيت بايتات مرتبة أصلاً. السرعة ليست ترتيباً سببياً جديداً.

يفصل ذلك هذا الموضوع عن تاريخ PIPELINING ويمنع قراءة الالتقاط المتقارب كأنه انعكاس للمعاملة.

بقي الإطار الحديث ثابتاً

يحافظ RFC 5321 على MAIL ثم RCPT واحد أو أكثر ثم DATA. تضيف الامتدادات معاملات وقدرات، ولا تعيد اختيار R/T.

يمكن للخوادم داخلياً التحقق في أوقات مختلفة أو تمرير العمل إلى طابور آخر. الواجهة الموحدة تحصر الاختلافات خلف الحدود ولا تحولها إلى عبء على كل مرسل.

تبسيط الحالة المشتركة لا يعلن أن T كان خطأ. إنه ينقل تحسيناً مشروعاً إلى مكان يمكن تغييره بلا تنسيق شامل.

MRCP آخر لا علاقة له بالبريد

MRCP هنا أمر Mail Recipient في MTP. أما Media Resource Control Protocol اللاحق الخاص بموارد الكلام فلا يرث الآلية.

ينبغي أن تقرن عمليات البحث MRCP بـMRSQ أو mail أو RFC 772/780. تساوي الحروف ليس سلسلة نسب.

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

يعتمد المقال على RFC 772 و780 و788 و821 و1123 و5321. تثبت الأنماط والضبط والسلطة وحدود الموارد وترتيب SMTP والكفاءة المستمرة.

لا تقدم تعداداً للتطبيقات أو اجتماعاً واحداً أنهى الآلية أو مكسباً عاماً. يتوقف RFC 788 عن تعريف MRSQ/MRCP ويحدد تسلسلاً آخر.

R ليس تسليماً ذرياً، وT لا يعيد النص لكل مستلم. الفرق في موضع الحالة ووقت قوة الدليل.