قد يتم الاستعلام عن المجال المعروض في Unicode من خلال تمثيل متوافق مع ASCII. احتفظ بكل من النماذج وقواعد التحويل بحيث يمكن إعادة إنتاج نتيجة المدقق. الألفة البصرية ليست دليلاً على أن اسمين يحددان نفس المجال أو ينتميان إلى نفس المنظمة.
افصل المجال عن علبة البريد
مراجع: RFC 5890 §2.3.2.1, RFC 5891 §5.
يمكن أن تحتوي تسمية النطاق الدولية على علامة U، ونموذج Unicode الصالح الخاص بها، وعلامة A، ونموذجها المتوافق مع ASCII والذي يبدأ بـ xn--. تعمل معالجة IDNA على تسميات المجال. ولا يقوم بتحويل جزء محلي من البريد الإلكتروني إلى صندوق بريد ASCII ولا ينشئ دعم SMTPUTF8.
تضيف سجلات المصادقة تسميات البروتوكول حول المجال. قم بتحويل جزء النطاق الدولي باستخدام تطبيق IDNA المناسب، ثم قم بإنشاء المالك، مثل _dmarc. بالإضافة إلى مجال التسمية A. لا تقم بتشغيل مدقق IDNA لاسم المضيف فقط على تسميات الشرطة السفلية للبروتوكول وتخلص إلى أن المجال الأساسي غير صالح.
التحقق من صحة بدلا من مجرد تشفير
مراجع: RFC 5890 §2.3.2.1, RFC 5891 §4, RFC 5895 §2.
يعد Punycode جزءًا من تمثيل A-label، ولكن ليست كل سلسلة تبدأ بـ xn-- هي تسمية A صالحة. يتضمن التحقق من الصحة قواعد IDNA المعمول بها والأحرف المسموح بها والقيود السياقية. يحدد RFC 5891 معالجة البروتوكول، بينما يمكن أن تؤثر اختيارات تعيين التطبيق على إدخال المستخدم قبل تلك المعالجة.
قم بتسجيل المكتبة والإصدار وملف تعريف IDNA وإدخال Unicode ونموذج ASCII الناتج. يمكن أن تختلف الإعدادات الافتراضية للأداة، خاصة بالنسبة للأحرف المتأثرة بالتعيين أو سلوك IDNA الأقدم. تجنب تسوية إدخال مستخدم غامض بصمت وتقديم النتيجة على أنها المجال المقصود الوحيد الممكن.
إعادة إنتاج لاعبا اساسيا ذهابا وإيابا
باستخدام مكتبة Python idna المثبتة والتي تنفذ IDNA2008، قم بتشغيل idna.encode("bü cher.example ", uts46=False).decode("ascii"). الناتج المتوقع هو xn--bcher-kva.example. قم بفك تشفيرها باستخدام نفس المكتبة وتحقق من رحلة Unicode ذهابًا وإيابًا. هذا المثال توضيحي وليس مطالبة بشأن النطاق المباشر للمؤسسة.
بناء _dmarc.xn--bcher-kva.example و s1._domainkey.xn--bcher-kva.example كسلاسل مالك DNS . في المختبر أو المدقق المتحكم فيه، يمكنك التقاط ما إذا كانت الأداة تقبل إدخال Unicode، أو تحوله، أو ترفضه، أو ترسل سؤالاً مختلفًا. يسجل الالتقاط التاريخي المحتفظ به تحويل المكتبة فقط، مع إصدار idna 3.18. يسجل فحص التحويل دون اتصال الجديد في هذه المراجعة الإصدار المثبت الخاص به بشكل منفصل؛ ولا يوجد اختبار DNS أو SMTPUTF8.
أضف تركيبًا سلبيًا بتسمية xn-- غير صالحة واحتفظ باستثناء المكتبة الفعلي. تعامل مع الرفض كدليل مفيد بدلاً من حذف الأحرف حتى يتم تمرير الإدخال. بالنسبة إلى التعيينات الأخرى التي تواجه المستخدم، قم بتوثيق ملف التعريف البديل بشكل صريح بدلاً من افتراض أن نتيجة IDNA2008 الصارمة تتطابق مع كل متصفح.
قارن الهويات الفعلية في الأدلة البريدية
مراجع: RFC 9989 §4.4, RFC 9989 §5.3.1.
الحفاظ على الأصل من الرأس وتمثيلات المجال المستخدمة من قبل SPF, DKIM و DMARC تحليل. بالنسبة إلى DMARC ، RFC 9989 يتطلب §5.3.1 تحويل نطاق مؤلف U-label المستخرج إلى نموذج A-label لمزيد من المعالجة. استخدم البروتوكول تنسيق القواعد بدلاً من المقارنة المرئية للأسماء المعروضة. عندما يكون بناء جملة الرسالة أو سلوك التدويل غير مدعوم بواسطة إحدى الأدوات، قم بالإبلاغ عن القيد بدلاً من اختيار هوية مناسبة بصمت.
استخدم سياق الملكية المعروف للتحقق من المشابهين. يمكن للمجال تمرير المصادقة الخاصة به ويظل يشبه اسم مؤسسة أخرى بشكل مرئي. يؤدي تحويل IDNA إلى تحسين إمكانية تكرار نتائج؛ فإنه لا يشهد ملكية العلامة التجارية، وإزالة التصيد المخاطرة أو إثبات أن رسالة البريد الإلكتروني قد تمت الموافقة عليها من قبل الطرف المتوقع.