MTA-STS और TLS-RPT सेटअप करने की गाइड

ईमेल सुरक्षा के लिए MTA-STS और TLS-RPT कैसे सेट अप करें

MTA-STS से ईमेल पाने वाला डोमेन, ईमेल भेजने वाले सिस्टम को बता सकता है कि उसके संदेश किन मेल सर्वरों पर स्वीकार किए जाने चाहिए और इन सर्वरों से कनेक्शन के लिए भरोसेमंद TLS का इस्तेमाल ज़रूरी है। TLS-RPT रिपोर्टिंग की सुविधा देता है: इसमें भाग लेने वाले ईमेल प्रेषक आपको TLS के ज़रिए डिलीवरी में आई विफलताओं और नीति से जुड़ी समस्याओं की जानकारी भेज सकते हैं। अगर आप जानना चाहते हैं कि MTA-STS कैसे सेट अप करें, तो DNS रिकॉर्ड से नहीं, बल्कि अपने इनकमिंग मेल कॉन्फ़िगरेशन से शुरुआत करें।

ये नियंत्रण SPF, DKIM या DMARC की जगह नहीं लेते। ये ईमेल के सफ़र के एक अलग हिस्से को सुरक्षित करते हैं: मेल सर्वरों के बीच एन्क्रिप्टेड कनेक्शन को। अगर नीति में किसी पुराने या गलत तरीके से कॉन्फ़िगर किए गए MX होस्ट का नाम शामिल है, तो ईमेल डिलीवरी बाधित हो सकती है। इसलिए इसे लागू करने से पहले पूरा सेटअप जाँच लें।

1. पुष्टि करें कि आपकी मेल-होस्टिंग तैयार है

सबसे पहले डोमेन के मौजूदा MX रिकॉर्ड देखें। उन सभी होस्टनामों की सूची बनाएँ जिन पर ये रिकॉर्ड निर्देशित करते हैं—इसमें बैकअप या क्षेत्रीय डिलीवरी के लिए इस्तेमाल होने वाले होस्ट भी शामिल करें। अगर आपका इनकमिंग मेल प्रदाता संभालता है, तो उससे पुष्टि करें कि MTA-STS नीति में किन MX नामों को शामिल करना है और क्या हर होस्ट वैध प्रमाणपत्र के साथ TLS का समर्थन करता है।

सिर्फ़ प्रदाता का ब्रांड नहीं, होस्टनाम जाँचें। किसी डोमेन के MX रिकॉर्ड में mx1.mail.example.com और mx2.mail.example.com जैसे नाम हो सकते हैं, जबकि उसका प्रदाता दूसरे होस्ट भी चलाता हो, जो उस डोमेन के लिए सूचीबद्ध नहीं हैं। आपकी नीति में उन MX होस्टनामों को शामिल होना चाहिए जो आपके डोमेन के लिए मेल प्राप्त कर सकते हैं।

सूची में शामिल हर होस्ट का प्रमाणपत्र और TLS कॉन्फ़िगरेशन जाँचें। प्रमाणपत्र भरोसेमंद और उस MX होस्टनाम के लिए वैध होना चाहिए जिससे भेजने वाला मेल सिस्टम कनेक्ट करता है। प्रदाता की वेबसाइट के लिए मान्य प्रमाणपत्र, अगर उसके मेल होस्ट को कवर नहीं करता, तो उसका विकल्प नहीं हो सकता।

अपने मेल प्रदाता से आने वाले होस्ट बदलावों के बारे में भी पूछें। अगर सेटअप के दौरान कोई MX होस्टनाम बदलने वाला है, तो अंतिम सूची मिलने तक इंतज़ार करें या प्रदाता के साथ मिलकर नीति अपडेट करने की योजना बनाएँ। लागू की गई नीति को किसी भेजने वाले सिस्टम ने कैश कर लिया हो, तो सूची में शामिल न किया गया नया होस्ट डिलीवरी में समस्या पैदा कर सकता है।

2. TLS-RPT रिपोर्ट पाने का पता प्रकाशित करें

DNS रिकॉर्ड प्रकाशित करने से पहले तय करें कि रिपोर्ट कहाँ भेजी जानी चाहिए। आप ऐसा मेलबॉक्स इस्तेमाल कर सकते हैं जो रिपोर्ट स्वीकार करता हो, या ऐसी TLS रिपोर्टिंग सेवा चुन सकते हैं जो आपको ईमेल पता या HTTPS डेस्टिनेशन देती हो। TLS-RPT डीएनएस रिकॉर्ड कैसे बनाएँ, इसकी शुरुआत भी रिपोर्ट के डेस्टिनेशन को तय करने से होती है। पुष्टि करें कि कोई इस डेस्टिनेशन की निगरानी करता है और आपका मेल सिस्टम वहाँ आने वाली रिपोर्ट स्वीकार करेगा।

