👨🏾‍🚒 🎟️ 📄 पोस्टफिक्स के लिए एमटीए-एसटीएस 👩🏼‍🌾 ‼️ 📻

MTA-STS प्रस्तावित RFC8461 मानक है जो मसौदा स्थिति से बाहर हो गया है और आधिकारिक तौर पर 26 सितंबर, 2018 को प्रकाशित किया गया है। यह मानक डेटा एन्क्रिप्शन और सर्वर प्रमाणीकरण के साथ मेल सर्वर के बीच पूर्ण टीएलएस का उपयोग करने की संभावना का पता लगाने के लिए एक तंत्र प्रदान करता है। यही है, यह मानक लगभग पूरी तरह से सर्वर के बीच मेल यातायात के साथ हस्तक्षेप से बचाता है।

सरलीकृत, मानक का सार इस प्रकार है:

मेल सेवाओं का समर्थन एक नीति (प्रत्येक डोमेन के लिए 1 TXT रिकॉर्ड और 1 HTTPS संसाधन) प्रकाशित करता है।
अन्य डोमेन को मेल भेजते समय मेल सेवाएं प्राप्तकर्ता डोमेन नीति का पता लगाती हैं।
मेल सेवाएँ प्राप्तकर्ता डोमेन के मेल सर्वर से जुड़ती हैं, यदि कोई हो, तो निर्धारित नीति द्वारा निर्धारित टीएलएस प्रतिबंधों को लागू करना।

अच्छे लेख हैं ( उदाहरण के लिए ) जो मानक के बारे में बात करते हैं और इसकी आवश्यकता क्यों है, एमटीए-एसटीएस की अन्य समान पहलों के साथ तुलना करना और यहां तक कि यह भी दिखाना कि नीति कैसे लिखना और प्रकाशित करना है। लेकिन पहले कदम से आगे जाने का तरीका खोजना इतना सरल नहीं था।

शुरू करो

एमटीए-एसटीएस को लागू करने से पहले, आपको मेल सर्वर प्रमाणपत्रों को साफ करना होगा। अन्यथा, आपकी एसटीएस नीति को ध्यान में रखने वाले मेल सर्वर आपके सर्वर से कनेक्शन को अस्वीकार कर देंगे। निम्नलिखित शर्तों को पूरा किया जाना चाहिए:

सर्वर प्रमाणपत्र किसी मान्यताप्राप्त प्रमाणन प्राधिकरण द्वारा जारी किया जाता है (चलो एनक्रिप्ट अच्छा है)।
सर्वर द्वारा भेजी गई प्रमाणपत्र श्रृंखला में मध्यवर्ती प्रमाणीकरण अधिकारियों के सभी आवश्यक प्रमाण पत्र शामिल हैं।
प्रमाणपत्र में आपके MX सर्वर के DNS नाम के साथ एक विषय वैकल्पिक नाम फ़ील्ड है।

आप निम्न आदेश के साथ प्रमाणपत्र के साथ कॉन्फ़िगर किए गए सर्वर को सत्यापित कर सकते हैं:

[ "$(LANG=C openssl s_client -connect MX.EXAMPLE.COM:25 -starttls smtp -verify_hostname MX.EXAMPLE.COM < /dev/null 2>&1 | fgrep 'error')" = "" ] && echo OK || echo FAIL

जहाँ MX.EXAMPLE.COM आपके MX सर्वर का डोमेन नाम है। मानक के पूर्ण अनुपालन के लिए, यह सत्यापित करना उचित है कि वांछित डोमेन नाम न केवल प्रमाण पत्र के सामान्य नाम में मौजूद है, बल्कि कम से कम विषय वैकल्पिक नाम में भी है।

पॉलिसी पोस्टिंग

इसके साथ एक सुरक्षित कनेक्शन का समर्थन करने के रूप में अपने डोमेन को नामित करने के लिए, आपको एमटीए-एसटीएस नीति प्रकाशित करनी होगी। ऐसा करने के लिए, निर्दिष्ट क्रम में निम्नलिखित सरल चरणों का पालन करें (उदाहरण डोमेन example.com के लिए दिए गए हैं)।

1. जगह पर

  https://mta-sts.example.com/.well-known/mta-sts.txt

प्रपत्र की पाठ फ़ाइल:

 संस्करण: STSv1
 मोड: लागू करें
 mx: mail.example.com
 mx: * .example.net
 mx: backupmx.example.com
 max_age: 604800

