आईपी ​​प्रतिष्ठा बनाम डोमेन प्रतिष्ठा

एक दृश्यमान कनेक्टिंग आईपी से आते समय एक ईमेल कई डोमेन पहचान ले जा सकता है। यह पूछना कि क्या "प्रतिष्ठा" अच्छी है, उन भेदों को छिपा देता है। उस पते या डोमेन का नाम देकर प्रारंभ करें जिसका प्रत्येक स्रोत मूल्यांकन करता है और प्राप्त करने वाली सेवा जिसने सिग्नल उत्पन्न किया है।

प्रतिष्ठा से अलग पहचान

DKIM एक हस्ताक्षरित संदेश और एक हस्ताक्षरित डोमेन के बीच संबंध स्थापित करता है। यह स्वयं वांछित या सुरक्षित सामग्री की घोषणा नहीं करता है। एक वैध हस्ताक्षर अवांछित मेल के साथ हो सकता है। RFC 6376.

इसी तरह, एक आईपी पता एक हॉप पर देखे गए नेटवर्क मूल की पहचान करता है, जो एक साझा सेवा या अनुवादित पता हो सकता है। प्रतिष्ठा एक मूल्यांकनकर्ता द्वारा देखे गए व्यवहार का मूल्यांकन है, हस्तांतरणीय प्रमाणपत्र नहीं। Google विशिष्ट IP और को उजागर करता है डोमेन प्रतिष्ठा दृश्य, जबकि Microsoft SNDS IP-उन्मुख टेलीमेट्री प्रदान करता है। Google का पोस्टमास्टर डेटा व्यक्तिगत Gmail ट्रैफ़िक को कवर करता है, वास्तविक समय नहीं है और गोपनीयता के लिए कम मात्रा वाले डेटा को छोड़ सकता है। Microsoft SNDS अधिकृत पता स्वामियों के लिए Outlook .com IP अवलोकन प्रदान करता है। विचारों को एक आविष्कृत सार्वभौमिक स्कोर में विलय करने के बजाय उन क्षेत्रों को संरक्षित करें। पोस्टमास्टर डैशबोर्ड, SNDS.

असफल स्ट्रीम के लिए एक पहचान मानचित्र बनाएं

डोमेन से दृश्यमान कनेक्टिंग आईपी रिकॉर्ड करें, लिफाफा भेजने वाला डोमेन और DKIM हस्ताक्षरित डोमेन। प्रदाता मार्ग और संदेश संशोधन को भी सुरक्षित रखें। यदि कोई सेवा अपने स्वयं के डोमेन के साथ हस्ताक्षर करती है जबकि दृश्यमान ग्राहक के ब्रांड का उपयोग करता है, तो दोनों को स्पष्ट रूप से लिखें। "डोमेन प्रतिष्ठा खराब है" तब तक अधूरा है जब तक कि यह उस मूल्यांकन के डोमेन और स्रोत का नाम नहीं देता।

समान आयामों का उपयोग करके प्रभावित और अप्रभावित ट्रैफ़िक की तुलना करें। एक आईपी कई ब्रांड ले जा सकता है; एक ब्रांड एकाधिक आईपी का उपयोग कर सकता है। एक नया रूट ब्रांड को बदले बिना आईपी को बदल सकता है, जबकि एक कस्टम-साइनिंग रोलआउट कनेक्शन को स्थानांतरित किए बिना साइनिंग डोमेन को बदल सकता है। इन परिवर्तनों को दिनांकित कॉन्फ़िगरेशन इतिहास में रखें।

दो-दो-दो उदाहरण का सावधानी से उपयोग करें

एक काल्पनिक दो-ब्रांड, दो-आईपी तुलना पर विचार करें। ब्रांड ए के दोनों पतों पर प्रतिकूल टिप्पणियाँ हैं; ब्रांड बी में केवल पहले पर प्रतिकूल टिप्पणियाँ हैं। यह जांच के लायक ब्रांड-संबद्ध पैटर्न और आईपी-संबद्ध पैटर्न दोनों को छोड़ देता है। यह एक भी कारण की पहचान नहीं करता है.

ये आविष्कृत लेबल प्रदाता स्कोर नहीं हैं, और मैट्रिक्स फ़िल्टरिंग एल्गोरिदम का एक मॉडल नहीं है। यह उलझन को दर्शाता है: दर्शकों की संरचना, सामग्री और रूटिंग एक साथ बदल सकते हैं। वास्तविक निदान के लिए कारण बताने से पहले तुलनीय ट्रैफ़िक और स्वतंत्र अवलोकन की आवश्यकता होती है।

