अंतर्राष्ट्रीयकरण को प्रतिरूपण से अलग करें
अंतर्राष्ट्रीयकृत डोमेन नाम लोगों को पारंपरिक ASCII अक्षरों, अंकों और हाइफ़न से परे डोमेन लेबल का उपयोग करने देते हैं। वह क्षमता वैध और महत्वपूर्ण है. सुरक्षा संबंधी चिंता किसी विशेष स्क्रिप्ट की उपस्थिति नहीं है; यह है कि क्या एक प्रदर्शित पहचानकर्ता को परिणामी संदर्भ में किसी अन्य पहचान के साथ भ्रमित किया जा सकता है। इसलिए एक होमोग्राफ़ या कन्फ़्यूज़ेबल-डोमेन जांच को प्रत्येक गैर-ASCII नाम को दुर्भावनापूर्ण घोषित किए बिना वास्तविक नाम, उसके मान्य DNS प्रतिनिधित्व और रिसीवर की प्रस्तुति को संरक्षित करना चाहिए।
RFC 5890 ए-लेबल और यू-लेबल सहित अनुप्रयोगों में अंतर्राष्ट्रीयकृत डोमेन नामों के लिए शब्दावली को परिभाषित करता है। यूनिकोड तकनीकी मानक 39 भ्रमित करने योग्य तारों की पहचान करने के लिए तंत्र का वर्णन करता है। ये संबंधित लेकिन अलग-अलग कार्य हैं। आईडीएनए प्रतिनिधित्व और वैधता संबद्धता के बारे में निर्णय नहीं है; भ्रमित करने वाली तुलना धोखाधड़ी का प्रमाण नहीं है। यह लेख नाम दर्ज किए बिना, संदेश भेजे बिना या संदिग्ध डोमेन पर गए बिना एक रक्षात्मक समीक्षा पद्धति का प्रस्ताव करता है।
प्रपत्रों को ढहाने के बजाय उन्हें सुरक्षित रखें
RFC 5890 खंड 2.3.2.1 निर्दिष्ट आवश्यकताओं के तहत ए-लेबल को आईडीएनए-मान्य लेबल के एएससीआईआई-संगत रूप के रूप में और यू-लेबल को इसके यूनिकोड फॉर्म के रूप में परिभाषित करता है। परिचित xn-- उपसर्ग से शुरू होने वाली प्रत्येक स्ट्रिंग वैध A-लेबल नहीं है। एक पार्सर को अकेले उपसर्ग को प्रमाण मानने के बजाय रिश्ते को मान्य करना चाहिए। इसी तरह, एक मनमाना यूनिकोड स्ट्रिंग स्वचालित रूप से एक वैध यू-लेबल नहीं है क्योंकि यह एक डोमेन लेबल जैसा दिखता है।
परिवर्तन से पहले अपरिष्कृत प्रेक्षित मान को बनाए रखें। फिर पार्सर और उपयोग किए गए संस्करण, उसके द्वारा उत्पादित मान्य लेबल फॉर्म और किसी भी त्रुटि को रिकॉर्ड करें। मेल क्लाइंट से प्रदर्शित मूल्य को एक अलग अवलोकन के रूप में रखें। एक स्क्रीनशॉट उपस्थिति का दस्तावेजीकरण कर सकता है, लेकिन यह अंतर्निहित कोड बिंदुओं या पार्स किए गए पते को प्रतिस्थापित नहीं कर सकता है। इस पांडुलिपि में सामान्यीकरण उपकरण नहीं चलाया गया है और यह कथित रूप से मापे गए रूपांतरणों की आपूर्ति नहीं करता है। वास्तविक उदाहरण तैयार किए जाने चाहिए और अधिकृत साक्ष्य अभ्यास में बनाए रखे जाने चाहिए।
एक भ्रमित करने वाला कंकाल एक DNS नाम नहीं है
यूनिकोड TR39 परिभाषित परिवर्तनों और डेटा का उपयोग करके भ्रमित करने योग्य पहचान का वर्णन करता है। रखे गए वर्तमान दस्तावेज़ में दिशा-जागरूक कंकाल प्रसंस्करण और नोट्स शामिल हैं कि तुलना अत्यधिक समावेशी हो सकती है। कंकाल एक तुलनात्मक कलाकृति है। इसका उपयोग क्वेरी के पते, अनुमति सूची के डोमेन या DNS में प्रकाशित करने के मान के रूप में नहीं किया जाना चाहिए। तुलना विधि के तहत मेल खाने वाली दो स्ट्रिंग एक ही डोमेन नहीं बनती हैं या एक ही मालिक को प्राप्त नहीं करती हैं।
ऐसी विधि का उपयोग करते समय यूनिकोड डेटा संस्करण, एल्गोरिदम और प्रासंगिक दिशा धारणाओं को रिकॉर्ड करें। दृश्यमान समान वर्णों को लोअरकेस करने और बदलने के लिए वर्तमान विनिर्देश को एक गैर-दस्तावेजी निर्देश में सरलीकृत न करें। यह अज्ञात व्यवहार वाला एक अलग एल्गोरिदम होगा। यदि कोई उत्पाद समानता स्कोर प्रदान करता है, तो उत्पाद की विधि और सीमाओं को मानक से अलग रखें। एक स्कोर दुर्भावनापूर्ण इरादे या प्राप्तकर्ता के वास्तविक प्रदर्शन व्यवहार को स्थापित किए बिना मानवीय समीक्षा को प्राथमिकता दे सकता है।
प्रस्तुति उपभोग करने वाले एप्लिकेशन पर निर्भर करती है
एक ही अंतर्निहित डोमेन को विभिन्न अनुप्रयोगों और संदर्भों द्वारा अलग-अलग प्रस्तुत किया जा सकता है। यह वादा न करें कि प्रत्येक मेल क्लाइंट यूनिकोड प्रदर्शित करता है, हमेशा ASCII फॉर्म प्रदर्शित करता है या मिश्रित स्क्रिप्ट के बारे में लगातार चेतावनी देता है। वर्तमान रिसीवर परिणाम के लिए प्रासंगिक क्लाइंट, संस्करण, प्लेटफ़ॉर्म और संदेश संदर्भ के वास्तविक अवलोकन की आवश्यकता होती है। इस लेख में उन टिप्पणियों का प्रदर्शन नहीं किया गया है और इसलिए यह कोई दावा नहीं करता है कि कोई विशेष प्रदाता किसी विशिष्ट परीक्षण नाम को प्रदर्शित या अवरुद्ध करेगा।
बाद में अधिकृत साक्ष्य एकत्र करते समय, मूल पहचान और उपयोगकर्ता ने जो देखा, दोनों को सुरक्षित रखें। इसमें शामिल करें कि क्या पता विस्तारित या संक्षिप्त किया गया था, क्या प्रदर्शन नाम अलग से दिखाया गया था और किस इंटरफ़ेस ने कोई चेतावनी दी थी। एक स्क्रीनशॉट से सभी प्राप्तकर्ताओं के लिए सामान्यीकरण करने से बचें। अभिगम्यता की समीक्षा भी मायने रखती है: एक दृश्य समानता और एक मौखिक प्रतिपादन अलग-अलग समझ की समस्याएं पैदा कर सकता है, लेकिन उचित देखे गए उदाहरण के बिना किसी पर भी जोर नहीं दिया जाना चाहिए।
प्रमाणीकरण डोमेन का अनुसरण करता है, कथित समानता का नहीं
RFC 9989, धारा 2.2, यह बताती है DMARC दिखने में समान डोमेन नाम या प्रदर्शन-नाम के दुरुपयोग को संबोधित नहीं करता है। एक अलग डोमेन स्वयं के लिए मेल को प्रमाणित कर सकता है, भले ही प्राप्तकर्ता इसे किसी विश्वसनीय संगठन के लिए भूल जाए। यह जाँच बंद करने का कोई कारण नहीं है संरेखण. यह वास्तविक डोमेन और प्राप्तकर्ता द्वारा उसकी उपस्थिति से अनुमानित पहचान के बीच अंतर को संरक्षित करने का एक कारण है।
विश्वास-सीमा संबंधी चिंताओं का पालन करते हुए, विश्वसनीय रिसीवर प्रमाणीकरण साक्ष्य का उपयोग करें RFC 8601. रिकॉर्ड करें कि किस डोमेन को प्रमाणित किया गया और किस दृश्यमान डोमेन का मूल्यांकन किया गया। उनके संबंध का आकलन करने से पहले उन डोमेन को किसी भ्रमित करने वाले ढांचे से न बदलें। तुलना के लिए प्रदर्शन को सामान्य करने से जांच की जा रही प्रोटोकॉल पहचान में चुपचाप परिवर्तन नहीं होना चाहिए। प्रमाणीकरण परिणाम और मानव-पहचान मुद्दे को जुड़े हुए लेकिन अलग-अलग अवलोकनों के रूप में रखें।
एक पहचान-प्रतिनिधित्व कार्यपत्रक
मूल संदेश फ़ील्ड, कच्चे निकाले गए डोमेन, जहां आवश्यक हो, कोड-बिंदु प्रतिनिधित्व, मान्य ए-लेबल और यू-लेबल फॉर्म, पार्सर संस्करण, सत्यापन परिणाम और प्रदर्शित क्लाइंट फॉर्म के साथ एक वर्कशीट बनाएं। एक विश्वसनीय व्यवसाय रिकॉर्ड, भ्रमित-पहचान विधि और संस्करण, तुलना परिणाम, रिसीवर प्रमाणीकरण उद्गम और अनुरोधित कार्रवाई से तुलना लक्ष्य जोड़ें। देखे गए तथ्यों और विश्लेषक व्याख्या के लिए अलग-अलग कॉलम शामिल करें।
गोपनीयता के लिए, मामले के लिए आवश्यक सटीक डोमेन भेदों को संरक्षित करते हुए असंबंधित संदेश सामग्री और व्यक्तिगत पहचानकर्ताओं को संशोधित करें। केवल वर्कशीट को दर्शाने के लिए किसी वास्तविक संदिग्ध डोमेन को क्लिक करने योग्य लिंक के रूप में प्रकाशित न करें। एक अनुमोदित गैर-संवादात्मक साक्ष्य प्रस्तुति का उपयोग करें। यदि शिक्षण के लिए काल्पनिक तारों का उपयोग किया जाता है, तो उन्हें उदाहरण के रूप में लेबल करें और यह दावा न करें कि वे पंजीकृत थे, प्रदाता द्वारा स्वीकार किए गए थे या रिसीवर द्वारा प्रदर्शित किए गए थे। एक मनगढ़ंत रिसीवर परिणाम साक्ष्य की आवश्यकता के उद्देश्य को विफल कर देगा।
काल्पनिक निदान: एक नाम जो परिचित लगता है
एक काल्पनिक खरीद विश्लेषक ने नोटिस किया कि एक आपूर्तिकर्ता संदेश एक परिचित नाम का उपयोग करता प्रतीत होता है, लेकिन एक विस्तारित पता दृश्य एक अलग अंतर्निहित डोमेन का खुलासा करता है। सुरक्षा टीम कच्चे पते को संरक्षित करने और एक दस्तावेजी उपकरण का उपयोग करके मान्य अभ्यावेदन की तुलना करने का प्रस्ताव करती है। इस स्तर पर टीम को दुर्भावनापूर्ण इरादे या स्वामित्व के प्रमाण की नहीं, बल्कि भ्रामकता की चिंता है। अनुरोधित आपूर्तिकर्ता-रिकॉर्ड परिवर्तन सामान्य व्यावसायिक प्रक्रिया के तहत रुका हुआ रहता है।
टीम पहले से ही स्वतंत्र रूप से रिकॉर्ड किए गए आपूर्तिकर्ता संपर्क के माध्यम से संबद्धता का सत्यापन करेगी। यदि कोई अधिकृत जांच आगे बढ़ती है तो यह वास्तविक प्राप्तकर्ता के साक्ष्य भी बनाए रखेगा। काल्पनिक मामले में जानबूझकर कोई आविष्कृत यूनिकोड रूपांतरण, स्केलेटन आउटपुट या दावा शामिल नहीं है कि नामित मेल क्लाइंट ने एक विशेष स्ट्रिंग प्रदर्शित की है। वे टिप्पणियाँ हैं जिन्हें एकत्र किया जाना चाहिए, न कि वर्णनात्मक सुविधा के लिए भरने के लिए विवरण। इस कार्य के दौरान मेल भेजने के लिए किसी डोमेन के बारे में पूछताछ, पंजीकरण या उपयोग नहीं किया गया।
केवल आवश्यक उदाहरणों के साथ जारी करें
एक बचाव योग्य निष्कर्ष वैध प्रतिनिधित्व, समानता, संबद्धता, प्रमाणीकरण और देखे गए नुकसान को अलग करता है। यह बता सकता है कि तुलना पद्धति में किसी अपराध का दावा किए बिना ही भ्रम की स्थिति पाई गई। यह बता सकता है कि व्यावसायिक अनुरोध को प्रमाणित किए बिना एक अलग डोमेन प्रमाणित किया गया है। यह किसी प्राप्तकर्ता की प्रस्तुति को बिना यह दावा किए प्रलेखित कर सकता है कि प्रत्येक प्राप्तकर्ता समान व्यवहार करता है। ये अंतर परिणामी मार्गदर्शन को वैध अंतर्राष्ट्रीय नामकरण के साथ-साथ प्रतिरूपण जांच में उपयोगी बनाते हैं।
कैटलॉग को सामान्यीकृत DNS फॉर्म और रिसीवर परिणामों के साथ कच्चे और प्रदर्शित पहचान उदाहरणों की आवश्यकता होती है। वे मूल अवलोकन खुले रहते हैं। इस पांडुलिपि में एक वर्कशीट और काल्पनिक निदान प्रक्रिया है, न कि वह साक्ष्य। मानव विशेषज्ञ समीक्षा, स्रोत प्रयोज्यता, उत्पादन मार्ग, दृश्य पहुंच और मालिक की रिहाई भी खुली रहती है। प्रकाशन के लिए सटीक टूल संस्करणों और देखे गए परिणामों के साथ संरक्षित, अधिकृत उदाहरणों की आवश्यकता होती है, अनावश्यक व्यक्तिगत डेटा को उजागर किए बिना या किसी डोमेन ऑपरेटर के बारे में असमर्थित आरोप लगाए बिना समीक्षा की जाती है।