_smtp._tls.example.com पर TXT रिकॉर्ड प्रकाशित करें और example.com की जगह अपना डोमेन डालें। मेल डेस्टिनेशन के लिए वैल्यू का फ़ॉर्मैट इस तरह होगा: v=TLSRPTv1; rua=mailto:tls-reports@example.com। अगर आपकी रिपोर्टिंग सेवा कोई दूसरा डेस्टिनेशन देती है, तो उसका दिया हुआ सटीक URI इस्तेमाल करें।

हो सके तो इस मेलबॉक्स को किसी व्यक्ति के रोज़मर्रा के इनबॉक्स से अलग रखें। TLS रिपोर्ट में संरचित अटैचमेंट आ सकते हैं। एक अलग मेलबॉक्स से ऐक्सेस नियम तय करना, संदेशों को सुरक्षित रखना और समीक्षा की ज़िम्मेदारी मेल डिलीवरी के प्रशासक को देना आसान हो जाता है। रिकॉर्ड प्रकाशित करने से पहले इसकी स्टोरेज और फ़िल्टरिंग सेटिंग जाँच लें।

DNS बदलाव दिखने में समय लग सकता है, क्योंकि रिज़ॉल्वर TTL के अनुसार रिकॉर्ड कैश करते हैं। रिकॉर्ड प्रकाशित करने के बाद, ऑथोरिटेटिव DNS सेवा और किसी सार्वजनिक रिज़ॉल्वर से क्वेरी करके पुष्टि करें कि दोनों सही TXT वैल्यू लौटा रहे हैं। रिकॉर्ड के नाम में टाइपिंग की गलती होने पर भेजने वाले सिस्टम को डेस्टिनेशन दिखाई नहीं देगा।

3. MTA-STS नीति फ़ाइल होस्ट करें

नीति को https://mta-sts.example.com/.well-known/mta-sts.txt पर रखें और example.com की जगह अपना डोमेन डालें। यह URL HTTPS पर उपलब्ध होना चाहिए और इसका प्रमाणपत्र mta-sts.example.com होस्टनाम के लिए वैध होना चाहिए। वेबसाइट के सामान्य होमपेज वाले पाथ पर रखी फ़ाइल इस ज़रूरत को पूरा नहीं करेगी।

नीति एक सादा टेक्स्ट फ़ाइल होती है। शुरुआती परीक्षण के लिए इसमें इस तरह की फ़ील्ड इस्तेमाल करें:

• version: STSv1
• mode: testing
• mx: mx1.mail.example.com
• mx: mx2.mail.example.com
• max_age: 86400

नमूने में दिए MX नामों की जगह अपने डोमेन के असली इनकमिंग होस्ट डालें। max_age वह सेकंड की संख्या है, जितने समय तक भेजने वाला सिस्टम नीति को कैश कर सकता है; ऊपर दिया गया उदाहरण एक दिन का है। शुरुआत में कम अवधि रखने से परीक्षण नीति में बदलाव करना आसान हो सकता है, जबकि ज़्यादा अवधि रखने पर भेजने वाले इसे लंबे समय तक कैश कर सकते हैं।

लागू करने से पहले testing मोड इस्तेमाल करें। इस मोड में, भेजने वाले नीति की विफलताओं की रिपोर्ट कर सकते हैं, लेकिन वे नीति को इस निर्देश के रूप में नहीं मानते कि ज़रूरी TLS शर्तों के तहत डिलीवर न हो सकने वाले मेल को अस्वीकार कर दिया जाए। अपने नेटवर्क के बाहर से URL जाँचें और सुनिश्चित करें कि लॉगिन, रीडायरेक्ट लूप या वेब ऐप्लिकेशन की गड़बड़ी के बिना फ़ाइल मिल रही है।

4. MTA-STS डिस्कवरी रिकॉर्ड प्रकाशित करें

भेजने वाले _mta-sts.example.com पर मौजूद TXT रिकॉर्ड के ज़रिए नीति खोजते हैं। इसकी वैल्यू में वर्ज़न और नीति पहचानकर्ता शामिल होता है, उदाहरण के लिए: v=STSv1; id=20261104a। ऐसा पहचानकर्ता चुनें जिसे आप अपने बदलावों के लॉग में दर्ज कर सकें; पुरानी वैल्यू दोबारा इस्तेमाल न करें।

जब भी संशोधित नीति फ़ाइल प्रकाशित करें, पहचानकर्ता बदलें। इससे भेजने वाले सिस्टम को पता चलता है कि उन्हें कैश की गई प्रति पर निर्भर रहने के बजाय अपडेट की गई नीति जाँचनी चाहिए। पहचानकर्ता नीति खोजने का संकेत है; यह नीति फ़ाइल या उसकी HTTPS होस्टिंग की जगह नहीं लेता।

नीति फ़ाइल ज़रूरी URL पर उपलब्ध होने के बाद ही रिकॉर्ड प्रकाशित करें। फिर TXT रिकॉर्ड की क्वेरी करें और बाहरी कनेक्शन से URL खोलें। DNS रिकॉर्ड और फ़ाइल, दोनों में मौजूदा सेटअप का एक जैसा विवरण होना चाहिए: नया पहचानकर्ता अगर किसी गुम या पुरानी फ़ाइल की ओर संकेत करता है, तो सेटअप फिर भी टूटा हुआ है।

