ईमेल को समझना: पर्दे के पीछे यह कैसे काम करता है

सबसे पहले, आप अपने डिवाइस (जैसे Gmail, या Apple डिवाइस पर मेल ऐप) से ईमेल पढ़ने और भेजने के लिए एक मेल यूजर एजेंट, या MUA का उपयोग करते हैं। ये प्रोग्राम केवल तभी सक्रिय होते हैं जब आप उनका उपयोग कर रहे होते हैं।

आम तौर पर, वे एक मेल ट्रांसफर एजेंट, या MTA (जिसे मेल सर्वर, MX होस्ट, और मेल एक्सचेंजर के रूप में भी जाना जाता है) के साथ संचार करते हैं, जो आपके ईमेल प्राप्त करने और संग्रहीत करने का कार्य करता है।

ईमेल दूरस्थ रूप से तब तक संग्रहीत किए जाते हैं जब तक आप अपना MUA खोलकर अपना ईमेल जांचते हैं। ईमेल मेल डिलीवरी एजेंट्स (MDA) द्वारा वितरित किए जाते हैं, जो आमतौर पर MTA के साथ पैक किए जाते हैं।

मेल को SMTP, या सिंपल मेल ट्रांसफर प्रोटोकॉल का उपयोग करके मेल सर्वर पर भेजा जाता था। SMTP ईमेल के लिए एक संचार प्रोटोकॉल है।

यहां तक कि अब, जबकि Microsoft Exchange जैसे कई मालिकाना सिस्टम और Gmail जैसे वेबमेल प्रोग्राम आंतरिक रूप से अपने स्वयं के प्रोटोकॉल का उपयोग करते हैं, वे अपने सिस्टम के बाहर संदेशों को स्थानांतरित करने के लिए SMTP का उपयोग करते हैं (उदाहरण के लिए, यदि कोई Gmail उपयोगकर्ता Outlook क्लाइंट को ईमेल भेजना चाहता है)।

मेल को तब पोस्ट ऑफिस प्रोटोकॉल (POP3) का उपयोग करके सर्वर से डाउनलोड किया जाता था। POP3 एक एप्लिकेशन-लेयर प्रोटोकॉल है जो एक उपयोगकर्ता एप्लिकेशन के लिए मेल सर्वर पर मेलबॉक्स से संपर्क करने के लिए इंटरनेट प्रोटोकॉल (IP) नेटवर्क के माध्यम से पहुंच प्रदान करता है। यह कनेक्ट कर सकता है, संदेश प्राप्त कर सकता है, उन्हें क्लाइंट के कंप्यूटर पर संग्रहीत कर सकता है, और उन्हें सर्वर पर हटा या बनाए रख सकता है।

इसे अस्थायी इंटरनेट कनेक्शन, जैसे डायल-अप (ताकि यह सिर्फ कनेक्ट हो और कनेक्ट होने पर ईमेल प्राप्त करे, और जब आप ऑफ़लाइन हों तो संदेशों को देखने की अनुमति दे) को प्रबंधित करने में सक्षम होने के लिए डिज़ाइन किया गया था। यह तब अधिक लोकप्रिय था जब डायल-अप एक्सेस अधिक व्यापक था।

अब, IMAP, इंटरनेट मैसेज एक्सेस प्रोटोकॉल, ने अधिकतर POP3 को बदल दिया है। IMAP एक ही मेलबॉक्स को प्रबंधित करने के लिए कई क्लाइंट्स की अनुमति दे सकता है (ताकि आप अपने डेस्कटॉप, लैपटॉप, और फोन, आदि से अपना ईमेल पढ़ सकें और आपके सभी संदेश वहीं होंगे, उसी तरह व्यवस्थित)।

अंततः, वेबमेल ने दोनों को बदल दिया। वेबमेल आपको एक वेबसाइट पर लॉग इन करने और कहीं से भी या किसी भी डिवाइस से संदेश प्राप्त करने की अनुमति देता है (याय!), हालांकि आपको इसका उपयोग करते समय इंटरनेट से जुड़े रहने की आवश्यकता है। यदि वेबसाइट (जैसे Gmail) आपका MUA है, तो आपको SMTP या IMAP सर्वर सेटिंग्स जानने की आवश्यकता नहीं है।

ईमेल कैसे सुरक्षित है?

दुर्भाग्य से, सुरक्षा वास्तव में मेल प्रोटोकॉल में शुरुआत से नहीं बनाई गई थी (अधिकांश शुरुआती इंटरनेट प्रोटोकॉल की तरह)। सर्वरों को बस किसी से भी कोई भी संदेश लेने और उसे किसी अन्य सर्वर को पास करने की उम्मीद थी जो संदेश को उसके अंतिम गंतव्य (to: फ़ील्ड में प्राप्तकर्ता) तक रूट करने में मदद कर सके।

