नेटवर्क कनेक्शन और प्रारंभिक SMTP कमांड पहले ही काम कर लेने के बाद SMTP TLS विफलता हो सकती है। प्रेषक प्रोटोकॉल संस्करण पर बातचीत करने में विफल हो सकता है, प्रमाणपत्र को अस्वीकार कर सकता है, या हैंडशेक के दौरान रुकावट प्राप्त कर सकता है। इन्हें ट्रांसपोर्ट-लेयर अवलोकन के रूप में मानें, प्रेषक के तत्काल साक्ष्य के रूप में नहीं SPF या DKIM रिकॉर्ड गलत है.
परिवहन मोड को पहचानें
SMTP में STARTTLS, क्लाइंट पहले SMTP स्थापित करता है, क्षमता विज्ञापन प्राप्त करता है, STARTTLS अनुरोध करता है और फिर सर्वर की तत्परता के उत्तर के बाद TLS बातचीत शुरू करता है। अंतर्निहित TLS कनेक्शन पर तुरंत TLS शुरू करता है और आमतौर पर समर्थित सबमिशन सेवा के लिए उपयोग किया जाता है। इन अपेक्षाओं को मिलाने से उपयोगी मेल विनिमय होने से पहले कनेक्शन विफल हो सकता है। RFC 3207 धारा 4 और 5.
गंतव्य, पोर्ट, मोड, भेजने वाला सॉफ़्टवेयर, दूरस्थ SMTP ग्रीटिंग और विज्ञापित क्षमताओं को रिकॉर्ड करें। संरक्षित करें कि क्या विफलता STARTTLS की पेशकश से पहले हुई, STARTTLS कमांड के बाद, प्रमाणपत्र प्रसंस्करण के दौरान या हैंडशेक के बाद हुई। डायग्नोस्टिक पैकेट में निजी कुंजी, पासवर्ड या सत्र रहस्यों को कॉपी करने से बचें। प्रमाणपत्र मेटाडेटा और संशोधित प्रोटोकॉल त्रुटियां आमतौर पर अस्पष्ट "सुरक्षित कनेक्शन विफल" की तुलना में अधिक उपयोगी होती हैं।
वास्तविक नीति के तहत प्रमाणपत्रों का मूल्यांकन करें
एक समाप्त प्रमाणपत्र, असमर्थित प्रोटोकॉल, अपूर्ण श्रृंखला या पहचान बेमेल अलग-अलग भेजने वाली नीतियों के तहत अलग-अलग मायने रख सकते हैं। साधारण अवसरवादी SMTP TLS द्वारा संचालित कनेक्शन के समान आश्वासन मॉडल नहीं है MTA-STS या प्रमाणित DANE. प्रेषक ने डिलीवरी क्यों स्थगित की, इसकी व्याख्या करने से पहले लागू की जा रही नीति का नाम बताएं। यह न मानें कि प्रत्येक SMTP कार्यान्वयन प्रत्येक प्रमाणपत्र को समान रूप से मान्य करता है।
RFC 8461 MTA-STS नीति खोज, सत्यापन और प्रवर्तन व्यवहार को निर्दिष्ट करता है। RFC 7672 DNSSEC-प्रमाणित का उपयोग करके DANE SMTP परिवहन सुरक्षा को परिभाषित करता है TLSA जानकारी। उन तंत्रों की अपनी आवश्यकताएं और विफलता से निपटने की अपनी-अपनी आवश्यकताएं होती हैं। उनकी उपस्थिति को वास्तविक प्रेषक कॉन्फ़िगरेशन और प्रासंगिक खोज साक्ष्य से सत्यापित किया जाना चाहिए, केवल इसलिए अनुमान नहीं लगाया जाना चाहिए क्योंकि लॉग में TLS त्रुटि दिखाई देती है।
एक काल्पनिक पहचान विफलता के माध्यम से कार्य करें
मान लीजिए कि एक अधिकृत सबमिशन क्लाइंट को submit.example पर अंतर्निहित TLS के लिए कॉन्फ़िगर किया गया है, लेकिन इसकी प्रमाणपत्र त्रुटि old-submit.example की अपेक्षित पहचान दिखाती है। सबसे पहले सेवा के वर्तमान प्रलेखित समापन बिंदु की पुष्टि करें और क्या ग्राहक उस तक पहुंच रहा है। जो भी प्रमाणपत्र प्रतीत होता है उसे पास करने के लिए अपेक्षित नाम न बदलें।
यदि सेवा स्वामी पुष्टि करता है कि submit.example सही है और प्रमाणपत्र और श्रृंखला उस समापन बिंदु के लिए लागू आवश्यकताओं को पूरा करती है, तो एक अनुमोदित क्लाइंट कॉन्फ़िगरेशन सुधार बेमेल को हल कर सकता है। यदि समापन बिंदु सही है लेकिन प्रमाणपत्र गलत है, तो इसके बजाय सेवा प्रमाणपत्र की मरम्मत करें। दोनों पथों में सत्यापन सक्षम रखें और सुधार के बाद उसी सेवा की पुनः जाँच करें।
यह एक काल्पनिक निर्णय वृक्ष है, न कि निष्पादित हैंडशेक, प्रमाणपत्र जारी करना या दावा किया गया TLS संस्करण। MX डिलीवरी के लिए, सबमिशन-क्लाइंट धारणा को आयात करने के बजाय वास्तविक MTA-STS या DANE पहचान नियमों का उपयोग करें। HTTPS होमपेज प्रमाणपत्र SMTP एंडपॉइंट के प्रमाणपत्र या नीति को स्थापित नहीं करता है।
सुरक्षा को मिटाए बिना कारण को ठीक करें
सेवा स्वामी को प्रमाणपत्र नवीनीकरण और श्रृंखला परिनियोजन, मेल-प्लेटफ़ॉर्म स्वामी को प्रोटोकॉल संगतता, और नेटवर्क टीम को अवरोधन या पथ रुकावटें सौंपें। प्रमाणपत्र बदलने से पहले अपेक्षित MX पहचान और लागू नीति की जाँच करें। एक समय में एक स्वीकृत सुधार करें और रोलबैक योजना सुरक्षित रखें।
केवल परीक्षण पास करने के लिए प्रमाणपत्र चेतावनी को नजरअंदाज न करें, प्रवर्तन को अक्षम न करें या सादे पाठ की अनुमति न दें। कोई प्रेषक वापस आ सकता है या नहीं यह प्रोटोकॉल और शासन नीति पर निर्भर करता है; सख्त नीति असुरक्षित रूप से परिणाम देने के बजाय जानबूझकर विलंबित कर सकती है। एक सफल असुरक्षित पुनर्प्रयास यह प्रदर्शित नहीं करेगा कि TLS समस्या ठीक हो गई थी।
पुनः आरंभ किए गए SMTP सत्र को सत्यापित करें
RFC 3207 सफल STARTTLS के बाद पूर्व-TLS SMTP ज्ञान को त्यागने की आवश्यकता है; ग्राहक को भेजना चाहिए EHLO सबसे पहले संरक्षित सत्र की क्षमताओं की खोज करें, जो पिछली सूची से भिन्न हो सकती हैं। पुष्टि करें कि वास्तविक MTA इस संक्रमण को पूरा करता है और फिर अधिकृत संदेश स्थानांतरित करता है। किसी भी जारी कतार में देरी और अंतिम परिणाम को हैंडशेक की सफलता से अलग से रिकॉर्ड करें। TLS ट्रांसपोर्ट हॉप की सुरक्षा करता है; यह स्वयं दृश्यमान लेखक की वैधता, शुरू से अंत तक सामग्री की गोपनीयता या इनबॉक्स प्लेसमेंट स्थापित नहीं करता है।
TLS मरम्मत करते समय सुरक्षा आवश्यकता का ध्यान रखें
- एंडपॉइंट, पोर्ट, STARTTLS या अंतर्निहित मोड और सटीक विफल चरण को कैप्चर करें।
- प्रमाणपत्र बदलने से पहले सक्रिय नीति और अपेक्षित पहचान की पहचान करें।
- अलग नाम, वैधता, ट्रस्ट-चेन और प्रोटोकॉल त्रुटियां; लॉग से रहस्यों को बाहर निकालें.
- सत्यापन को अक्षम किए बिना अनुमोदित कारण-विशिष्ट मरम्मत लागू करें।
- नीति-अनुपालक TLS , पोस्ट-STARTTLS स्थिति रीसेट और संदेश परिणाम की स्वतंत्र रूप से पुष्टि करें।