डिलीवरी की व्याख्या करने से पहले परिणाम को समझें
SPF temperror इसका मतलब है कि सत्यापनकर्ता को जाँच करते समय एक क्षणिक त्रुटि का सामना करना पड़ा, जिसमें आम तौर पर DNS शामिल था। इसका मतलब यह नहीं है कि डोमेन ने क्लाइंट को अधिकृत करने से स्पष्ट रूप से इनकार कर दिया है, और यह स्थापित नहीं करता है कि प्रकाशित रिकॉर्ड स्थायी रूप से विकृत है। अंतर मायने रखता है क्योंकि एक स्थायी नीति पुनर्लेखन एक अस्थायी समाधानकर्ता समस्या की गलत प्रतिक्रिया हो सकती है।
जाँच करने वाला सॉफ़्टवेयर संदेश को स्वीकार या अस्थायी रूप से अस्वीकार करना चुन सकता है। यदि यह इस कारण से SMTP के दौरान अस्वीकार कर देता है, RFC 7208 उत्तर कोड 451 की सिफारिश करता है और, जहां समर्थित है, उन्नत स्थिति 4.4.3 की सिफारिश करता है। ये सशर्त सिफ़ारिशें हैं, इस बात का प्रमाण नहीं कि प्रत्येक रिसीवर उन सटीक कोडों का उत्सर्जन करता है या कोई संदेश पहले से ही पुनः प्रयास कतार में प्रवेश कर चुका है। जो हुआ उसका वर्णन करने से पहले वास्तविक SMTP प्रतिक्रिया और प्रेषक-पक्ष की स्थिति प्राप्त करें। RFC 7208 , खंड 8.6
मूल्यांकित पहचान और DNS संदर्भ कैप्चर करें
कनेक्टिंग पते से प्रारंभ करें, HELO या मेल प्रेषक पहचान, मूल्यांकित डोमेन, प्रेषक तर्क और अवलोकन समय। SPF केवल यह मूल्यांकन नहीं करता है कि उपयोगकर्ता संदेश के प्रेषक डिस्प्ले में कौन सा डोमेन देखता है। यदि कोई सेवा एक अलग लिफाफा डोमेन का उपयोग करती है, तो उस डोमेन के लिए एक क्षणिक परिणाम को ग्राहक के दृश्यमान पते पर स्वचालित रूप से श्रेय देने के बजाय उस संदर्भ में जांच की जानी चाहिए।
सटीक क्वेरी नाम, रिकॉर्ड प्रकार, रिज़ॉल्वर या मूल्यांकनकर्ता संदर्भ, प्रतिक्रिया कोड, टाइमआउट जानकारी और प्रासंगिक उत्तर रिकॉर्ड बनाए रखें। किसी व्यवस्थापक के लैपटॉप से बाद में की गई सफल क्वेरी उपयोगी पुष्टि है, लेकिन यह रिसीवर की पिछली DNS स्थिति का पुनर्निर्माण नहीं करती है। दोनों अवलोकनों को टाइमस्टैम्प और दायरे के साथ सुरक्षित रखें। समस्याएँ प्रेषक या प्राप्तकर्ता के DNS सॉफ़्टवेयर में उत्पन्न हो सकती हैं, इसलिए अकेले त्रुटि लेबल जिम्मेदारी नहीं दे सकता है। RFC 7208 , खंड 2.3, 2.4 और 8.6
उस निर्भरता का पालन करें जहां त्रुटि हुई
एक नीति पुनरावर्ती समावेशन या पुनर्निर्देशन के साथ-साथ अन्य DNS-कारक तंत्रों पर निर्भर हो सकती है। एक बच्चा temperror सामान्य नॉनमैच की तरह व्यवहार करने के बजाय एक त्रुटि के रूप में शामिल होता है। इसलिए अस्थायी रूप से अनुपलब्ध आपूर्तिकर्ता को छोड़ना और यह घोषणा करना असुरक्षित है कि माता-पिता के अंतिम -all ने परिणाम निर्धारित किया है। वह तंत्र दिखाएं जिस पर मूल्यांकन रुका और परिणाम अभिभावक को लौटाया गया।
क्षणिक विफलताओं को खाली सकारात्मक उत्तरों और शून्य-लुकअप लेखांकन में उपयोग किए जाने वाले नाम त्रुटि प्रतिक्रियाओं से अलग रखें। साथ ही दस-अवधि की सीमा को बीते समय की सीमा से अलग करें। RFC 7208 का कहना है कि प्रोसेसरों को एक मूल्यांकन समय सीमा लगानी चाहिए जिसके लिए कम से कम बीस सेकंड का समय देना चाहिए; यदि पार हो गया, तो प्राधिकरण temperror होना चाहिए। इसे सार्वभौमिक निश्चित टाइमआउट के रूप में वर्णित न करें या सबूत के बिना किसी विशेष रिसीवर के कॉन्फ़िगरेशन को न मानें। RFC 7208 , खंड 4.6.4 और 5.2
जांच में तीन घड़ियां अलग करें
कम से कम तीन प्रासंगिक समय अनुक्रम हैं: DNS रिज़ॉल्यूशन और कैशिंग, रिसीवर का SMTP लेनदेन, और भेजने वाले सिस्टम की कतार प्रयास। एक अस्थायी DNS विफलता मिलीसेकंड या सेकंड के भीतर हो सकती है जबकि बाद में डिलीवरी के प्रयासों में बहुत लंबी अवधि लग सकती है। इन अनुक्रमों को एक सामान्य "पुनर्प्रयास" घटना के रूप में मानने के बजाय लेन-देन के साक्ष्य से जोड़कर रखें।
रिकॉर्ड करें कि क्या प्राप्तकर्ता ने संदेश स्वीकार कर लिया, एक अस्थायी प्रतिक्रिया जारी की, या उपयोगी प्रतिक्रिया के बिना कनेक्शन बंद कर दिया। फिर वास्तविक कतारबद्ध पुनः प्रयास, अगले प्रयास के समय या अंतिम समाप्ति के लिए अधिकृत प्रेषक-पक्ष साक्ष्य का निरीक्षण करें। यह आलेख विक्रेता-विशिष्ट पुनर्प्रयास अंतराल निर्धारित नहीं करता है। प्रोटोकॉल-स्तरीय अस्थायी त्रुटि यह स्थापित नहीं करती है कि कोई विशेष एप्लिकेशन संदेशों को कैसे कतारबद्ध, रिपोर्ट या छोड़ देता है।
यह वादा न करें कि प्रतीक्षा करने से घटना अवश्य सुलझ जाएगी। आवर्ती समाधानकर्ता समस्या या अनुपलब्ध निर्भरता प्रयासों के दौरान जारी रह सकती है। इसके विपरीत, क्षणिक आउटेज के दौरान बार-बार DNS संपादित करने से नए दोष आ सकते हैं और मूल कारण का पुनर्निर्माण करना कठिन हो सकता है। पहले निदान करें, कालक्रम को संरक्षित करें और प्रत्येक साक्ष्य स्रोत के लिए एक जिम्मेदार ऑपरेटर नियुक्त करें।
प्रस्तावित स्वीकृति कार्यपत्रक
प्रति सीमित प्रयास में एक पंक्ति के साथ एक वर्कशीट बनाएं। मार्ग स्वामी, संदेश सहसंबंध पहचानकर्ता, मूल्यांकन की गई पहचान, कनेक्टिंग पता, सटीक SPF स्नैपशॉट, निर्भरता चरण, DNS परिणाम, SPF परिणाम, रिसीवर प्रतिक्रिया और भेजने वाली कतार स्थिति शामिल करें। अनावश्यक प्राप्तकर्ता विवरण और संदेश सामग्री को कार्यशील प्रतिलिपि से बाहर रखें। प्रत्येक क्षेत्र की उत्पत्ति को सुरक्षित रखें ताकि किसी एप्लिकेशन की स्थिति को रिसीवर अवलोकन के रूप में गलत न समझा जाए।
एक अनिश्चितता स्तंभ जोड़ें. उदाहरणों में अनुपलब्ध रिसीवर रिज़ॉल्वर लॉग, समसामयिक DNS उत्तर के बजाय बाद का उत्तर, या एक कतार घटना शामिल है जिसे SMTP लेनदेन से आत्मविश्वास से नहीं जोड़ा जा सकता है। एक समीक्षक को परिचालन कार्रवाई चुनने से पहले यह देखना चाहिए कि क्या अज्ञात रहता है। यह मानकर अंतराल न भरें कि एक ही समय विंडो में सभी संदेश एक ही पथ का अनुसरण करते हैं।
स्वीकृति मानदंड को निदान को पुनर्प्राप्ति से अलग करना चाहिए। निदान के लिए एक समर्थित क्षणिक विफलता और मूल्यांकन में उसके स्थान की आवश्यकता होती है। पुनर्प्राप्ति के लिए बताई गई शर्तों के तहत प्रभावित मार्ग के बाद के अधिकृत अवलोकन की आवश्यकता होती है। कोई भी स्वचालित रूप से यह साबित नहीं करता है कि प्रत्येक प्राप्तकर्ता, पता परिवार या आपूर्तिकर्ता निर्भरता स्वस्थ है। एक प्रस्तावित अनुवर्ती जांच के लिए अपने स्वयं के प्राधिकरण और बनाए रखा परिणाम की आवश्यकता होती है; इस ड्राफ्ट के लिए ऐसा कोई चेक निष्पादित नहीं किया गया था।
काल्पनिक निदान: अन्यत्र स्वीकार किया गया, यहां स्थगित किया गया
एक काल्पनिक लेन-देन मार्ग की कल्पना करें जिसकी ग्राहक नीति में एक आपूर्तिकर्ता शामिल है। एक काल्पनिक रिसीवर के लिए, आपूर्तिकर्ता-नीति क्वेरी का समय समाप्त हो जाता है और SPF मूल्यांकन temperror लौटाता है। मान लें कि रिसीवर एक अस्थायी SMTP प्रतिक्रिया चुनता है और प्रेषक एक कतारबद्ध पुनः प्रयास रिकॉर्ड करता है। इस शिक्षण उदाहरण में वे तीन अलग-अलग अनुमानित तथ्य हैं, एकत्रित लॉग या वास्तविक प्रदाता घटना नहीं।
दूसरा काल्पनिक रिसीवर आपूर्तिकर्ता नीति को सफलतापूर्वक हल करता है और संदेश स्वीकार करता है। वह अवलोकन पहले प्राप्तकर्ता की रिपोर्ट को झूठा साबित नहीं करेगा। विभिन्न रिज़ॉल्वर संदर्भ और समय अलग-अलग परिणाम उत्पन्न कर सकते हैं। उपयोगी जांच टाइमस्टैम्प और निर्भरता की तुलना करेगी, न कि यह तर्क देगी कि एक सफल लुकअप हर पिछली विफलता को अमान्य कर देता है।
अब मान लीजिए कि प्रेषक डैशबोर्ड केवल "विफल" दिखाता है और कोई SMTP प्रतिक्रिया नहीं दिखाता है। अन्वेषक यह निष्कर्ष नहीं निकाल सकता कि प्राप्तकर्ता ने संदेश को स्थायी रूप से अस्वीकार कर दिया है या प्रेषक ने पुनः प्रयास किया है। अगली कार्रवाई एक अनुमोदित चैनल के माध्यम से गायब हुए साक्ष्यों को प्राप्त करना है। प्रस्तावित निदान तब तक अस्थायी रहता है जब तक कतार और SMTP रिकॉर्ड इसका समर्थन नहीं करते। कोई भी रिकॉर्ड परिवर्तन केवल जेनेरिक लेबल द्वारा उचित नहीं है।
साक्ष्य और रिहाई सीमा
यह आलेख एक निदान पद्धति प्रदान करता है, न कि कोई घटना रिपोर्ट। कैटलॉग को प्रत्येक निदान का समर्थन करने वाले DNS या संदेश साक्ष्य के साथ परिणाम-विशिष्ट उदाहरणों की आवश्यकता होती है। वे उदाहरण, मूल क्वेरी प्रतिलेख और देखा गया पुनर्प्राप्ति व्यवहार खुला रहता है। कोई DNS स्कैन, संदेश भेजना, कतार संचालन या रिसीवर परीक्षण नहीं किए गए।
मानव समीक्षा को सशर्त SMTP अनुशंसा, मूल्यांकनकर्ता मान्यताओं और कारण कारण की सीमाओं की जांच करनी चाहिए। स्रोत प्रयोज्यता, मूल साक्ष्य, उत्पादन मार्ग, दृश्य पहुंच और मालिक की रिहाई भी खुली रहती है। वास्तविक सुधार से पहले, एक ऑपरेटर को नीति दोष को अस्थायी निर्भरता या समाधानकर्ता मुद्दे से अलग करना होगा और किसी भी उत्पादन परिवर्तन के लिए आवश्यक प्राधिकरण प्राप्त करना होगा।