सही स्तर पर सुधारात्मक कार्य चुनें

मार्ग-विशिष्ट परिवहन विफलता के लिए, वास्तविक निदान को बनाए रखें और बुनियादी ढांचे के मालिक से जांच करने के लिए कहें। कई मार्गों पर एक कार्यक्रम में केंद्रित शिकायतों के लिए, उस कार्यक्रम के मालिक के साथ अनुमति, अपेक्षाओं और दमन का निरीक्षण करें। विफल प्रमाणीकरण के लिए, प्रतिष्ठा में सुधार की उम्मीद करने के बजाय सीधे मूल्यांकन की गई पहचान और कॉन्फ़िगरेशन की जांच करें जिससे विफलता गायब हो जाएगी।

किसी नए आईपी या डोमेन को साफ़ स्लेट के रूप में प्रस्तुत करने से बचें। बुनियादी ढांचे को बदलने से वांछित मेल, सही पहचान और विश्वसनीय शिकायत प्रबंधन की आवश्यकता दूर नहीं होती है। यदि प्रत्येक चर एक साथ बदलता है तो यह नए परिचालन कार्य को प्रस्तुत कर सकता है और तुलना को कमजोर कर सकता है।

समापन में अनिश्चितता बनाए रखें

बताएं कि कौन से संकेत देखे गए, वे कौन सी पहचान छिपाते हैं और उनके द्वारा समर्थित गतिविधियां क्या हैं। यदि कोई प्रदाता किसी डोमेन के लिए स्कोर उजागर नहीं करता है, तो किसी असंबंधित आईपी चार्ट से स्कोर का अनुमान लगाने के बजाय कहें कि डेटा अनुपलब्ध है। अनुमानित कारणों से प्राप्त परिणामों को अलग से ट्रैक करें।

एक उपयोगी परिणाम यह हो सकता है कि "डोमेन दोषी है" के बजाय "समस्या दो मार्गों से इस धारा का अनुसरण करती है"। वह संक्षिप्त कथन मालिकाना भार के ज्ञान या इनबॉक्स के लिए गारंटीकृत पथ का दावा किए बिना अगले परीक्षण को निर्देशित करता है।

बिना किसी आशाजनक कारण के नियंत्रित तुलना का प्रयोग करें

मान लीजिए कि अगला प्रस्तावित चेक सामग्री, गंतव्य मिश्रण और अवलोकन अवधि को व्यावहारिक रूप से संरक्षित करते हुए एक अनुमोदित वैकल्पिक मार्ग के माध्यम से प्रभावित धारा का अनुसरण करता है। परिणाम एकत्र करने से पहले, प्रतिस्पर्धी स्पष्टीकरण बताएं: मार्ग-विशिष्ट इनकार, कार्यक्रम-विशिष्ट शिकायतें या संदेश-स्तरीय प्रमाणीकरण दोष।

यदि एक ही स्ट्रीम में अभी भी दोनों मार्गों पर समस्याएं हैं, तो यह साबित नहीं होता है कि डोमेन स्कोर के कारण उनका कारण बना। यदि एक मार्ग बेहतर दिखता है, तो दर्शकों का इतिहास और प्राप्त करने का व्यवहार अभी भी भिन्न हो सकता है। वास्तविक निदान और प्रदाता के स्कोप्ड टेलीमेट्री को बनाए रखें, और अगला साक्ष्य अनुरोध चुनें जो उन विकल्पों को अलग कर सके। यह एक काल्पनिक जांच योजना है, न कि कोई परिकलित प्रतिष्ठा मॉडल या मापा मार्ग सुधार।

अगले चेक को समर्थित पैटर्न पर असाइन करें

• वास्तविक स्ट्रीम के लिए मैप आईपी, फ्रॉम, लिफाफा और DKIM पहचान।
• प्रत्येक प्रतिष्ठा संकेत के प्रदाता, दायरे और समय को रिकॉर्ड करें।
• सहसंबंध को कार्य-कारण माने बिना सभी मार्गों पर धाराओं की तुलना करें।
• रूट डायग्नोस्टिक्स, दर्शकों की शिकायतों और प्रमाणीकरण की अलग से जांच करें।
• यदि कोई प्रदाता किसी स्कोर को उजागर नहीं करता है, तो सार्वभौमिक रेटिंग का अनुमान लगाने के बजाय इसे अनुपलब्ध के रूप में चिह्नित करें।