आश्चर्य की बात नहीं, यह एक मुद्दा बन गया जब इंटरनेट कुछ सरकारी और अनुसंधान समूहों से विस्तारित होकर कुछ ऐसा बन गया जिसका उपयोग दुनिया का अधिकांश हिस्सा अनिवार्य रूप से सब कुछ करने के लिए करता है। बहुत जल्द स्पैम और फ़िशिंग ईमेल सभी के लिए एक बड़ी समस्या बन गए (और बने हुए हैं)।

प्रतिक्रिया में, हमने सामूहिक रूप से कई उपायों को लागू करने की कोशिश की है जो लोगों को दूसरों के संदेशों को पढ़ने से रोकते हैं (एन्क्रिप्शन) और यह मान्य करते हैं कि संदेश वास्तव में कथित प्रेषक से आए हैं (प्रमाणीकरण)।

अधिकांश स्थान TLS (ट्रांसपोर्ट लेयर सिक्योरिटी, SSL का प्रतिस्थापन, सिक्योर सॉकेट्स लेयर) का उपयोग करते हैं, एक क्रिप्टोग्राफिक प्रोटोकॉल जो ट्रांजिट में एन्क्रिप्शन प्रदान करता है। यह तब सुरक्षा प्रदान करता है जब संदेश प्रेषित किया जा रहा होता है, लेकिन तब नहीं जब डेटा आराम पर होता है (उदाहरण के लिए, आपके कंप्यूटर पर संग्रहीत)।

यह सुनिश्चित करता है कि संदेश MTA से MTA तक यात्रा करते समय बदला या जासूसी नहीं किया जाता है। हालांकि, यह सत्यापित नहीं करता कि संदेश यात्रा के दौरान संशोधित नहीं किया गया था।

उदाहरण के लिए, यदि ईमेल अपने अंतिम गंतव्य तक पहुंचने से पहले कई मेल सर्वरों से गुजरता है, तो TLS का उपयोग यह सुनिश्चित करेगा कि यह सर्वरों के बीच एन्क्रिप्टेड है, लेकिन प्रत्येक सर्वर संदेश सामग्री को बदल सकता है। इसे संबोधित करने के लिए, हमने SPF, DKIM, और DMARC बनाए हैं।

SPF (सेंडर पॉलिसी फ्रेमवर्क)

SPF एक डोमेन के मालिक (जैसे google.com) को अपने DNS में एक TXT रिकॉर्ड सेट करने की अनुमति देता है जो बताता है कि कौन से सर्वर उस डोमेन से मेल भेजने के लिए अधिकृत हैं (विभिन्न होस्टिंग प्रदाताओं के लिए इसे कैसे करें, इस पर निर्देशों के लिए इस साइट को देखें)।

यह कैसे काम करता है?

यह रिकॉर्ड उन उपकरणों (आमतौर पर IP द्वारा) को सूचीबद्ध करता है जिन्हें अनुमति दी गई है और निम्न विकल्पों में से किसी एक में समाप्त हो सकता है:

• -all = यदि जांच विफल होती है (ईमेल का स्रोत सूचीबद्ध उपकरणों में से एक नहीं है) तो परिणाम HardFail होता है। अधिकांश मेल सिस्टम इन संदेशों को स्पैम के रूप में चिह्नित करेंगे।
• ?all = यदि जांच विफल होती है तो परिणाम तटस्थ होता है। यह आमतौर पर परीक्षण के लिए उपयोग किया जाता है, प्रोडक्शन डोमेन के लिए नहीं।
• ~all = यदि जांच विफल होती है तो परिणाम SoftFail होता है। इसका मतलब है कि यह संदेश संदिग्ध है, लेकिन जरूरी नहीं कि ज्ञात बुरा हो। कुछ मेल सिस्टम इन संदेशों को स्पैम के रूप में चिह्नित करेंगे, लेकिन अधिकांश नहीं करेंगे।

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

1. SPF एक मेल सर्वर को यह नहीं बताता कि संदेश के साथ क्या करना है - जिसका अर्थ है कि एक संदेश SPF जांच में विफल हो सकता है और फिर भी वितरित किया जा सकता है।
2. एक SPF रिकॉर्ड उस 'from' पते को नहीं देख रहा है जो उपयोगकर्ता देखता है, यह 'return-path' को देख रहा है। यह मूल रूप से एक पत्र पर आपके द्वारा लिखे गए रिटर्न एड्रेस के बराबर है। यह मेल सर्वरों को बताता है जो पत्र को संभालते हैं कि संदेश कहां लौटाना है (और यह ईमेल हेडर्स में संग्रहीत है - अनिवार्य रूप से तकनीकी जानकारी जो सर्वर ईमेल प्रोसेस करने के लिए उपयोग करते हैं)।
   इसका मतलब है कि मैं from: पते में जो चाहूं डाल सकता हूं और यह SPF जांच को प्रभावित नहीं करेगा। वास्तव में, उन दोनों ईमेल पतों को एक हैकर द्वारा अपेक्षाकृत आसानी से स्पूफ किया जा सकता है। क्योंकि कोई एन्क्रिप्शन शामिल नहीं है, SPF हेडर्स पर पूरी तरह से भरोसा नहीं किया जा सकता।
