الخلاصة

  • نُشرت draft-ietf-mailmaint-smtputf8-syntax-05 في 10 سبتمبر 2026، واستبدلت تعداد فئات المحارف بإحالة إلى IdentifierClass في PRECIS، مع إلزام تطبيق قاعدة السياق حيث تكون مطلوبة.
  • تضيف المراجعة مثالين مرفوضين: U+3164 HANGUL FILLER الذي قد يظهر بلا أثر، وU+0640 ARABIC TATWEEL الذي يطيل الحرف السابق ويتيح صيغاً بصرية كثيرة.
  • نجاح اختبار الصياغة لا يثبت وجود صندوق البريد أو سيطرة صاحبه أو هويته، ولا يثبت اكتمال مسار SMTPUTF8 أو وصول الرسالة.
  • بقي في النص تعارض حرفي بين مسافة موضوعة بين علامتي اقتباس وعلامات الترقيم المستخدمة في العنوان. يجب توضيحه في مسودة لاحقة بدل أن تصلحه التطبيقات سراً بطرق مختلفة.

أثر موجود في البايتات وغائب عن الشاشة

تبدأ الحادثة كتذكرة دعم عادية. التسجيل نجح، لكن استعادة الحساب لا تجد العنوان. يعرض الموظف السلسلتين ولا يرى فرقاً. عند تفكيكهما إلى نقاط ترميز يظهر U+3164 قبل الفاصل في إحداهما؛ لا يمنحه الخط مساحة مرئية، لكنه يظل جزءاً من دخل UTF-8.

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

تضيف المراجعة 05 من SMTPUTF8 Email Addresses هذا المثال وتجعله غير مسموح. كما تضيف U+0640 ARABIC TATWEEL. يندرج التطويل ضمن فئة الحروف العامة في Unicode، لكنه يمد الحرف العربي السابق؛ ويمكن لتكراره أن ينتج سلاسل متعددة ذات مظهر متقارب.

يسجل Datatracker الوثيقة كمسودة نشطة لمجموعة Mail Maintenance وهدفها Proposed Standard. ويثبت السجل التاريخي صدور المراجعة في 10 سبتمبر. لا تعني هذه الحالة أنها RFC أو أن IETF اعتمدها، ولا تثبت تنفيذاً أو حادثة.

من قائمة محلية إلى إجراء مرجعي

كانت المراجعة 04 تعدد الفئات A وH وK وبعض عناصر F في RFC 8264، إضافة إلى علامات بنية العنوان. أما 05 فتسمح فقط بما يعتبره IdentifierClass صالحاً، وتشترط اجتياز قاعدة السياق عندما يطلبها التصنيف.

الإحالة هنا ليست اختصاراً لغوياً فحسب. RFC 8264 يعطي أربع نتائج: صالح، يحتاج إلى قاعدة سياق، غير مسموح، وغير مخصص. بعض علامات الوصل لا تُحكم من فئتها وحدها؛ فالمحارف المجاورة جزء من الاختبار.

صُمم IdentifierClass للسلاسل التي تعرّف كياناً شبكياً أو تعنونه، ويقدم السلامة على سعة التعبير. يسمح بالحروف والأرقام التقليدية وASCII القابل للطباعة ضمن قواعده، ويستبعد Jamo الكورية القديمة ومحارف التحكم والخصائص المهملة والمسافات وأشكال التوافق وفئات أخرى.

ومع ذلك لا يحدد PRECIS كل سياسة التطبيق. يجب على profile المعتمد أن يوضح تحويل العرض، والتحويلات الإضافية، وحالة الحروف، والتطبيع، والاتجاه. المرجع المشترك يرسم بداية القرار المحلي ولا يلغيها.

لماذا لا تكفي عبارة «هذا حرف»

يضع RFC 5892 U+0640 في جدول استثناءات صريح ويعطيه DISALLOWED، مع أن حساب الخصائص العام كان سيمنحه PVALID. لذلك لا تكفي فئة Unicode العامة لإثبات نتيجة القبول.

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

أما القاعدة الثالثة فتحظر وجود أكثر من script غير ASCII في العنوان بعد تجاهل ASCII في العد. يعرّف Unicode Standard Annex #24 خاصية Script المقصودة. هذا حد مقترح لتشغيل المعرّف، وليس حكماً على مشروعية أسماء الأشخاص متعددي اللغات.

المسافة المقتبسة ما زالت سؤالاً

تقول القاعدة الثانية حرفياً إن العنوان يضم نقاطاً صالحة وفق IdentifierClass و«مسافة» بين علامتي اقتباس. ثم تذكر الأمثلة النقطة والشرطة المائلة وعلامة at بصورة منفصلة. ويحمل مصدر المؤلفين العبارة نفسها.

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

إذا اختار المنفذ تفسيراً مؤقتاً فعليه تسجيل رقم المسودة والافتراض وحالة الاختبار. التصحيح الصامت قد ينتج برنامجاً يعمل، لكنه لا ينتج توافقاً قابلاً للمقارنة.

القبول لا يمنح الهوية

يسمح RFC 6532 باستخدام UTF-8 مباشرة في رؤوس البريد الدولي وعناوينه. تحاول المسودة الجديدة تضييق السلاسل إلى ما هو أكثر قابلية للتشغيل البيني. ولا تصادق أي من الطبقتين على الشخص.

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

تناولت مادة BTW التاريخية السابقة حفظ الجزء المحلي الدولي عبر مسار البريد وعدم وجود تخفيض عام. أما هذه المقالة فموضوعها بوابة أسبق: اختبار دخول السلسلة. يمكن أن يفشل الاثنان بصورة مستقلة.

إيصال يشرح مسار القرار

يبدأ الإيصال الأدنى ببايتات UTF-8 الأصلية وترتيب نقاط الترميز وموقعها في قواعد العنوان. ولكل محرف غير ASCII يسجل نتيجة IdentifierClass وقاعدة السياق ونتيجتها وحساب Script. كما يبين سياسات التحويل وحالة الأحرف والتطبيع والاتجاه.

بعد ذلك يثبت إصدار بيانات Unicode/PRECIS وبناء المدقق والواجهة المستدعية والوقت والإجراء ومسار التصحيح. يمكن للوحة التشغيل عرض الشكل المقروء بجوار تمثيل escaped آمن، بينما تحفظ القيمة الأصلية كدليل محمي.

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

المصادر