ईमेल कैसे काम करता है?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

यह सुनिश्चित करता है कि एमटीए से एमटीए की यात्रा के दौरान संदेश में कोई बदलाव नहीं किया गया है या उसकी जासूसी नहीं की गई है। हालांकि, यह इस बात की पुष्टि नहीं करता है कि यात्रा के दौरान संदेश को संशोधित नहीं किया गया था।

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

SPF (प्रेषक नीति ढांचा)

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

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

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

-all =यदि चेक विफल हो जाता है (ईमेल का स्रोत सूचीबद्ध उपकरणों में से एक नहीं है) तो परिणाम हार्डफेल है। अधिकांश मेल सिस्टम इन संदेशों को स्पैम के रूप में चिह्नित करेंगे।

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

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

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

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

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

DKIM (DomainKeys Identified Mail)

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

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

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

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

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

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

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

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

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

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

DMARC (डोमेन-आधारित संदेश प्रमाणीकरण, रिपोर्टिंग और अनुरूपता)

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

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

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

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

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

रैप अप करें

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

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

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

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