3. SPF रिकॉर्ड्स को लगातार अद्यतन रखने की आवश्यकता होती है जो बड़े, कभी बदलते संगठनों में मुश्किल हो सकता है।
4. फॉरवर्डिंग SPF को तोड़ देता है। ऐसा इसलिए है क्योंकि यदि google.com से कोई ईमेल bob@bobsburgers.com द्वारा फॉरवर्ड किया जाता है, तो लिफाफा प्रेषक अपरिवर्तित रहता है (from पता अभी भी google.com कहता है)। प्राप्त मेल सर्वर सोचता है कि यह google.com से होने का दावा कर रहा है, लेकिन bobsburgers.com से आ रहा है, इसलिए यह SPF जांच में विफल होता है (भले ही मेल वास्तव में google.com से आ रहा हो)।

SPF पर अधिक पढ़ने के लिए इन लेखों को देखें। आप यहां जांच सकते हैं कि किसी विशिष्ट डोमेन में SPF और DMARC रिकॉर्ड कॉन्फ़िगर हैं या नहीं।

DKIM (डोमेनकीज आइडेंटिफाइड मेल)

DKIM SPF के समान है। यह भेजने वाले डोमेन के DNS में TXT रिकॉर्ड्स का भी उपयोग करता है, और यह संदेश के कुछ प्रमाणीकरण प्रदान करता है। यह सत्यापित करने का प्रयास करता है कि संदेश ट्रांजिट में बदले नहीं गए थे।

यह कैसे काम करता है?

भेजने वाला डोमेन एक सार्वजनिक/निजी कुंजी जोड़ी उत्पन्न करता है और सार्वजनिक कुंजी को डोमेन के DNS TXT रिकॉर्ड में रखता है (यदि आप नहीं जानते कि सार्वजनिक/निजी कुंजी जोड़ी क्या है, तो क्रिप्टोग्राफी पर इस लेख को देखें)।

फिर, डोमेन के मेल सर्वर (बाहरी सीमा पर - वे सर्वर जो डोमेन के बाहर मेल भेज रहे हैं (उदाहरण के लिए gmail.com से outlook.com)) पूरे संदेश बॉडी का हस्ताक्षर उत्पन्न करने के लिए निजी कुंजी का उपयोग करते हैं, जिसमें हेडर्स शामिल हैं।

हस्ताक्षर उत्पन्न करने के लिए आमतौर पर टेक्स्ट को हैश और एन्क्रिप्ट करने की आवश्यकता होती है (इस प्रक्रिया पर अधिक विवरण के लिए इस लेख को देखें)।

प्राप्त मेल सर्वर DNS TXT रिकॉर्ड में सार्वजनिक कुंजी का उपयोग करके हस्ताक्षर को डिक्रिप्ट करते हैं और फिर संदेश और प्रासंगिक हेडर्स (कोई भी हेडर जो मेल भेजने वाले के बुनियादी ढांचे के अंदर बनाए गए थे - उदाहरण के लिए यदि कई Gmail सर्वरों ने इसे Outlook.com को बाहरी रूप से भेजने से पहले प्रोसेस किया) को हैश करते हैं।

सर्वर तब यह सुनिश्चित करने के लिए जांच करेगा कि दोनों हैश मेल खाते हैं। यदि वे करते हैं, तो संदेश अपरिवर्तित होने की संभावना है (जब तक किसी ने प्रेषक की निजी कुंजी से समझौता नहीं किया है) और कथित प्रेषक से वैध रूप से है। यदि हैश मेल नहीं खाते हैं, तो संदेश या तो कथित प्रेषक से नहीं था, या ट्रांजिट में किसी अन्य सर्वर द्वारा बदल दिया गया था, या दोनों।

DKIM एक बहुत विशिष्ट कार्य पर बहुत अच्छा काम करता है - 'क्या इस ईमेल को ट्रांजिट में बदल दिया गया था या कथित प्रेषक से नहीं था?' सवाल का जवाब देना। हालांकि, यह सब यह करता है। यह आपको यह नहीं बताता कि इस टेस्ट में विफल होने वाले ईमेल से कैसे निपटें, कौन सा सर्वर संदेश को बदल सकता था, या क्या परिवर्तन किए गए थे।

