प्रमाणीकरण समस्या का निदान करने के लिए इनबॉक्स स्क्रीनशॉट में शायद ही कभी पर्याप्त सबूत होते हैं। प्रभावित मेलबॉक्स में सटीक प्राप्त संदेश से प्रारंभ करें। इसे कब और कहाँ प्राप्त किया गया, इसे सुरक्षित रखें, फिर पूर्ण मूल-संदेश दृश्य एकत्र करें। यह बाद के विश्लेषण को उस वास्तविक प्रतिलिपि से बांधे रखता है जिसने रिपोर्ट किए गए अनुभव को उत्पन्न किया है।
संदेश-स्तरीय साक्ष्य प्राप्त करें
सन्दर्भ: RFC 6376 §3.7.
Google के ब्राउज़र निर्देश हैं कि ईमेल खोलें, उत्तर के बगल में More का उपयोग करें, मूल दिखाएँ चुनें और पूर्ण हेडर की प्रतिलिपि बनाएँ। एक ही वार्तालाप में किसी भिन्न आइटम के बजाय प्रभावित संदेश चुनें। बाइट-संरक्षित निर्यात उपलब्ध होने पर उपलब्ध मूल-संदेश आर्टिफैक्ट को अलग से सहेजें; अकेले कॉपी किए गए हेडर में पुन: सत्यापन के लिए आवश्यक सभी चीजें शामिल नहीं हैं DKIM. Gmail हेडर निर्देश.
मेलबॉक्स संदर्भ, संग्रह समय और क्या कलाकृति एक कच्चा निर्यात, कॉपी किया गया पाठ या स्क्रीनशॉट है, रिकॉर्ड करें। एक विश्लेषक को पता होना चाहिए कि संग्रह के दौरान लाइन एंडिंग, फोल्डिंग या MIME सामग्री बदल गई है या नहीं। संदेश को इनलाइन अग्रेषित न करें और परिणामी नए संदेश को अछूते मूल के रूप में वर्णित करें।
पहचान और परिणाम पढ़ें
सन्दर्भ: RFC 8601 §5.
Google बताता है कि मेल द्वारा भेजी गई और हस्ताक्षरित जानकारी प्रमाणीकरण का निरीक्षण करने में मदद कर सकती है, जबकि एक अप्रमाणित संदेश स्वचालित रूप से स्पैम नहीं होता है और एक प्रमाणित संदेश स्वचालित रूप से सुरक्षित नहीं होता है। दृश्य संकेतकों को एक प्रवेश बिंदु मानें, फिर तकनीकी विश्लेषण के लिए पूर्ण साक्ष्य अपने पास रखें। Gmail प्रमाणीकरण सहायता.
भरोसेमंद में Authentication-Results फ़ील्ड, संरक्षित करें SPF परिणाम और उसकी मूल्यांकित पहचान, DKIM परिणाम और हस्ताक्षर डोमेन, और DMARC परिणाम और डोमेन से दृश्यमान। असंबंधित हॉप्स के परिणामों को एक कल्पित रिसीवर फैसले में संयोजित न करें। एक संदेश में एकाधिक हस्ताक्षर या प्रमाणीकरण-परिणाम फ़ील्ड हो सकते हैं, इसलिए उनका क्रम और दायरा रिकॉर्ड करें। RFC 8601.
प्राप्त साक्ष्यों को दोबारा जाँचने से अलग रखें
सन्दर्भ: RFC 6376 §3.6, RFC 6376 §6.
प्राप्तकर्ता का परिणाम प्रसंस्करण समय पर उसके मूल्यांकन का वर्णन करता है। एक स्थानीय DKIM जांच आज उपलब्ध बाइट्स और प्रमुख सामग्री का मूल्यांकन करती है। एक कुंजी रोटेशन, एक परिवर्तित DNS उत्तर या एक संशोधित निर्यात मूल रिसीवर गलत साबित किए बिना एक अलग परिणाम उत्पन्न कर सकता है। हेडर टेक्स्ट दावा किए गए अवलोकन को रिकॉर्ड करता है; यह स्वयं कोई नया क्रिप्टोग्राफ़िक सत्यापन नहीं है। RFC 6376 अनुभाग 3 और 6.
संलग्न सिंथेटिक संदेश में दो Authentication-Results फ़ील्ड हैं। पार्सर चुपचाप पहले को चुनने के बजाय दोनों को लौटाता है। यह एक निष्कर्षण परीक्षण है, Gmail कैप्चर या ट्रस्ट एल्गोरिदम नहीं। वास्तविक जांच में, प्राप्तकर्ता सेवा और विश्वसनीय मार्ग को यह स्थापित करना होगा कि कौन सा परिणाम प्रासंगिक है।
सबसे छोटी उपयोगी कलाकृतियाँ साझा करें
सन्दर्भ: RFC 8601 §7.
मूल प्रतिबन्धित रखें. जब पूर्ण संदेश सामग्री या व्यक्तिगत पते अनावश्यक हों तो एक अलग लेबल वाली डायग्नोस्टिक कॉपी बनाएं। प्रश्न के लिए आवश्यक डोमेन संबंध और टाइमस्टैम्प सुरक्षित रखें, और किसी भी संपादन का खुलासा करें। हस्ताक्षर सत्यापन के लिए, असंशोधित बाइट्स के अधिकृत सुरक्षित हस्तांतरण की व्यवस्था करें न कि यह दिखावा करें कि संशोधित प्रति की हमेशा जाँच की जा सकती है।
Google एक ऑनलाइन हेडर विश्लेषक का भी वर्णन करता है, लेकिन किसी भी विश्लेषक में साक्ष्य चिपकाने से वह उस सेवा तक पहुंच जाता है। ऐसा करने से पहले प्राप्तकर्ता, डेटा और संगठनात्मक साझाकरण नियमों की समीक्षा करें। Gmail में क्या देखा गया, क्या अनुमान लगाया गया और क्या परीक्षण नहीं किया गया, इसके स्पष्ट विवरण के साथ समाप्त करें।
विश्वास जताए बिना एनोटेट किए गए नमूने को पढ़ें
सन्दर्भ: RFC 8601 §5.
बनाए रखा गया एनोटेशन रजिस्टर प्रत्येक कच्चे फ़ील्ड को उसके वास्तविक जनरेटर, दावा किए गए मूल और विश्वास सीमा के क्रम में सूचीबद्ध करता है। से एक लेखक द्वारा प्रदत्त पहचान है; SMTP लिफाफे के प्रमाण के बजाय एक प्रदर्शित प्राप्तकर्ता है। संदेश-आईडी, दिनांक और विषय प्रेषक-नियंत्रित संदर्भ हैं। प्रत्येक Authentication-Results फ़ील्ड एक रिपोर्टिंग सेवा और परिणाम का दावा करता है, लेकिन न तो trusted.example और न ही untrusted.example वास्तविक रिसीवर उद्गम स्थापित करता है। सूची-आईडी दावा की गई सूची का नाम देता है; सदस्यता समाप्त फ़ील्ड एक कार्रवाई तंत्र का वर्णन करते हैं, सूची स्वामित्व का नहीं। वर्गीकरण नमूने में, CAT, DIR, SCL और BCL का आविष्कृत Microsoft-शैली के निर्णय हैं, न कि Microsoft के अवलोकन। कोई प्राप्त श्रृंखला, SPF लिफाफा पहचान या कनेक्टिंग आईपी स्थापित नहीं किया गया था।
इस मानचित्र का उपयोग एनोटेटेड शिक्षण उदाहरण के रूप में करें। वास्तविक संदेश के लिए, प्रत्येक कल्पित मूल को संग्रह और प्राप्तकर्ता साक्ष्य से बदलें, और किसी भी असत्यापित सीमा को स्पष्ट रूप से अनसुलझा छोड़ दें।