مُرحِّل واحد لبريد نطاقين؛ إلى أيهما تعود الرسالة؟

الخلاصة

• ضمت الجداول المشتركة لشبكتي ARPANET وDCNET أكثر من أربعمئة اسم واسم مستعار. اقترح Mills توزيع الأسماء على نطاقات بدل إلزام كل مضيف بحفظ دليل مسطح لكل مضيف آخر.
• يمكن لآلة واحدة تشغيل مُرحِّلات بريد لـ COMSAT وINTELPOST معًا. قد يشير Mills@HOST إلى صندوقين مختلفين، بينما لا يحدد عنوان الآلة أي النطاقين يقصده الرد. كان لا بد من حمل اسم الصندوق كاملًا وسياق النطاق في مسار العودة.

في مكتب بريد متخيل درجَان باسم Mills@HOST. أحدهما لـ COMSAT والآخر لـ INTELPOST، والموظف واحد. إذا نُزعت بطاقة النطاق عن الرسالة، فلن يعالجها عبق الموظف؛ عليه أن يخمن. استعمل D. L. Mills في RFC 799 الصادرة في سبتمبر 1981 نسخة تقنية دقيقة من هذا المأزق. فقد تجاوزت جداول الأسماء والعناوين المشتركة بين ARPANET وDCNET أربعمئة اسم واسم مستعار. تقسيم الدليل بدا معقولًا. أما إبقاء الرسالة والرد مرتبطين بالجزء الصحيح من الدليل فكان الاختبار الحقيقي.

تصور Mills نطاقات أسماء مرتبطة بمؤسسات مثل ARPA وUCL وCOMSAT. يمكن لهذه النطاقات أن تتداخل وأن تترك بعض العناوين خارجها. افترض في التحليل مستوى واحدًا من النطاقات، مع أن الصيغة القياسية للصندوق <user>.<host>@<domain> توحي بثلاث طبقات تُقرأ من اليمين. قد يكفي Mills@COMSAT-DLM داخل COMSAT، أما Mills.COMSAT-DLM@COMSAT فيحمل اسم النطاق إلى خارجها. يمكن لنطاقين أن يستخدمَا اللقب المحلي نفسه؛ الجزء الأخير من العنوان يقول في أي دفتر ينبغي البحث.

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

وجود مكتب توجيه لا يعني مرور كل بريد عبره. توقع Mills أن يسافر معظم البريد مباشرة من المضيف المرسل إلى المضيف المستقبل. يظهر دور الوسيط حين لا يكون الطرفان متصلين في الوقت نفسه، أو يعجز المرسل عن ترجمة الاسم، أو تمنع قيود تنظيمية أو اقتصادية أو أمنية المسار المباشر، أو يستخدم الطرفان بروتوكولين مختلفين مثل TCP وNCP. قد يخزن وسيط عادي الرسالة ثم يرسلها من دون أن يملك جداول الأسماء الكاملة التي يملكها المُوجِّه. ليس كل من يحمل كيس البريد أمينًا على كل دفاتر العناوين.

يعرض النص مسارين: MRCP to:<@COMSAT,Mills@HOST> وMRCP to:<@INTELPOST,Mills@HOST>. يمكن أن يقودا إلى صندوقين مختلفين وإن عمل المُوجِّهان على الحاسوب نفسه. إذا كان اسم الحاسوب FORWARDER في النطاقين، فإن MRCP to:<@FORWARDER,Mills@HOST> يمحو الفرق بينهما. لا يستطيع عنوان الإنترنت الخاص بالحاسوب أن يعيده؛ فهو يحدد الآلة، ولا يحدد الدور الذي أدته لحساب COMSAT أو INTELPOST في هذه الرسالة.

يشتد الإشكال عند الرد. في إجراءات RFC 780 التي ناقشها Mills، يبني المستقبل اسمًا لمسار المرسل من عنوان الإنترنت للمضيف الذي سلّمه الرسالة. إذا كان ذلك المضيف مُوجِّهًا يخدم نطاقين، سيختفي اختيار النطاق من المسار المعاد بناؤه. لذلك دعا Mills إلى تحديث مسار المستقبِل ومسار المرسل معًا: تُنسخ أول خانة من مسار المستقبِل كما وصلت إلى مقدمة مسار العودة. يجب أن يحتفظ الإيصال باسم الشباك الذي مرت به الرسالة، لا بعنوان المبنى وحده.

وبقيت أنظمة البريد القديمة تعتمد أسماء قصيرة. رأى Mills أن تعديل رؤوس RFC 733 طوال الطريق إجراء متطفل يحتاج إلى تحليل واسع. تستطيع الأنظمة الجديدة استعمال الصيغة الكاملة منذ البداية. أما في بريد ARPANET القائم، فيجري التعديل عند أول دخول إلى نظام بريد الإنترنت: يتحول <anything>@<host> المحلي إلى <anything>.<host>@ARPA، ويبقى <anything>@<domain> المعروف كما هو. عند باب الدخول يعرف النظام أصل الاسم المختصر؛ بعد عدة محطات يصبح التخمين عادة سيئة.

أنهى Mills مذكرته بدعوة إلى النقاش. ما لدينا اقتراح من عام 1981، لا تقرير عن تشغيل DNS اللاحق. مع ذلك، كشف مثال الآلة مزدوجة الدور حدًا واضحًا: قد يحدد عنوان من 32 بت المضيف بدقة ولا يحدد صندوق البريد الذي يمثله. أربعمئة اسم جعلت الدليل المسطح ثقيلاً، لكن صندوقين خلف آلة واحدة كشفا لماذا يلزم أن يعرف الرد طريق العودة.