DKIM का उपयोग कुछ ISPs, या इंटरनेट सेवा प्रदाताओं द्वारा आपके डोमेन की प्रतिष्ठा निर्धारित करने के लिए भी किया जाता है (क्या आप बहुत सारा स्पैम भेज रहे हैं? क्या आपके पास कम जुड़ाव है? आपके ईमेल कितनी बार बाउंस होते हैं?)।

DKIM पर अधिक पढ़ने के लिए इस लेख को देखें। आप यहां DKIM रिकॉर्ड को मान्य कर सकते हैं।

DMARC (डोमेन-बेस्ड मैसेज ऑथेंटिकेशन, रिपोर्टिंग, एंड कंफॉरमेंस)

DMARC अनिवार्य रूप से मेल सर्वरों के लिए निर्देश हैं कि SPF और DKIM रिकॉर्ड को कैसे संभालें। यह अपने आप कोई परीक्षण नहीं करता है, लेकिन यह मेल सर्वरों को बताता है कि SPF और DKIM द्वारा किए गए चेक को कैसे संभालना है।

भाग लेने वाले ISPs प्रकाशित DMARC रिकॉर्ड्स को देखेंगे और उनका उपयोग यह निर्धारित करने के लिए करेंगे कि DKIM या SPF विफलताओं से कैसे निपटें। तो उदाहरण के लिए, एक आमतौर पर स्पूफ किया गया ब्रांड एक DMARC रिकॉर्ड प्रकाशित कर सकता है जो कहता है कि यदि DKIM या SPF विफल होता है, तो संदेश को ड्रॉप करें।

अक्सर ISPs आपके डोमेन की गतिविधि पर रिपोर्ट भी आपको भेजेंगे जिसमें ईमेल का स्रोत और चाहे उसने DKIM/SPF पास/फेल किया हो। इसका मतलब है कि आप देख पाएंगे कि कब लोग आपके डोमेन को स्पूफ कर रहे हैं (आपके डोमेन से भेजने का दिखावा कर रहे हैं) या आपके संदेशों को बदल रहे हैं।

DMARC लागू करने के लिए, आपको अपनी आवश्यकताओं के आधार पर एक DMARC रिकॉर्ड बनाने की आवश्यकता है (अपने ईमेल ट्रैफिक की निगरानी करने से यह पता लगाने के लिए कि आपके सभी ईमेल स्रोत क्या हैं, कार्रवाई करने के लिए कहने तक, जैसे DKIM या SPF में विफल होने वाले किसी भी ईमेल को अस्वीकार करना)। आप इसके बारे में यहां और यहां अधिक जान सकते हैं।

DMARC पर अधिक पढ़ने के लिए इस लेख को देखें। आप यहां जांच सकते हैं कि किसी विशिष्ट डोमेन में SPF और DMARC रिकॉर्ड कॉन्फ़िगर हैं या नहीं।

समापन

इनमें से कोई भी सुरक्षा उपाय पूर्ण नहीं हैं, लेकिन साथ में, वे दुनिया भर में ईमेल सिस्टम की सुरक्षा में सुधार करने में हमारी मदद करने का एक अच्छा काम करते हैं।

जितने अधिक संगठन इन उपायों को अपनाते हैं (चाहे ओपन सोर्स कार्यान्वयन का उपयोग करके या किसी उत्पाद के लिए भुगतान करके) उतना ही बेहतर सभी के लिए होगा। एक प्रोटोकॉल या उत्पाद विकसित होने के बाद जोड़ी गई सुरक्षा आमतौर पर सुरक्षा की तुलना में अधिक महंगी, कम प्रभावी, और लागू करने में कठिन होती है, जो उत्पाद में अंतर्निहित होती है।

हालांकि, अधिकांश प्रोटोकॉल जिन पर वर्तमान इंटरनेट निर्भर करता है, प्रारंभिक इंटरनेट के लिए डिज़ाइन किए गए थे - उत्साही, वैज्ञानिकों, और सरकारी लोगों के एक छोटे समूह के लिए - एक विश्वव्यापी नेटवर्क के लिए नहीं जिस पर हम इमारतें, स्मार्ट डिवाइस, सार्वजनिक परिवहन, परमाणु संयंत्र(!), और इसी तरह चलाते हैं।

इस प्रकार, जैसे-जैसे इंटरनेट का विस्तार जारी रहा है, हमें उन प्रणालियों को सुरक्षित करने के नए तरीकों को अनुकूलित और विकसित करना जारी रखना होगा जिन पर हम भरोसा करते हैं।