सबूत की परतें अलग करें
एक पता वाक्यात्मक रूप से अच्छी तरह से बनाया जा सकता है जबकि उसका मेलबॉक्स मौजूद नहीं है। एक डोमेन एक प्रकाशित कर सकता है MX रिकॉर्ड किसी विशेष प्राप्तकर्ता को अस्वीकार करते समय। एक सर्वर SMTP के दौरान प्राप्तकर्ता को स्वीकार कर सकता है और बाद में अस्वीकार कर सकता है, या प्रत्येक स्थानीय भाग के लिए मेल स्वीकार कर सकता है। इनमें से कोई भी अवलोकन विपणन संदेश भेजने की अनुमति साबित नहीं करता है। सिंटैक्स, रूटिंग, प्राप्तकर्ता प्रतिक्रिया, डिलीवरी और सहमति को अलग-अलग फ़ील्ड में रखें।
प्रमाणीकरण एक अन्य प्रश्न से संबंधित है: क्या कोई संदेश विशेष डोमेन के लिए अधिकृत या हस्ताक्षरित है और क्या वे पहचान दृश्यमान लेखक डोमेन के साथ संरेखित हैं। प्राप्तकर्ता-पता सत्यापन परिणाम स्थापित नहीं होता है SPF, DKIM या DMARC एक संदेश के लिए सफलता. इसी तरह, DMARC पास इस बारे में कुछ नहीं कहता कि प्राप्तकर्ता वह संदेश चाहता था या नहीं।
संदर्भ में SMTP प्रतिक्रियाओं की व्याख्या करें
RFC 5321 SMTP लेनदेन के परिभाषित चरणों में अस्थायी नकारात्मक उत्तरों, स्थायी नकारात्मक उत्तरों और सफल उत्तरों को अलग करता है। चरण, प्रतिक्रिया और टाइमस्टैम्प रिकॉर्ड करें। एक अस्थायी प्रतिक्रिया पुनः प्रयास रणनीति को आमंत्रित करती है, तत्काल अमान्य-पता लेबल को नहीं। अकेले आरसीपीटी टीओ की स्वीकृति संपूर्ण संदेश सामग्री या इनबॉक्स में डिलीवरी के प्रमाण की स्वीकृति नहीं है।
कैच -all व्यवहार एक महत्वपूर्ण अनिश्चितता पैदा करता है। यदि दो आविष्कृत स्थानीय भागों और एक ज्ञात पते को समान प्राप्तकर्ता-चरण स्वीकृति प्राप्त होती है, तो यह सर्वर के प्रतिक्रिया पैटर्न का प्रमाण है, यह प्रमाण नहीं है कि प्रत्येक मेलबॉक्स मौजूद है। कुछ सिस्टम जानबूझकर प्राप्तकर्ता की वैधता का खुलासा करने से बचते हैं। अन्य लोग स्वीकृत संदेशों की कतार बनाते हैं और बाद में डिलीवरी विफलता उत्पन्न करते हैं। इन अवलोकनों से संपूर्ण मेलबॉक्स निर्देशिका का वादा न करें।
सत्यापन साक्ष्य तालिका का उपयोग करें
पांच काल्पनिक टिप्पणियों पर विचार करें: एक निर्दिष्ट पार्सर द्वारा वाक्यविन्यास अस्वीकृति; आरसीपीटी टू पर 550 प्रतिक्रिया; आरसीपीटी टू पर 450 प्रतिक्रिया; कई आविष्कृत स्थानीय भागों के लिए समान प्राप्तकर्ता-चरण स्वीकृति; और पूर्ण-संदेश स्वीकृति के बाद वितरण विफलता। उन्हें क्रमशः पार्सर अस्वीकृति, उस लेनदेन के लिए एक स्थायी इनकार, अस्थायी इनकार, अज्ञात मेलबॉक्स अस्तित्व के साथ देखी गई स्वीकृति, और बाद में डिलीवरी विफलता के रूप में लेबल करें। 550 अस्तित्वहीन मेलबॉक्स के बजाय नीति को प्रतिबिंबित कर सकता है। कोई भी सहमति या प्रेषक प्रमाणीकरण स्थापित नहीं करता है। ये शिक्षण इनपुट हैं, आपूर्ति किए गए परीक्षण परिणाम या निष्पादित जांच नहीं।
अधिकृत उत्पादन वर्कफ़्लो में, केवल बताए गए उद्देश्य के लिए आवश्यक न्यूनतम पते की जानकारी और प्रतिक्रिया विवरण को बनाए रखें। आक्रामक या अनचाही जांच से बचें। सहमत हों कि अज्ञात परिणाम डाउनस्ट्रीम कार्य को कैसे प्रभावित करते हैं: समीक्षा के लिए रोकें, मौजूदा संबंध के माध्यम से पुष्टि का अनुरोध करें, या ऑपरेशन रोकें। एक अनुमोदक अज्ञात-से-मान्य मानचित्रण झूठा आत्मविश्वास पैदा करता है; अज्ञात-से-अमान्य वैध संपर्कों को त्याग सकता है। उस व्यापार-बंद को हरे टिक के अंदर छिपाने के बजाय स्पष्ट बनाएं।
सटीक सीमा सुरक्षित रखें
RFC 5321 अनुभाग 3.3, 4.2.1, 4.2.5 और 6.1 लेन-देन चरणों, प्रतिक्रिया वर्गों और स्वीकृति जिम्मेदारी में अंतर करें। लौटाया गया MX मेलबॉक्स सूची नहीं है; अकेले MX की अनुपस्थिति भी कोई मेल रूट साबित नहीं करती क्योंकि धारा 5.1 अंतर्निहित MX हैंडलिंग को परिभाषित करती है। RFC 9989 धारा 4.4 और 5.3.5 प्रमाणित मूल्यांकन करें डोमेन संरेखण एक संदेश के लिए, प्राप्तकर्ता अस्तित्व के लिए नहीं। कोई लाइव जांच, भेजना या मेलबॉक्स गणना नहीं की गई थी।