डोमेन प्रमाणीकरण नीति किसी एप्लिकेशन को आपके मेल रिले का उपयोग करने के लिए अधिकृत नहीं करती है। रिले प्राधिकरण नियंत्रित करता है कि कौन मेल सबमिट कर सकता है और कहाँ जा सकता है; SPF, DKIM और DMARC प्राप्तकर्ताओं को परिणामी संदेश पहचान का मूल्यांकन करने में सहायता करें। दोनों की जरूरत है. एक मार्ग जो खूबसूरती से संकेत करता है लेकिन मनमाने प्रेषकों को स्वीकार करता है वह अभी भी परिचालन और दुरुपयोग का जोखिम है।
एक समर्थित मार्ग चुनें
एप्लिकेशन, किरायेदार, सबमिशन एंडपॉइंट, प्रमाणीकरण विधि, पहचान और प्राप्तकर्ता वर्गों से इच्छित रिकॉर्ड करें। माइक्रोसॉफ्ट क्लाइंट SMTP सबमिशन, कनेक्टर-प्रमाणीकृत SMTP रिले और डायरेक्ट सेंड को अलग करता है। इसका प्रलेखित डायरेक्ट सेंड रूट Microsoft 365 के माध्यम से इंटरनेट प्राप्तकर्ताओं को रिले नहीं करता है, जबकि समर्थित SMTP रिले कर सकता है। ये उत्पाद-विशिष्ट भेद हैं, सार्वभौमिक SMTP शब्दावली नहीं। माइक्रोसॉफ्ट एप्लिकेशन ईमेल मार्गदर्शन.
वास्तविक कार्यभार के लिए वर्तमान समर्थित विधि चुनें। किसी पुराने डिवाइस कॉन्फ़िगरेशन को किसी भिन्न टैनेंट में कॉपी करने या किसी आईपी अनुमति शर्त को एप्लिकेशन पहचान के स्थायी प्रमाण के रूप में मानने से बचें। रिकॉर्ड करें कि क्रेडेंशियल्स, प्रमाणपत्र, नेटवर्क प्रतिबंध और कनेक्टर परिवर्तन का स्वामी कौन है। केवल समस्या निवारण को सरल बनाने के लिए परीक्षण साक्ष्य में रहस्यों का खुलासा न करें या लगातार पहुंच का विस्तार न करें।
अंतिम प्रमाणीकरण से अलग सबमिशन
SMTP लेनदेन दिखाता है कि किस चरण ने कमांड को स्वीकार या अस्वीकार कर दिया है। आरसीपीटी टीओ पर अस्वीकृति संदेश डेटा के बाद विफलता से भिन्न होती है, और अंतिम सफल डेटा प्रतिक्रिया का मतलब है कि प्राप्तकर्ता ने इनबॉक्स प्लेसमेंट को साबित करने के बजाय संदेश के लिए जिम्मेदारी स्वीकार कर ली है। RFC 5321. प्रत्येक विफलता को अवरुद्ध करने के बजाय संपूर्ण उत्तर कोड, उन्नत कोड जहां मौजूद हो, टेक्स्ट और टाइमस्टैम्प को सुरक्षित रखें।
फिर उसके वास्तविक लिफाफे और हस्ताक्षरित डोमेन के लिए अधिकृत प्राप्त संदेश का निरीक्षण करें। एक रिले एक पहचान को फिर से लिख सकता है या एक हस्ताक्षर लागू कर सकता है जो इसे बदल देता है संरेखण परिणाम। SPF प्रासंगिक कनेक्टिंग रूट का मूल्यांकन करता है, न कि उपयोगकर्ता के इस विश्वास का कि प्रेषक कंपनी का है। यह न मानें कि सबमिशन की सफलता DMARC पास है या पास प्राप्तकर्ता की सहमति का प्रमाण है।
तीन काल्पनिक चरण परिणामों की तुलना करें
तीन स्वतंत्र मामलों के साथ एक लिखित स्वीकृति बही का उपयोग करें: आरसीपीटी टीओ में एक अस्वीकृत बाहरी-प्राप्तकर्ता अनुरोध को अस्वीकार किए जाने की उम्मीद है; एक अनुमोदित बाहरी मार्ग से स्वीकृत अंतिम डेटा प्रतिक्रिया तक पहुंचने की उम्मीद की जाती है; और एक अनुमोदित आंतरिक मार्ग की अलग से जाँच की जाती है। प्राप्तकर्ता के इनकार पर उदाहरणात्मक उत्तर 550 5.7.1 हो सकते हैं, या आरसीपीटी टीओ पर 250, डेटा के लिए 354 और स्वीकृत लेनदेन पर अंतिम बिंदु के बाद 250 हो सकते हैं। ये काल्पनिक उत्तर अनुक्रम हैं, कैप्चर किए गए लूपबैक या माइक्रोसॉफ्ट ट्रांसक्रिप्ट नहीं।
एक ग्राहक का EHLO नाम प्राधिकरण का प्रमाण नहीं है. वास्तविक रिले अनुमतियों को उस परिनियोजन के लिए समर्थित प्रमाणीकरण और कनेक्टर नियंत्रणों का उपयोग करना चाहिए। यहां कोई क्रेडेंशियल सत्यापन, कनेक्टर लुकअप, स्थानीय सॉकेट, TLS सत्र या प्रदाता प्रेषण निष्पादित नहीं किया गया था। इन अपेक्षित उदाहरणों को देखे गए परिणामों के रूप में मानने के बजाय भविष्य में अधिकृत परीक्षण में वास्तविक प्रतिक्रिया कोड और संदर्भ रिकॉर्ड करें।
स्वीकृत और अस्वीकृत दोनों मामलों का परीक्षण करें
स्वीकृत परिनियोजन के लिए, इच्छित आंतरिक और बाह्य पथों का परीक्षण करने के लिए नियंत्रित प्राप्तकर्ताओं का उपयोग करें। किसी क्लाइंट से स्पष्ट रूप से अधिकृत नकारात्मक परीक्षण शामिल करें जिसे असंबंधित सिस्टम की जांच किए बिना रिले नहीं किया जाना चाहिए। मूल साक्ष्य को अभिगम नियंत्रण में रखते हुए साफ-सुथरी प्रतिलेख और प्रदाता लॉग को बनाए रखें। पुष्टि करें कि इनकार वहीं होता है जहां अपेक्षित होता है और वैकल्पिक आवेदन मार्ग के माध्यम से इसे दरकिनार नहीं किया जा सकता है।
महत्वपूर्ण वर्कफ़्लो रिले पर निर्भर होने से पहले थ्रॉटलिंग, कतार व्यवहार की जाँच करें और स्वामित्व का पुनः प्रयास करें। एक क्षणिक इनकार के कारण तेजी से पुनः प्रयास का तूफान नहीं आना चाहिए, जबकि एक स्थायी कॉन्फ़िगरेशन विफलता के लिए जवाबदेह मरम्मत की आवश्यकता होती है। अप्रतिबंधित बाईपास को अधिकृत किए बिना दस्तावेज़ फ़ॉलबैक आवश्यकताएँ।
रिले एक्सेस, समर्थित प्राप्तकर्ता स्कोप, अंतिम संदेश प्रमाणीकरण और एप्लिकेशन की सफलता के लिए अलग-अलग परिणामों के साथ परिवर्तन को बंद करें। लुप्त अवलोकनों को अनसुलझे के रूप में चिह्नित करें। यह किसी टीम को एप्लिकेशन को केवल इसलिए कार्यशील घोषित करने से रोकता है क्योंकि DNS सही दिखता है या एक SMTP कमांड ने एक सफल कोड लौटाया है।
स्रोत और निष्पादन सीमा
RFC 9989 अनुभाग 4.4, 5.3.5 और 5.4 प्रमाणीकरण, संरेखण और हैंडलिंग में अंतर कर सकेंगे; पास संदेश सामग्री का समर्थन नहीं करता. यहां परिचालन संबंधी निर्णय व्यापक अनुशंसाएं और स्पष्ट रूप से काल्पनिक उदाहरण हैं, न कि किसी ग्राहक, प्रदाता या ऐतिहासिक स्थिरता के नए परीक्षण। किसी भी वास्तविक परिवर्तन के लिए अपने स्वयं के अधिकृत दायरे, रखे गए साक्ष्य और जवाबदेह निर्णय की आवश्यकता होती है।