ईमेल क्लाइंट: Difference between revisions
| Line 49: | Line 49: | ||
| access-date = 24 August 2011 | | access-date = 24 August 2011 | ||
}} | }} | ||
</ref> मेल भेजते समय, उपयोगकर्ता केवल | </ref> मेल भेजते समय, उपयोगकर्ता केवल क्लाइंट से उसके कॉन्फ़िगर किए गए आउटगोइंग मेल सर्वर पर पहली हॉप पर एन्क्रिप्शन को नियंत्रित कर सकते हैं। किसी भी आगे की स्थिति में, संदेशों को एन्क्रिप्शन के साथ या उसके बिना प्रसारित किया जा सकता है, जो केवल संचरण सर्वर के सामान्य विन्यास और प्राप्तकर्ता की क्षमताओं पर निर्भर करता है। | ||
एन्क्रिप्टेड मेल सत्र उपयोगकर्ता के स्थानीय मेलबॉक्स और गंतव्य सर्वर पर उनके मूल प्रारूप, अर्थात प्लैन पाठ या एन्क्रिप्टेड निकाय में संदेश वितरित करते हैं। बाद वाला सर्वर एक [[ईमेल होस्टिंग सेवा]] प्रदाता द्वारा संचालित होता है, जो संभवतः वर्तमान में उपस्थित इंटरनेट एक्सेस प्रदाता से भिन्न इकाई है। | एन्क्रिप्टेड मेल सत्र उपयोगकर्ता के स्थानीय मेलबॉक्स और गंतव्य सर्वर पर उनके मूल प्रारूप, अर्थात प्लैन पाठ या एन्क्रिप्टेड निकाय में संदेश वितरित करते हैं। बाद वाला सर्वर एक [[ईमेल होस्टिंग सेवा]] प्रदाता द्वारा संचालित होता है, जो संभवतः वर्तमान में उपस्थित इंटरनेट एक्सेस प्रदाता से भिन्न इकाई है। | ||
Revision as of 09:00, 14 August 2023
एक ईमेल क्लाइंट, ईमेल रीडर या, अधिक औपचारिक रूप से, संदेश उपयोगकर्ता एजेंट (एमयूए) या मेल उपयोगकर्ता एजेंट एक कंप्यूटर प्रोग्राम है जिसका उपयोग उपयोगकर्ता के ईमेल को एक्सेस और प्रबंधित करने के लिए किया जाता है।
एक वेब अनुप्रयोग जो संदेश प्रबंधन, संयोजन और रिसेप्शन फंक्शनों को प्रदान करता है तथा एक वेब ईमेल क्लाइंट के रूप में कार्य कर सकता है, और कंप्यूटर हार्डवेयर या सॉफ़्टवेयर का एक भाग जिसकी प्राथमिक या सबसे दृश्य भूमिका ईमेल क्लाइंट के रूप में काम करना है, वह भी इस शब्द का उपयोग कर सकता है।
मेलबॉक्स से संदेश पुनः प्राप्त करना
अधिकांश क्लाइंट प्रोग्रामों की तरह, एक ईमेल क्लाइंट केवल तभी सक्रिय होता है जब कोई उपयोगकर्ता इसे चलाता है। सामान्य व्यवस्था एक ईमेल उपयोगकर्ता (क्लाइंट) के लिए क्लाइंट के ईमेल की प्राप्ति और भंडारण के लिए रिमोट मेल ट्रांसफर एजेंट (एमटीए) सर्वर के साथ व्यवस्था करना है। एमटीए, एक उपयुक्त मेल डिलीवरी एजेंट (एमडीए) का उपयोग करके, क्लाइंट के भंडारण में ईमेल संदेशों को आते ही जोड़ देता है। दूरस्थ मेल भंडारण को उपयोगकर्ता का मेलबॉक्स कहा जाता है। कई यूनिक्स प्रणालियों पर डिफ़ॉल्ट सेटिंग मेल सर्वर के लिए उपयोगकर्ता की निजी निर्देशिका के भीतर तथा एमबॉक्स में प्रारूपित संदेशों को संग्रहीत करने के लिए है। अवश्य ही, प्रणाली के उपयोगकर्ता लॉग-इन कर सकते हैं और उसी कंप्यूटर पर मेल क्लाइंट चला सकते हैं जो उनके मेलबॉक्स को होस्ट करता है, इस स्थिति में, सामान्य अर्थ के अतिरिक्त, सर्वर वास्तव में दूरस्थ नहीं है।
ईमेल को दूरस्थ सर्वर पर उपयोगकर्ता के मेलबॉक्स में तब तक संग्रहीत किया जाता है जब तक कि उपयोगकर्ता का ईमेल क्लाइंट उन्हें उपयोगकर्ता के कंप्यूटर पर डाउनलोड करने का अनुरोध नहीं करता है, या संभवतः दूरस्थ सर्वर पर उपयोगकर्ता के मेलबॉक्स तक एक्सेस नहीं कर सकता है। ईमेल क्लाइंट को एक ही समय में कई मेलबॉक्सों से संयोजित करने और स्वचालित रूप से ईमेल डाउनलोड करने का अनुरोध करने के लिए निर्धारित किया जा सकता है, जैसे कि पूर्व-निर्धारित अंतराल पर, या अनुरोध उपयोगकर्ता द्वारा मैन्युअल रूप से शुरू किया जा सकता है।
उपयोगकर्ता के मेलबॉक्स तक दो समर्पित तरीकों से एक्सेस किया जा सकता है। पोस्ट ऑफिस प्रोटोकाॅल (पीओपी) उपयोगकर्ता को एक समय में एक संदेश डाउनलोड करने की अनुमति देता है और स्थानीय भंडारण पर सफलतापूर्वक सहेजे जाने के बाद ही उन्हें सर्वर से हटाता है। किसी अन्य क्लाइंट को उन तक एक्सेस करने की अनुमति देने के लिए सर्वर पर संदेशों को छोड़ना संभव है। हालांकि, किसी विशिष्ट संदेश को देखे गए, उत्तर उत्तर दिए गए या अग्रेषित के रूप में चिह्नित करने का कोई नियम नहीं है, इस प्रकार पीओपी उन उपयोक्ताओं के लिए सुविधाजनक नहीं है जो विभिन्न मशीनों से एक ही मेल तक एक्सेस करते हैं।
वैकल्पिक रूप से, इंटरनेट संदेश एक्सेस प्रोटोकॉल (आईएमएपी) उपयोगकर्ताओं को उचित रूप में चिह्नित करके सर्वर पर संदेश रखने की अनुमति देता है। आईएमएपी फ़ोल्डर्स और उप-फ़ोल्डर्स प्रदान करता है, जिन्हें संभवतः अलग-अलग एक्सेस अधिकारों के साथ विभिन्न उपयोगकर्ताओं के बीच सहभाजित किया जा सकता है। आमतौर पर, प्रेषित, ड्राफ्ट औरट्रैश फ़ोल्डर डिफ़ॉल्ट रूप से बनाए जाते हैं। आईएमएपी में वास्तविक समय के अपडेट के लिए एकनिष्क्रिय विस्तार की सुविधा है, जो पोलिंग (क्रमवरण) की तुलना में तेज़ अधिसूचना प्रदान करता है तथा जहां लंबे समय तक चलने वाले संबंध संभव हैं। नीचे दूरस्थ संदेश अनुभाग भी देखें।
जेएसओएन मेटा अनुप्रयोग प्रोटोकॉल (जेएमएपी) को एचटीटीपी पर जेएसओएन एपीआई का उपयोग करके कार्यान्वित किया गया है और इसे आईएमएपी/एसएमटीपी के विकल्प के रूप में विकसित किया गया है।
इसके अतिरिक्त, मेलबॉक्स भण्डारण को सर्वर पर चल रहे प्रोग्राम या सहभाजित डिस्क के माध्यम से सीधे एक्सेस किया जा सकता है। डाइरेक्ट ऐक्सेस अधिक सक्षम हो सकता है लेकिन यह सुवाहय नहीं होता क्योंकि यह मेलबॉक्स प्रारूप पर निर्भर करता है, इसका उपयोग कुछ ईमेल क्लाइंटों द्वारा किया जाता है, जिनमें कुछ वेबमेल अनुप्रयोग भी सम्मिलित हैं।
संदेश रचना
ईमेल क्लाइंटों में आमतौर पर उपयोक्ता अंतरापृष्ठ सम्मिलित होते हैं जो पाठ्य को प्रदर्शित और संपादित करने के लिए होते हैं। कुछ अनुप्रयोग प्रोग्राम-बाहरी संपादक के उपयोग की अनुमति देते हैं।
ईमेल क्लाइंट हेडर और निकाय के लिए RFC 5322 और गैर-पाठ्य अन्तर्वस्तु और अनुलग्नकों के लिए एमआईएमई के अनुसार प्रारूपण करेंगे। हेडर में गंतव्य क्षेत्रों से सीसी (कार्बन कॉपी के लिए संक्षिप्त), और बीसीसी (ब्लाइंड कार्बन कॉपी), और प्रवर्तक क्षेत्र सम्मिलित हैं, जिनमें से संदेश का लेखक है, यदि अधिक लेखक हैं तो प्रेषक, और किसी भिन्न मेलबॉक्स को संबोधित करके प्रतिक्रियाओं की स्थिति में उत्तर दें। गंतव्य क्षेत्र में उपयोगकर्ता की बेहतर सहायता के लिए, कई क्लाइंट एक या अधिक पता पुस्तिकाएँ बनाए रखते हैं और/या एलडीएपी निर्देशिका सर्वर से जुड़ने में सक्षम होते हैं। प्रवर्तक क्षेत्रों के लिए, क्लाइंट विभिन्न पहचानों का समर्थन कर सकते हैं।
क्लाइंट सेटिंग्स के लिए प्रत्येक उपयोगकर्ता की पहचान के लिए उपयोगकर्ता कावास्तविक नाम औरईमेल पता और संभवतः एलडीएपी सर्वर की एक सूची की आवश्यकता होती है।
सर्वर पर संदेश प्रस्तुत करना
जब कोई उपयोगकर्ता ईमेल बनाना और भेजना चाहता है, तो ईमेल क्लाइंट इस कार्य का संचालन करता है | ईमेल क्लाइंट आमतौर पर उपयोगकर्ता के मेल सर्वर से संबंधित करने के लिए स्वचालित रूप से निर्धारित किया जाता है, जो आमतौर पर या तो एमएसए या एमटीए होता है, जो एसएमटीपी प्रोटोकॉल के दो रूप हैं। एसएमटीपी प्रोटोकॉल का उपयोग करने वाला ईमेल क्लाइंट एक सत्यापन विस्तार बनाता है, जिसका उपयोग मेल सर्वर प्रेषक को सत्यापित करने के लिए करता है। यह विधि माड्यूलता और नोमेडिक कंप्यूटिंग को आसान बनाती है। पुरानी विधि मेल सर्वर के लिए क्लाइंट के आईपी पते को पहचानने के लिए थी, उदाहरण के लिए, क्योंकि क्लाइंट एक ही मशीन पर है और आंतरिक पता 127.0.0.1 का उपयोग करता है, या क्लाइंट का आईपी पता उसी इंटरनेट सेवा प्रदाता द्वारा नियंत्रित किया जाता है जो इंटरनेट एक्सेस और मेल सेवाएं दोनों प्रदान करता है।
क्लाइंट सेटिंग्स के लिए मुख्य आउटगोइंग मेल सर्वर का नाम या आईपी पता, पोर्ट संख्या (एमटीए के लिए 25, एमएसए के लिए 587), और सत्यापन के लिए उपयोगकर्ता नाम और पासवर्ड, की आवश्यकता होती है। एसएसएल एन्क्रिप्टेड एसएमटीपी सत्रों के लिए एक गैर-मानक पोर्ट 465 है, जिसे कई क्लाइंट और सर्वर पश्च संगतता के लिए समर्थन करते हैं।
एन्क्रिप्शन
बिना किसी एन्क्रिप्शन के, पोस्टकार्ड की तरह, ईमेल सक्रियता किसी भी सामयिक प्रच्छन्नश्रावी द्वारा स्पष्ट रूप से दिखाई देती है। ईमेल एन्क्रिप्शन मेल सत्र, संदेश के मुख्य भाग या दोनों को एन्क्रिप्ट करके गोपनीयता को सुरक्षित रखने में सक्षम बनाता है। इसके बिना, नेटवर्क एक्सेस करने और सही टूल वाला कोई भी व्यक्ति ईमेल की जांच कर सकता है और लॉगिन पासवर्ड प्राप्त कर सकता है। कंसर्न के उदाहरणों में सरकारी प्रतिबंधन और जांच और इंटरनेट कैफे जैसे वायरलेस नेटवर्क उपयोगकर्ता सम्मिलित हैं।
सभी उपयुक्त ईमेल प्रोटोकॉल में पूरे सत्र को एनक्रिप्ट करने का एक विकल्प होता है, जिससे उपयोगकर्ता केनाम औरपासवर्ड को स्निफ़ किया जाने से रोका जा सकता है। इन्हें नोमेडिक उपयोक्ताओं के लिए दृढ़ता से व्यक्त किया जाता है और जब भी इंटरनेट एक्सेस प्रदाता पर विश्वास नहीं किया जाता है।[1] मेल भेजते समय, उपयोगकर्ता केवल क्लाइंट से उसके कॉन्फ़िगर किए गए आउटगोइंग मेल सर्वर पर पहली हॉप पर एन्क्रिप्शन को नियंत्रित कर सकते हैं। किसी भी आगे की स्थिति में, संदेशों को एन्क्रिप्शन के साथ या उसके बिना प्रसारित किया जा सकता है, जो केवल संचरण सर्वर के सामान्य विन्यास और प्राप्तकर्ता की क्षमताओं पर निर्भर करता है।
एन्क्रिप्टेड मेल सत्र उपयोगकर्ता के स्थानीय मेलबॉक्स और गंतव्य सर्वर पर उनके मूल प्रारूप, अर्थात प्लैन पाठ या एन्क्रिप्टेड निकाय में संदेश वितरित करते हैं। बाद वाला सर्वर एक ईमेल होस्टिंग सेवा प्रदाता द्वारा संचालित होता है, जो संभवतः वर्तमान में उपस्थित इंटरनेट एक्सेस प्रदाता से भिन्न इकाई है।
ईमेल पुनर्प्राप्ति सत्र को एन्क्रिप्ट करना, उदाहरण के लिए, एसएसएल, सत्र के दोनों भागों (प्रमाणीकरण, और संदेश स्थानांतरण) की सुरक्षा कर सकता है।[2][3]
वैकल्पिक रूप से, यदि उपयोगकर्ता के पास अपने मेल सर्वर तक एसएसएच एक्सेस है, तो वे एक एन्क्रिप्टेड टनल बनाने के लिए एसएसएच पोर्ट अग्रक का उपयोग कर सकते हैं, जिस पर वे अपने ईमेल पुनः प्राप्त कर सकते हैं।[4]
संदेश के मुख्य भाग का एन्क्रिप्शन
क्रिप्टोग्राफ़िक कुंजियों के प्रबंधन के लिए दो प्रमुख प्रारूप हैं। एस/एमआईएमई एक विश्वसनीय प्रमाणपत्र प्राधिकारी (सीए) पर आधारित एक प्रारूप नियोजित करता है जो उपयोक्ताओं की सार्वजनिक कुंजियों पर हस्ताक्षर करता है। ओपनपीजीपी कुछ अधिक लचीले वेब ऑफ ट्रस्ट तंत्र का उपयोग करता है जो उपयोगकर्ताओं को एक दूसरे की सार्वजनिक कुंजी पर हस्ताक्षर करने की अनुमति देता है। ओपनपीजीपी संदेशों के प्रारूप में भी अधिक फ्लेक्सिबल है, इसमें यह अभी भी प्लैन संदेश एन्क्रिप्शन और हस्ताक्षर करने का समर्थन करता है क्योंकि कि वे एमआईएमई मानकीकरण से पहले काम करते थे।
दोनों ही स्थितियों में, केवल संदेश का मुख्य भाग एन्क्रिप्ट किया गया है। प्रवर्तक, प्राप्तकर्ता और अधिकतर विषय सहित हेडर क्षेत्र प्लैन पाठ में रहते हैं।
वेबमेल
डेस्कटॉप कंप्यूटर पर चलने वाले ईमेल क्लाइंटों के अतिरिक्त, दूरस्थ रूप से होस्ट किए गए क्लाइंट भी होते हैं, या तो टेलनेट (अर्थात एक शैल अकाउंट) द्वारा एक्सेस योग्य दूरस्थ यूनिक्स प्रतिष्ठापन के भाग के रूप में, या वेब पर होस्ट किए जाते हैं। इन दोनों दृष्टिकोणों के कई लाभ हैं, वे वेब ब्राउज़र या टेलनेट क्लाइंट का उपयोग करके उपयोगकर्ता के सामान्य आधार से दूर ईमेल भेजने और प्राप्त करने की क्षमता साझा करते हैं, जिससे उपयोगकर्ता के उपकरण पर एक समर्पित ईमेल क्लाइंट स्थापित करने की आवश्यकता समाप्त हो जाती है।
कुछ वेबसाइटें ईमेल सेवाएँ प्रदान करने के लिए प्रस्तुत हैं, और कई इंटरनेट सेवा प्रदाता अपने इंटरनेट सेवा पैकग के भाग के रूप में वेबमेल सेवाएँ प्रदान करते हैं। वेबमेल की प्रमुख सीमाएँ यह हैं कि उपयोगकर्ता की अन्योन्यक्रियाऐं वेबसाइट के प्रचालन प्रणाली के अधीन होती है और ईमेल संदेशों को डाउनलोड करने और संदेशों को ऑफ़लाइन लिखने या काम करने में सामान्य असमर्थता होती है, हालांकि ऐसे सॉफ़्टवेयर पैकग हैं जो वेबमेल प्रकार्यात्मकता के कुछ भागों को ओएस में एकीकृत कर सकते हैं (उदाहरण के लिए एमएपीआई के माध्यम से तीसरे पक्ष के अनुप्रयोग से सीधे संदेश बनाना)।
आईएमएपी और एमएपीआई की तरह, वेबमेल ईमेल संदेशों को मेल सर्वर पर बने रहने की सुविधा प्रदान करता है। जिसके लिए अगला भाग देखें |
दूरस्थ संदेश
पीओपी3 में सर्वर पर संदेश छोड़ने का विकल्प होता है। इसके विपरीत, आईएमएपी और वेबमेल दोनों सर्वर पर संदेशों को अपने प्रचालन की विधि के रूप में रखते हैं, हालांकि उपयोगकर्ता अपनी इच्छानुसार स्थानीय प्रतियां बना सकते हैं। सर्वर पर संदेशों को रखने के लाभ और हानि दोनों हैं।[5]
लाभ
- संदेशों को विभिन्न क्लाइंटों का उपयोग करके विभिन्न स्थानों पर विभिन्न कंप्यूटरों या मोबाइल उपकरणों से एक्सेस किया जा सकता है।
- किसी प्रकार का बैकअप आमतौर पर सर्वर द्वारा प्रदान किया जाता है।
हानि
- सीमित बैंडविड्थ के साथ, लंबे संदेशों का एक्सेस लंबा समय ले सकता है, जब तक कि ईमेल क्लाइंट स्थानीय प्रतिलिपि को कैश न कर ले।
- गोपनीयता संबंधी चिंताएँ हो सकती हैं क्योंकि सर्वर पर हर समय रहने वाले संदेशों को आईटी कर्मिकों द्वारा आकस्मिक रूप से एक्सेस किए जाने की अधिक संभावना होती है, जब तक कि आद्यांत अनुप्रयोग का उपयोग नहीं किया जाता है।
प्रोटोकॉल
मेल पुनर्प्राप्त करने के लिए लोकप्रिय प्रोटोकॉल में पीओपी3 और आईएमएपी4 सम्मिलित हैं। मेल भेजने के लिए आमतौर पर एसएमटीपी प्रोटोकॉल का उपयोग किया जाता है।
अधिकांश ईमेल क्लाइंटों द्वारा समर्थित एक अन्य महत्वपूर्ण मानक एमआईएमई है, जिसका उपयोग द्विआधारी फ़ाइल ईमेल संलग्नक भेजने के लिए किया जाता है। संलग्नक वे फ़ाइलें हैं जो ईमेल का भाग नहीं होती हैं लेकिन ईमेल के साथ भेजी जाती हैं।
अधिकांश ईमेल क्लाइंट संदेश भेजने के लिए उपयोग किए जाने वाले सॉफ़्टवेयर की पहचान करने के लिए उपयोक्ता-एजेंट हेडर क्षेत्र का उपयोग करते हैं।[6] यह हेडर क्षेत्र नेटन्यूज़ के लिए परिभाषित है, लेकिन ई-मेल के लिए नहीं, और, इस प्रकार, ई-मेल हेडर में गैर मानक है।[7]
RFC 6409, मेल के लिए संदेश प्रस्तुतिकरण तथा मेल प्रस्तुतिकरण एजेंट की भूमिका का विवरण देता है।
RFC 5068, ईमेल प्रस्तुतिकरण प्रचालन, एक्सेस और उत्तरदायित्व आवश्यकताएँ, एमटीए, एमएसए, एमडीए और एमयूए की अवधारणाओं का एक सर्वेक्षण प्रदान करता है। इसमें उल्लेख किया गया है कि "एक्सेस प्रदाताओं को उपयोगकर्ताओं को प्रस्तुतिकरण पोर्ट 587 का उपयोग बाहरी इंटरनेट तक एक्सेस से नहीं रोकना चाहिए" और "एमयूए को संदेश प्रस्तुति करने के लिए प्रस्तुतिकरण पोर्ट का उपयोग करना चाहिए।"
RFC 5965, ईमेल फीडबैक रिपोर्ट के लिए एक विस्तरणीय प्रारूप, "एक विस्तरणीय प्रारूप और एमआईएमई प्रकार प्रदान करता है जिसका उपयोग मेल प्रचालकों द्वारा अन्य पक्षों को प्राप्त ईमेल के बारे में फीडबैक रिपोर्ट करने के लिए किया जा सकता है।"
पोर्ट संख्या
कन्वेंशन के अनुसार ईमेल सर्वर और क्लाइंट निम्न तालिका में टीसीपी पोर्ट नंबर का उपयोग करते हैं। एमएसए, आईएमएपी और पीओपी3 के लिए, तालिका में लेबलों की भी रिपोर्ट करती है जिनका उपयोग क्लाइंट एसआरवी रिकार्ड को क्वेरी करने और संबंधित सेवा के होस्ट नाम और पोर्ट नंबर दोनों को खोजने के लिए कर सकता है |[8]
| प्रोटोकॉल | उपयोग | सादा पाठ या
एन्क्रिप्ट सत्र |
सादे पाठ
केवल सत्र |
केवल एन्क्रिप्टेड सत्र |
|---|---|---|---|---|
| पीओपी3 | इनकमिंग मेल | 110 _pop3._tcp |
995 _pop3s._tcp | |
| आईएमएपी4 | इनकमिंग मेल | 143 _imap._tcp |
993 _imaps._tcp | |
| एसएमटीपी | आउटगोइंग मेल | 25 | 587 | |
| एमएसए | आउटगोइंग मेल | 587 _submission._tcp |
465[9] _submissions._tcp | |
| एचटीटीपी | वेबमेल | 80 | 443 |
जबकि वेबमेल एन्क्रिप्ट और सादे पाठ सत्रों के लिए अलग-अलग पोर्ट रखने के पहले एचटीटीपी प्रबंध का पालन करता है, मेल प्रोटोकॉल एसटीएआरटीटीएलएस तकनीक का उपयोग करते हैं, जिससे एन्क्रिप्शन को पहले से स्थापित टीसीपी संबंध पर शुरू करने की अनुमति मिलती है। जबकि RFC 2595 पहले से स्थापित पोर्ट 995 और 993 के उपयोग को हतोत्साहित करता था, RFC 8314 उपलब्ध होने पर अंतर्निहित टीएलएस के उपयोग को बढ़ावा देता है।
सांपत्तिक क्लाइंट प्रोटोकॉल
माइक्रोसॉफ्ट मेल प्रणाली माइक्रोसॉफ्ट विनिमय इलेक्ट्रॉनिक मेल सर्वर तक एक्सेस के लिए माइक्रोसॉफ्ट आउटलुक जैसे क्लाइंट अनुप्रयोगों में सांपत्तिक संदेश अनुप्रयोग प्रोग्रामिंग अंतरापृष्ठ (एमएपीआई) का उपयोग करते हैं।
यह भी देखें
- ईमेल क्लाइंटों की तुलना
- मेल सबमिशन एजेंट (एमएसए)
- मेल
- संदेश डिलिवरी एजेंट (एमडीए)
- संदेश स्थानांतरण एजेंट (एमटीए)
- सरल मेल स्थानांतरण प्रोटोकॉल
- पाठ्य-आधारित ईमेल क्लाइंट
संदर्भ
- ↑ C. Hutzler; D. Crocker; P. Resnick; E. Allman; T. Finch (November 2007). "Message Submission Authentication/Authorization Technologies". Email Submission Operations: Access and Accountability Requirements. IETF. sec. 5. doi:10.17487/RFC5068. BCP 134. RFC 5068. Retrieved 24 August 2011.
This document does not provide recommendations on specific security implementations. It simply provides a warning that transmitting user credentials in clear text over insecure networks SHOULD be avoided in all scenarios as this could allow attackers to listen for this traffic and steal account data. In these cases, it is strongly suggested that an appropriate security technology MUST be used.
- ↑ Sill 2003, p. 353: "Like SMTP, POP3 is unencrypted. Unlike SMTP, however, it needs authentication: Users have to identify themselves and prove they're who they claim to be. Unfortunately, the authentication usually consists of presenting a username and a password known only to the user and the POP3 server. Because the POP3 dialogue is unencrypted, an eavesdropper can obtain a user's username and password and reuse them to access the user's mailbox. So, plain POP3 exposes the contents of the mail messages the user retrieves, and it exposes their username and password, which can then be reused by someone else.
Wrapping the POP3 dialogue with transport-layer security such as SSL solves both of these problems. Because SSL-wrapped POP3 sessions are encrypted from beginning to end, no messages, usernames, or passwords are exposed in cleartext.
The optional POP3 command,APOP, replaces the standardUSER/PASSauthentication with a challenge-response authentication mechanism. This solves the problem of the disclosure of reusable passwords, but does nothing to prevent eavesdroppers from reading users' mail messages as they're being retrieved." - ↑ Updated Transport Layer Security (TLS) Server Identity Check Procedure for Email-Related Protocols. doi:10.17487/RFC7817. RFC 7817.
- ↑ Flickenger, Rob (2003). Linux Server Hacks: 100 Industrial-Strength Tips & Tools. O'Reilly Media. p. 146. ISBN 978-0596004613.
In addition to providing remote shell access and command execution, OpenSSH can forward arbitrary TCP ports to the other end of your connection. This can be very handy for protecting email, web, or any other traffic you need to keep private (at least, all the way to the other end of the tunnel).
ssh accomplishes local forwarding by binding to a local port, performing encryption, sending the encrypted data to the remote end of the ssh connection, then decrypting it and sending it to the remote host and port you specify. Start an ssh tunnel with the -L switch (short for Local):root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost
Naturally, substitute user with your username, and mailhost with your mail server's name or IP address. Note that you will have to be root on the laptop for this example since you'll be binding to a privileged port (110, the POP port). You should also disable any locally running POP daemon (look in /etc/inetd.conf) or it will get in the way.
Now to encrypt all of your POP traffic, configure your mail client to connect to localhost port 110. It will happily talk to mailhost as if it were connected directly, except that the entire conversation will be encrypted. - ↑ "Is IMAP Right for Me?". IT Services. Stanford University. 4 March 2010. Retrieved 14 April 2013.
- ↑ "User-Agent". नेटन्यूज़ आलेख प्रारूप. IETF. November 2009. sec. 3.2.13. doi:10.17487/RFC5536. RFC 5536.
Some of this information has previously been sent in non-standardized header fields such as X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, and others
- ↑ J. Palme (February 1997). "Use of gatewaying headers". Common Internet Message Headers. sec. 2. doi:10.17487/RFC2076. RFC 2076. Retrieved May 11, 2015.
Headers defined only in RFC 1036 for use in Usenet News sometimes appear in mail messages, either because the messages have been gatewayed from Usenet News to e-mail, or because the messages were written in combined clients supporting both e-mail and Usenet News in the same client. These headers are not standardized for use in Internet e-mail and should be handled with caution by e-mail agents.
- ↑ Cyrus Daboo (March 2011). Use of SRV Records for Locating Email Submission/Access Services. IETF. doi:10.17487/RFC6186. RFC 6186. Retrieved 17 April 2013.
- ↑ Keith Moore; Chris Newman (January 2018). Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access. IETF. doi:10.17487/RFC8314. RFC 8314. Retrieved 12 February 2018.
ग्रन्थसूची
- Sill, Dave (2003). The qmail Handbook. Apress. ISBN 9781430211341.
- Partridge, Craig (April–June 2008). "The Technical Development of Internet Email" (PDF). IEEE Annals of the History of Computing. 30 (2): 3–29. doi:10.1109/mahc.2008.32. ISSN 1934-1547. S2CID 206442868. Archived from the original (PDF) on 2011-05-12.
