MTA-STS प्राप्तकर्ता डोमेन को प्रमाणित TLS डिलीवरी के लिए अपेक्षाएँ प्रकाशित करने देता है। यह प्राप्तकर्ता सेवा से SMTP कनेक्शन को संबोधित करता है। यह संदेश लेखक के प्रेषक पते को प्रमाणित नहीं करता है या संदेश को एक व्यक्ति के डिवाइस से दूसरे व्यक्ति तक एन्क्रिप्ट नहीं करता है।
एक कार्यशील परिनियोजन तीन चीज़ों को जोड़ता है: डोमेन का वास्तविक इनबाउंड MX मार्ग, HTTPS नीति और DNS रिकॉर्ड जो उस नीति का संकेत देता है। TLS रिपोर्टिंग एक अलग फीडबैक पथ प्रदान करती है।
वास्तविक प्राप्त सीमा स्थापित करें
सन्दर्भ: RFC 8461 §3.4, RFC 8461 §4.
उन MX होस्टों की सूची बनाएं जो बैकअप सेवाओं और अपस्ट्रीम सुरक्षा गेटवे सहित डोमेन के लिए मेल स्वीकार करते हैं। केवल आंतरिक मेलबॉक्स सर्वर पर ही नहीं, बल्कि वास्तविक सार्वजनिक प्राप्त सीमा पर TLS और प्रमाणपत्र व्यवहार को सत्यापित करें।
रिकॉर्ड करें कि MX रूट, पॉलिसी होस्टिंग, प्रमाणपत्र नवीनीकरण और रिपोर्टिंग गंतव्य का मालिक कौन है। एक होस्टेड मेलबॉक्स सेवा आवश्यक रूप से ग्राहक की MTA-STS नीति को होस्ट नहीं करती है या उसके सामने प्रत्येक गेटवे को संचालित नहीं करती है।
उपडोमेन का अलग से आकलन करें. MTA-STS डीएमएआरसी-शैली पैरेंट-पॉलिसी इनहेरिटेंस का उपयोग नहीं करता है। प्राप्तकर्ता उपडोमेन को उस डोमेन पर लागू कॉन्फ़िगरेशन की आवश्यकता होती है।
वास्तविक मेज़बानों के लिए एक नीति बनाएं
सन्दर्भ: RFC 8461 §3.2, RFC 8461 §3.3.
प्राप्तकर्ता डोमेन के लिए आवश्यक HTTPS स्थान से पॉलिसी प्रस्तुत करें। example.com के लिए, स्थान https://mta-sts.example.com/.well-known/mta-sts.txt. HTTPS सेवा को अपनी पॉलिसी होस्टनाम के लिए एक वैध प्रमाणपत्र की आवश्यकता है।
नीति इसके संस्करण, मोड, अनुमत MX पैटर्न और अधिकतम कैश जीवनकाल की पहचान करती है। एक दायरे-उपयुक्त परीक्षण परिनियोजन के साथ प्रारंभ करें और प्रवर्तन से पहले परिणामों का निरीक्षण करें। नमूना अवधि को सार्वभौमिक प्रमाण मानने के बजाय वास्तविक ट्रैफ़िक और निर्भरता से अवलोकन अवधि चुनें।
काल्पनिक सिंगल-एमएक्स डोमेन के लिए एक उदाहरणात्मक नीति है:
संस्करण: STSv1 मोड: परीक्षण mx: mx1.example.net max_age: 86400यह उदाहरण मानता है कि mx1.example.net डोमेन का वास्तविक प्राप्तकर्ता होस्ट है और उसके पास उपयुक्त SMTP TLS समर्थन है। यह किसी अन्य प्रदाता के लिए तैयार नीति नहीं है। अनुमति प्राप्त मेजबानों का सटीक मिलान करें और प्रत्येक वैध प्राप्तकर्ता मार्ग को शामिल करें।
खोज और रिपोर्टिंग को अलग-अलग प्रकाशित करें
सन्दर्भ: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
_mta-sts.example.com पर, एक उदाहरणात्मक TXT मान v=STSv1; id=2026110701. पहचानकर्ता नीति संशोधन का संकेत देता है। DNS में इसके नए संशोधन का विज्ञापन करने से पहले नीति को प्रकाशित और सत्यापित करें।
TLS-RPT _smtp._tls.example.com पर अपने स्वयं के रिकॉर्ड का उपयोग करता है। एक उदाहरणात्मक अनुरोध v=TLSRPTv1; rua=mailto:tls-reports@example.com, यह मानते हुए कि पता मौजूद है और इसका संग्रह पथ काम करता है।
ऐसा मत मानिए DMARC आरयूए गंतव्य स्वचालित रूप से TLS रिपोर्ट प्राप्त करता है, या MTA-STS परीक्षण अकेले एक कार्यशील रिपोर्टिंग अनुरोध बनाता है। प्रत्येक रिकॉर्ड को सही नाम और प्रत्येक गंतव्य पर अपनी संग्रह प्रक्रिया के माध्यम से सत्यापित करें।
तैनात श्रृंखला का परीक्षण करें
सन्दर्भ: RFC 8461 §4, RFC 8461 §6.
नीति को बाहरी रूप से प्राप्त करें और पुष्टि करें कि आवश्यक HTTPS एंडपॉइंट HTTP 200 के साथ इच्छित सादे-पाठ निकाय को कार्यान्वित करता है। HTTP रीडायरेक्ट का पालन न करें: RFC 8461 §3.3 के तहत रीडायरेक्ट एक वैध पॉलिसी फ़ेच नहीं है। डिस्कवरी DNS जांच करें और सभी विज्ञापित MX मार्गों की अनुमत पैटर्न के साथ तुलना करें।
प्रत्येक प्राप्त मार्ग पर SMTP TLS और प्रमाणपत्र सत्यापन का परीक्षण करें। mta-sts.example.com पर एक कार्यशील वेब प्रमाणपत्र यह स्थापित नहीं करता है कि MX सर्वर एक वैध SMTP प्रमाणपत्र प्रस्तुत करता है।
उपलब्ध TLS रिपोर्ट और नियंत्रित डिलीवरी साक्ष्य की समीक्षा करें। सेवाएँ भेजने में भागीदारी अलग-अलग होती है, इसलिए चुप्पी सार्वभौमिक सफलता स्थापित नहीं करती है। प्रत्येक अवलोकन के साथ रिपोर्टर, अंतराल और प्रभावित MX रखें।
सिंथेटिक मामले में, एक नीति केवल मुख्य गेटवे की अनुमति देती है जबकि DNS बैकअप MX भी विज्ञापन करता है। बैकअप सामान्य परीक्षणों में मेल स्वीकार करता है लेकिन नीति मिलान में विफल रहता है। प्रवर्तन से पहले नीति या रूटिंग डिज़ाइन की मरम्मत करें; बैकअप को ख़ारिज न करें क्योंकि इसकी दैनिक मात्रा छोटी है।
कैश के आसपास प्रवर्तन और पुनर्प्राप्ति की योजना बनाएं
सन्दर्भ: RFC 8461 §5, RFC 8461 §8.3.
एनफोर्स मोड सहायक प्रेषकों को गैर-अनुपालक कनेक्शन के माध्यम से डिलीवरी करने से रोक सकता है। गैर-समर्थन करने वाले प्रेषक उस आश्वासन से बाहर हैं। मोड बदलने से पहले निर्भरता और स्वीकार्य परिचालन प्रतिक्रिया रिकॉर्ड करें।
प्रेषक कैश अपनी अधिकतम आयु के लिए वैध पिछली नीतियों को बनाए रख सकते हैं। डिस्कवरी DNS को हटाना या HTTPS एंडपॉइंट को हटाना तत्काल वैश्विक रोलबैक नहीं है। निकासी के लिए, एक वैध मोड प्रकाशित करें: कम जीवनकाल वाली कोई भी पॉलिसी नहीं, फिर डिस्कवरी आईडी को अपडेट करें। दोनों अंतिम बिंदुओं को तब तक उपलब्ध रखें जब तक कि पिछली सभी पॉलिसियाँ समाप्त न हो जाएँ, जिनमें लंबे जीवनकाल वाले पुराने संशोधन भी शामिल हैं। प्रत्येक जीवनकाल की गणना उस समय से करें जब वह संशोधन अंतिम बार प्रस्तुत किया गया था, न कि केवल अगले संपादन से।
गेटवे माइग्रेशन के लिए, नीति को नियोजित ट्रांज़िशन के अनुकूल बनाएं, नए रूट को सत्यापित करें और कैश्ड संस्करणों की अनुमति दें। नीति समापन बिंदु को उपलब्ध रखें जबकि प्रासंगिक प्रेषक अभी भी उस पर भरोसा कर सकते हैं।
हैंडओवर में MX कॉन्फ़िगरेशन, पॉलिसी इतिहास, प्रमाणपत्र स्वामित्व और रिपोर्ट हैंडलिंग शामिल होनी चाहिए। MTA-STS तब उपयोगी रहता है जब उन गतिशील हिस्सों को एक साथ बनाए रखा जाता है।