2. एमटीए-एसटीएस नीति बनाना

हर डोमेन के लिए नीति बनाकर और उसे पब्लिश करके, अपने डोमेन के लिए MTA-STS सेट अप करें. इस नीति से, डोमेन में मौजूद उन मेल सर्वर के बारे में पता चलता है जो MTA-STS का इस्तेमाल करते हैं.

हर डोमेन के लिए, नीति की अलग फ़ाइल होनी चाहिए. नीतियां एक जैसी हो सकती हैं, लेकिन एमटीए-एसटीएस का इस्तेमाल करके, उन्हें हर डोमेन के लिए अलग-अलग होस्ट किया जाना चाहिए.

एमटीए-एसटीएस के लिए सर्वर से जुड़ी ज़रूरी शर्तें

आने वाले ईमेल पाने वाले मेल सर्वर के लिए, यहां दी गई जानकारी की पुष्टि करें:

  • इनके लिए, मेल को सुरक्षित (टीएलएस) कनेक्शन से भेजना ज़रूरी है.
  • वे TLS 1.2 या इसके बाद के वर्शन का इस्तेमाल करते हों
  • सर्वर के टीएलएस सर्टिफ़िकेट:
    • इनबाउंड मेल सर्वर (आपके MX रिकॉर्ड में मौजूद सर्वर) के इस्तेमाल किए गए डोमेन नेम से मेल खाना चाहिए.
    • इन पर रूट सर्टिफ़िकेट देने वाली संस्था के हस्ताक्षर होते हैं और ये भरोसेमंद होती हैं.
    • उनकी समयसीमा खत्म न हुई हो.

टीएलएस सर्टिफ़िकेट के बारे में ज़्यादा जानने के लिए, सुरक्षित ट्रांसपोर्ट (टीएलएस) के लिए Google Workspace सर्टिफ़िकेट का इस्तेमाल करना लेख पढ़ें.

एमटीए-एसटीएस नीति के मोड

एमटीए-एसटीएस नीति को टेस्टिंग मोड या लागू करने के मोड में सेट अप किया जा सकता है.

टेस्टिंग मोड

टेस्टिंग मोड में, बाहरी मेल सर्वर से हर दिन रिपोर्ट भेजने का अनुरोध किया जाता है. इन रिपोर्ट में, आपके डोमेन से कनेक्ट करते समय मिली समस्याओं के बारे में जानकारी होती है. रिपोर्ट में, MTA-STS की नीतियों, ट्रैफ़िक के आंकड़ों, कनेक्ट न हो पाने की वजहों, और न भेजे गए मैसेज की जानकारी शामिल होती है.

टेस्टिंग मोड में, आपका डोमेन सिर्फ़ रिपोर्ट का अनुरोध करता है. यह मोड, MTA-STS के लिए ज़रूरी कनेक्शन सुरक्षा को लागू नहीं करता. हमारा सुझाव है कि आप दो हफ़्तों के लिए टेस्टिंग मोड का इस्तेमाल करें. आपके डोमेन से जुड़ी किसी भी समस्या के बारे में जानने और उसे ठीक करने के लिए, रिपोर्ट का दो हफ़्ते का डेटा काफ़ी होता है.

हर दिन मिलने वाली रिपोर्ट में मौजूद जानकारी का इस्तेमाल करके, अपने सर्वर या डोमेन से जुड़ी एन्क्रिप्शन या सुरक्षा से जुड़ी अन्य समस्याओं को हल करें. इसके बाद, नीति को लागू करने के मोड में बदलें.

लागू करने का मोड

नीति के लागू होने पर, आपका डोमेन बाहरी सर्वर से यह पुष्टि करने का अनुरोध करता है कि एसएमटीपी कनेक्शन एन्क्रिप्ट (सुरक्षित) किया गया है और उसकी पुष्टि की गई है.

अगर कनेक्शन एन्क्रिप्ट (सुरक्षित) नहीं किया गया है और इसकी पुष्टि नहीं की गई है, तो:

  • MTA-STS के साथ काम करने वाले सर्वर, आपके डोमेन पर ईमेल नहीं भेजेंगे.
  • जिन सर्वर पर MTA-STS प्रोटोकॉल काम नहीं करता वे आपके डोमेन पर, सामान्य तरीके से एसएमटीपी कनेक्शन के ज़रिए ईमेल भेजते रहते हैं. ऐसा हो सकता है कि ये एसएमटीपी कनेक्शन एन्क्रिप्ट न किए गए हों.

लागू करने के मोड में, आपको बाहरी सर्वर से रोज़ाना रिपोर्ट मिलती रहेंगी.

नीति फ़ाइल बनाना