5. डिस्कवरी, नीति और MX कवरेज जाँचें

हर हिस्से को अलग-अलग सत्यापित करें। _smtp._tls और _mta-sts TXT रिकॉर्ड की क्वेरी करें, HTTPS पर नीति URL खोलें और हर mx: लाइन की तुलना अपने लाइव MX रिकॉर्ड से करें। इन तीनों की जाँच से ऐसी गलतियाँ पकड़ में आती हैं जिन्हें सिर्फ़ DNS लुकअप से नहीं ढूँढ़ा जा सकता।

पुष्टि करें कि HTTPS रिस्पॉन्स में MTA-STS होस्टनाम के लिए भरोसेमंद प्रमाणपत्र है और फ़ाइल में अपेक्षित फ़ील्ड मौजूद हैं। फिर हर MX होस्ट के लिए TLS सपोर्ट और उसी होस्ट के नाम पर वैध प्रमाणपत्र जाँचें। अगर आपके प्रदाता के कई इनकमिंग MX नाम हैं, तो हर एक का परीक्षण करें—यह न मानें कि सबका प्रमाणपत्र कॉन्फ़िगरेशन एक जैसा होगा।

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

6. नीति लागू करने से पहले रिपोर्टों की समीक्षा करें

TLS-RPT की प्रतिक्रियाएँ जुटाने और सामान्य मेल प्रवाह की जाँच करने के दौरान नीति को testing मोड में रखें। रिपोर्टों से पता चल सकता है कि भेजने वाले सिस्टम को प्रमाणपत्र की समस्या, TLS नेगोशिएशन में गड़बड़ी या आपके बताए MX होस्ट और नीति के बीच बेमेल का सामना करना पड़ा। रिपोर्ट जाँच करने के लिए सबूत है—DNS रिकॉर्ड बदलने का अपने-आप मिलने वाला निर्देश नहीं।

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

उन मेल सिस्टम से भी डिलीवरी जाँचें जिन पर आपका संगठन निर्भर करता है—जैसे कोई व्यावसायिक साझेदार या आपकी अपनी कोई अलग सेवा। पुष्टि करें कि संदेश पहुँच रहे हैं और आपके इनकमिंग लॉग में TLS कनेक्शन सफल दिख रहे हैं। रिपोर्ट वाला मेलबॉक्स खाली होने भर से यह साबित नहीं होता कि हर भेजने वाले ने आपकी नीति जाँची है।

ऐसी तय समीक्षा अवधि रखें जो आपके मेल वॉल्यूम और कामकाज की ज़रूरतों के मुताबिक हो। रिपोर्ट में हर भेजने वाला सिस्टम दिखाई देने की गारंटी देने वाले दिनों की कोई तय संख्या नहीं है, इसलिए किसी खास कैलेंडर अवधि को कवरेज का प्रमाण न मानें। दर्ज करें कि आपने क्या जाँचा और परीक्षण के दौरान किन ज्ञात भेजने वालों ने सफलतापूर्वक मेल पहुँचाया।

7. सेटअप लागू करें, निगरानी करें और बनाए रखें

जब MX सूची, प्रमाणपत्र, HTTPS नीति और परीक्षण के नतीजे तैयार हों, तो नीति का मोड testing से बदलकर enforce करें। बदली हुई नीति फ़ाइल और नया _mta-sts पहचानकर्ता प्रकाशित करें। अपडेट के बाद अपने नेटवर्क के बाहर से दोनों की जाँच करें, फिर TLS-RPT रिपोर्ट और मेल-फ़्लो लॉग देखते रहें।

लागू होने पर, MTA-STS का समर्थन करने वाले भेजने वाले सिस्टम से अपेक्षा की जाती है कि वे TLS का इस्तेमाल करें और नीति के अनुसार प्राप्तकर्ता होस्ट की पुष्टि करें। अगर वे ऐसा नहीं कर पाते, तो असुरक्षित कनेक्शन पर मेल भेजने के बजाय दोबारा कोशिश करते समय डिलीवरी में देर हो सकती है। बदलाव से पहले अपने मेल प्रदाता और सपोर्ट टीम को इसकी जानकारी दें, ताकि उन्हें पता हो कि डिलीवरी में देरी की जाँच कैसे करनी है।

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

रिपोर्टिंग मेलबॉक्स या सेवा की समीक्षा करने और DNS व प्रमाणपत्र में बदलावों पर नज़र रखने के लिए किसी व्यक्ति को ज़िम्मेदार ठहराएँ। अगर आप सहकर्मियों के लिए कामकाज से जुड़े नोट या मेल सेवा अपडेट प्रकाशित करते हैं, तो वे YourTrend की ब्लॉग फ़ीड भी फ़ॉलो कर सकते हैं। किसी ज़िम्मेदार व्यक्ति का नाम तय करने और MX बदलाव की प्रक्रिया दर्ज करने से अगले नवीनीकरण या प्रदाता माइग्रेशन को संभालना आसान हो जाता है।