फ़ाइल सामग्री-प्रकार: पाठ / सादे के साथ दी जानी चाहिए। पुनर्निर्देशन की अनुमति नहीं है। लाइन फ़ीड या तो LF या CRLF होनी चाहिए। खाली लाइनों की अनुमति नहीं है। अंतिम पंक्ति एक पंक्ति फ़ीड के साथ समाप्त हो सकती है, या इसके साथ समाप्त नहीं हो सकती है - दोनों विकल्पों की अनुमति है। बृहदान्त्र से पहले खाली जगह और लाइन की शुरुआत में अनुमति नहीं है। किसी भी मात्रा में बृहदान्त्र के बाद खाली स्थान की अनुमति है। प्रत्येक पंक्ति के अंत में सफेद स्थान (रिक्त स्थान, टैब, आदि) को अनदेखा किया जाता है।

फ़ील्ड मान:

संस्करण : प्रारूप संस्करण। यह हमेशा "STSv1" के बराबर होना चाहिए।
मोड : नीति मोड। संभावित विकल्प: कोई नहीं, परीक्षण, लागू करना। एनफोर्स मोड मानक के सामान्य कामकाज से मेल खाती है - सर्वर से कनेक्ट होने पर सही प्रमाण पत्र और एक स्थिर टीएलएस कनेक्शन की आवश्यकता होती है। परीक्षण मोड में आपको एक सुरक्षित कनेक्शन का उपयोग करने का प्रयास करने की आवश्यकता होती है, लेकिन किसी त्रुटि के मामले में TLSRPT तंत्र के माध्यम से व्यवस्थापक अधिसूचना के साथ मेल भेजें। कोई भी मोड स्थिति से मेल नहीं खाता है जैसे कि नीति बिल्कुल प्रकाशित नहीं हुई थी। यह मोड किसी नीति को ठीक से अक्षम करने के लिए उपयोगी है।
mx : सभी अनुमत एमएक्स डोमेन सर्वरों के नाम वाले एक या अधिक फ़ील्ड। जैसा कि आप उदाहरण से देख सकते हैं, टेम्पलेट्स की अनुमति है, लेकिन केवल निचले स्तर के डोमेन के रूप में।
max_age : सेकंड में वह समय जिसे पॉलिसी को कैश किया जा सकता है और जिसके दौरान प्रेषक इसका उपयोग जारी रख सकते हैं यदि पॉलिसी उपलब्ध नहीं है। मानक की इस विशेषता के कारण, नई नीति को बिना किसी मोड के प्रकाशित करने से STS को अक्षम करना तेजी से होता है।

2. फॉर्म की सामग्री के साथ एक TXT रिकॉर्ड _mta-sts.example.com बनाएं:

  v = STSv1;  id = 20160831085700Z;

अर्धविराम के आसपास व्हाट्सएप को किसी भी मात्रा में मनमाने ढंग से व्यवस्थित किया जा सकता है। अन्य स्थानों पर, व्हाट्सएप की अनुमति नहीं है। अंतिम अर्धविराम या तो मौजूद या अनुपस्थित हो सकता है।

फ़ील्ड मान:

v : प्रारूप संस्करण। यह हमेशा पहला क्षेत्र होना चाहिए, यह हमेशा STSv1 के बराबर होना चाहिए।
आईडी : प्रकाशित नीति का विशिष्ट पहचानकर्ता। यह 1-32 अक्षरों की लंबाई के साथ एक स्ट्रिंग हो सकता है, जिसमें रजिस्टरों और संख्याओं के अक्षर शामिल हैं। आईडी वैल्यू बदलना प्रेषकों के लिए एक संकेत है जिसे पॉलिसी को अपडेट किया गया है। इसलिए, आपको पहले एक नई पॉलिसी फ़ाइल प्रकाशित करके और फिर TXT रिकॉर्ड में आईडी बदलकर पॉलिसी को अपडेट करना होगा।

अब से, एमटीए-एसटीएस का समर्थन करने वाले मेल सर्वर केवल आपके डोमेन को एक सुरक्षित प्रमाणपत्र-प्रमाणित कनेक्शन के माध्यम से मेल भेजेंगे। यह वह जगह है जहां अधिकांश मैनुअल समाप्त हो जाते हैं, लेकिन आगे सबसे दिलचस्प हिस्सा मेल भेजने के दौरान अपने स्वयं के सर्वर से एमटीए-एसटीएस नीति प्राप्त करना है।

सबसे दिलचस्प

मुख्य कठिनाई यह है कि यह मानक मेल सर्वर द्वारा समर्थित नहीं है, जिसमें पोस्टफ़िक्स शामिल हैं। हालांकि, इस अप्रिय त्रासदी को हमें रोकना नहीं चाहिए।