नीति फ़ाइल एक सामान्य टेक्स्ट फ़ाइल होती है. इसमें कुंजी और वैल्यू के जोड़े होते हैं. हर जोड़े को टेक्स्ट फ़ाइल में अलग लाइन पर होना चाहिए. यहां दिए गए उदाहरण में दिखाया गया है. नीति के टेक्स्ट वाली फ़ाइल का साइज़ 64 केबी तक हो सकता है.

नीति की फ़ाइल का नाम: टेक्स्ट फ़ाइल का नाम mta-sts.txt होना चाहिए

नीति फ़ाइलें अपडेट करना: जब भी मेल सर्वर जोड़े या बदले जाएं या डोमेन बदला जाए, तब नीति फ़ाइल को अपडेट करें.

नीति फ़ाइल का फ़ॉर्मैट: version फ़ील्ड, नीति की पहली लाइन में होना चाहिए. अन्य फ़ील्ड किसी भी क्रम में हो सकते हैं. नीति फ़ाइल का एक उदाहरण यहां दिया गया है:

version: STSv1
mode: testing
mx: mail.solarmora.com
mx: *.solarmora.net
mx: backupmx.solarmora.com
max_age: 604800

नीति फ़ाइल का कॉन्टेंट: नीति में ये सभी मुख्य और वैल्यू पेयर शामिल होने चाहिए. अपने डोमेन के लिए, ज़रूरत के मुताबिक बनाई गई नीति पाने के लिए, एमटीए-एसटीएस की स्थिति देखें और सुझाए गए कॉन्फ़िगरेशन पाएं में दिया गया तरीका अपनाएं.

कुंजी वैल्यू
version प्रोटोकॉल वर्शन. STSv1 होना चाहिए
mode

नीति मोड:

  • जांच: बाहरी सर्वर, आपके डोमेन से कनेक्ट करते समय एन्क्रिप्शन और अन्य समस्याओं के बारे में रिपोर्ट भेजते हैं. MTA-STS एन्क्रिप्शन और पुष्टि करने की ज़रूरी शर्तों को लागू नहीं किया जाता

  • लागू करें: अगर SMTP कनेक्शन में पुष्टि करने और एन्क्रिप्ट (सुरक्षित) करने की सुविधा नहीं है, तो MTA-STS के लिए सेट अप किए गए मेल सर्वर, आपके डोमेन को ईमेल नहीं भेजेंगे. आपको कनेक्शन से जुड़ी समस्याओं के बारे में बाहरी सर्वर से भी रिपोर्ट मिलती हैं. ऐसा टेस्टिंग मोड में होता है.

  • none: इससे बाहरी सर्वर को पता चलता है कि आपका डोमेन अब MTA-STS के साथ काम नहीं करता. अगर आपको MTA-STS का इस्तेमाल बंद करना है, तो इस वैल्यू का इस्तेमाल करें. MTA-STS (RFC 8461) हटाने के बारे में जानें.

mx

डोमेन के लिए MX रिकॉर्ड.

  • नीति में, डोमेन में जोड़े गए हर MX रिकॉर्ड के लिए mx एंट्री होनी चाहिए.
  • नीति फ़ाइल में, हर mx एंट्री अपनी लाइन में होनी चाहिए. उदाहरण में दिखाया गया है कि इसे कैसे लिखा जाता है.
  • मेल सर्वर का नाम, स्टैंडर्ड सब्जेक्ट ऑल्टरनेटिव नेम (एसएएन) फ़ॉर्मैट में होना चाहिए.
  • mx वैल्यू, इन उदाहरणों में दिखाए गए फ़ॉर्मैट में से किसी एक में होनी चाहिए:

    स्टैंडर्ड MX फ़ॉर्म में एक सर्वर तय करें: alt1.aspmx.solarmora.com

    नाम के पैटर्न से मेल खाने वाले सर्वर तय करने के लिए, वाइल्डकार्ड का इस्तेमाल करें. वाइल्डकार्ड वर्ण, सिर्फ़ सबसे बाईं ओर मौजूद एक लेबल की जगह इस्तेमाल किया जाता है. उदाहरण के लिए: *.solarmora.com

MX रिकॉर्ड और MX रिकॉर्ड की वैल्यू के बारे में ज़्यादा जानें.

max_age

नीति के मान्य रहने की ज़्यादा से ज़्यादा अवधि, सेकंड में. जब भी कोई बाहरी सर्वर नीति की जांच करता है, तब उसके लिए max_age रीसेट हो जाता है. इसलिए, बाहरी सर्वर के लिए एक ही नीति की समयसीमा खत्म होने की तारीखें अलग-अलग हो सकती हैं.

वैल्यू, 86400 (एक दिन) और 31557600 (लगभग एक साल) के बीच होनी चाहिए.

हमारा सुझाव है कि टेस्टिंग मोड के लिए, 604800 से 1209600 (एक से दो हफ़्ते) के बीच का समय चुनें.

अगले चरण

MTA-STS नीति पब्लिश करना