समाधान खोजने से मुझे इस मानक के समय की चर्चा करने वाले पोस्ट -यूज़र्स मेलिंग लिस्ट आर्काइव में ले गया। एक पोस्ट में, पोस्टफ़िक्स के लेखक, विटास वेनेमा, इस कार्यक्षमता को लागू करने के लिए पसंदीदा दिशा बताते हैं - टीएलएस नीतियों की खोज के लिए एक बाहरी सर्वर का उपयोग करने के लिए। प्रपत्र के कॉन्फ़िगरेशन निर्देश का उपयोग करना प्रस्तावित है:

  smtp_policy_maps = सॉकेटमैप: inet: host: port: name

मैंने एमटीए-एसटीएस पॉलिसी प्राप्त करने के लिए इस तरह के सर्वर को लागू किया।

→ सोर्स कोड
→ PyPI में पैकेज

RFC8461 निर्धारित किए गए कुछ कार्यों में एप्लिकेशन का अभाव है, जैसे: सक्रिय नीति पुनर्प्राप्ति, रिपोर्ट, और नीति अनुरोधों की आवृत्ति को सीमित करना। हालांकि, मुख्य कार्य - टीएलएस नीति का पता लगाना और इसे कैशिंग करना - यह प्रदर्शन करता है।

एप्लिकेशन को पायथन 3.5.3+ की आवश्यकता है। इस डेमॉन को स्थापित और कॉन्फ़िगर करना निम्न चरणों का उपयोग करके किया जा सकता है।

पैकेज स्थापना

यह कमांड चलाने के लिए पर्याप्त है:

 pip3 install postfix-mta-sts-resolver

वैकल्पिक स्थापना के तरीके यहां लिखे गए हैं ।

कॉन्फ़िगरेशन फ़ाइल बनाना

यदि आप डिफ़ॉल्ट सेटिंग्स से संतुष्ट हैं, तो कमांड पर्याप्त है

 touch /etc/postfix/mta-sts-daemon.yml

अन्यथा, कॉन्फ़िगरेशन को उदाहरण से लिया जा सकता है और आपकी आवश्यकताओं के अनुरूप बनाया जा सकता है।

मेरी राय में, सबसे महत्वपूर्ण पैरामीटर, सख्त_ पैरामीटर है। यदि यह सही (डिफ़ॉल्ट रूप से गलत) पर सेट है, तो अनुप्रयोग परीक्षण मोड में नीति के साथ डोमेन के लिए भी एक सुरक्षित नीति लौटाएगा। यह व्यवहार मानक के विरुद्ध है, लेकिन व्यावहारिक कारणों से यह उचित है: यदि डोमेन स्वामी ने परीक्षण मोड में भी एसटीएस नीति प्रकाशित की है, तो वह संभवतः इसके लिए तैयार है। यही है, फिर आज gmail.com मेल एक विश्वसनीय कनेक्शन पर भेजा जाएगा।

स्टार्टअप संगठन

सिस्टमड के मामले में, /etc/systemd/system/mta-sts-daemon.service में एक साधारण इकाई फ़ाइल रखना पर्याप्त है

उसके बाद, यह सिस्टम कॉन्फ़िगरेशन को फिर से पढ़ने के लिए बना रहता है, डेमन के ऑटोरन को सक्षम करता है और इसे शुरू करता है:

 systemctl daemon-reload systemctl enable mta-sts-daemon.service systemctl start mta-sts-daemon.service

स्वास्थ्य की जाँच

मान लें कि डिफ़ॉल्ट पोर्ट का उपयोग किया जाता है, कमांड

 /usr/sbin/postmap -q dismail.de socketmap:inet:127.0.0.1:8461:postfix

लाना चाहिए

  सुरक्षित मैच = mx1.dismail.de

पोस्टफिक्स से कनेक्ट करें

Main.cf में एक पंक्ति जोड़ें:

 smtp_policy_maps = socketmap:inet:127.0.0.1:8461:postfix

पोस्टफ़िक्स को पुनरारंभ करें:

 systemctl reload postfix.service

यदि सब कुछ सही ढंग से किया जाता है, तो STS कनेक्शन के लिए /var/log/mail.info में लॉग इन करें

  विश्वसनीय टीएलएस कनेक्शन स्थापित

रिकॉर्ड दिखाई देने लगते हैं

  सत्यापित टीएलएस कनेक्शन स्थापित

निष्कर्ष

यदि आप इस जगह पर आते हैं, तो इसका सबसे अधिक मतलब है:

आप एक छवि के बिना लेख पढ़ते हैं।
दिन-प्रतिदिन, आपके डोमेन में मेल के अवरोधन की संभावना कम हो जाएगी, क्योंकि अन्य मेल सेवाएं नए मानक को लागू करती हैं।

पोस्टफिक्स के लिए एमटीए-एसटीएस