ईमेल क्लाइंट
एक ईमेल क्लाइंट, ईमेल रीडर या, अधिक औपचारिक रूप से, संदेश उपयोगकर्ता एजेंट (एमयूए) या मेल उपयोगकर्ता एजेंट एक कंप्यूटर प्रोग्राम है जिसका उपयोग उपयोगकर्ता के ईमेल तक पहुंचने और प्रबंधित करने के लिए किया जाता है।
एक वेब अप्प जो संदेश प्रबंधन, संरचना और रिसेप्शन फ़ंक्शन प्रदान करता है, एक वेब ईमेल के रूप में कार्य कर सकता है, और कंप्यूटर हार्डवेयर या सॉफ़्टवेयर का एक टुकड़ा जिसकी प्राथमिक या सबसे दृश्य भूमिका ईमेल क्लाइंट के रूप में काम करना है, वह भी इस शब्द का उपयोग कर सकता है।
मेलबॉक्स से संदेश पुनर्प्राप्त करना
अधिकांश क्लाइंट प्रोग्रामों की तरह, एक ईमेल क्लाइंट केवल तभी सक्रिय होता है जब कोई उपयोगकर्ता इसे चलाता है। सामान्य व्यवस्था एक ईमेल उपयोगकर्ता (क्लाइंट) के लिए एक दूरस्थ मेल ट्रांसफ़र एजेंट के साथ व्यवस्था करना है (एमटीए) क्लाइंट के ईमेल की प्राप्ति और भंडारण के लिए सर्वर। एमटीए, एक उपयुक्त मेल डिलीवरी एजेंट (एमडीए) का उपयोग करके, ग्राहक के स्टोरेज में ईमेल संदेश आते ही जोड़ देता है। दूरस्थ मेल संग्रहण को उपयोगकर्ता का ई-मेल मेलबॉक्स कहा जाता है। कई यूनिक्स प्रणालियों पर डिफ़ॉल्ट सेटिंग मेल सर्वर के लिए उपयोगकर्ता की होम निर्देशिका के भीतर, एम बॉक्स में स्वरूपित संदेशों को संग्रहीत करने के लिए है। बेशक, सिस्टम के उपयोगकर्ता लॉग-इन कर सकते हैं और उसी कंप्यूटर पर मेल क्लाइंट चला सकते हैं जो उनके मेलबॉक्स को होस्ट करता है; इस मामले में, सामान्य अर्थ के अलावा, सर्वर वास्तव में दूरस्थ नहीं है।
ईमेल को दूरस्थ सर्वर पर उपयोगकर्ता के मेलबॉक्स में तब तक संग्रहीत किया जाता है जब तक कि उपयोगकर्ता का ईमेल क्लाइंट उन्हें उपयोगकर्ता के कंप्यूटर पर डाउनलोड करने का अनुरोध नहीं करता है, या अन्यथा संभवतः दूरस्थ सर्वर पर उपयोगकर्ता के मेलबॉक्स तक पहुंच नहीं सकता है। ईमेल क्लाइंट को एक ही समय में कई मेलबॉक्सों से कनेक्ट करने और स्वचालित रूप से ईमेल डाउनलोड करने का अनुरोध करने के लिए सेट किया जा सकता है, जैसे कि पूर्व-निर्धारित अंतराल पर, या अनुरोध उपयोगकर्ता द्वारा मैन्युअल रूप से शुरू किया जा सकता है।
उपयोगकर्ता के मेलबॉक्स तक दो समर्पित तरीकों से पहुंचा जा सकता है। डाकघर प्रोटोकॉल (पीओपी) उपयोगकर्ता को एक समय में एक संदेश डाउनलोड करने की अनुमति देता है और स्थानीय भंडारण पर सफलतापूर्वक सहेजे जाने के बाद ही उन्हें सर्वर से हटाता है। किसी अन्य क्लाइंट को उन तक पहुंचने की अनुमति देने के लिए सर्वर पर संदेश छोड़ना संभव है। हालाँकि, किसी विशिष्ट संदेश को देखे गए, उत्तर दिए गए या अग्रेषित के रूप में चिह्नित करने का कोई प्रावधान नहीं है, इस प्रकार पीओपी उन उपयोगकर्ताओं के लिए सुविधाजनक नहीं है जो विभिन्न मशीनों से एक ही मेल तक पहुंचते हैं।
वैकल्पिक रूप से, इंटरनेट संदेश एक्सेस प्रोटोकॉल (आईएमएपी) उपयोगकर्ताओं को उचित रूप में चिह्नित करके सर्वर पर संदेश रखने की अनुमति देता है। IMAP फ़ोल्डर्स और उप-फ़ोल्डर्स प्रदान करता है, जिन्हें संभवतः अलग-अलग एक्सेस अधिकारों के साथ विभिन्न उपयोगकर्ताओं के बीच साझा किया जा सकता है। आमतौर पर, भेजे गए, ड्राफ्ट और ट्रैश फ़ोल्डर डिफ़ॉल्ट रूप से बनाए जाते हैं। आईएमएपी वास्तविक समय के अपडेट के लिए एक आईएमएपी आईडीएलई की सुविधा देता है, जो मतदान की तुलना में तेज़ अधिसूचना प्रदान करता है, जहां लंबे समय तक चलने वाले कनेक्शन संभव हैं। नीचे #दूरस्थ संदेश अनुभाग भी देखें।
JSON मेटा एप्लिकेशन प्रोटोकॉल (JMAP) को HTTP पर JSON API का उपयोग करके कार्यान्वित किया गया है और इसे IMAP/SMTP के विकल्प के रूप में विकसित किया गया है।
इसके अलावा, मेलबॉक्स स्टोरेज को सर्वर पर चल रहे प्रोग्रामों द्वारा या क्लस्टर्ड फ़ाइल सिस्टम##शेयर्ड-डिस्क के माध्यम से सीधे एक्सेस किया जा सकता है। सीधी पहुंच अधिक कुशल हो सकती है लेकिन कम पोर्टेबल है क्योंकि यह मेलबॉक्स प्रारूप पर निर्भर करती है; इसका उपयोग कुछ ईमेल क्लाइंट द्वारा किया जाता है, जिनमें कुछ #वेबमेल एप्लिकेशन भी शामिल हैं।
संदेश रचना
ईमेल क्लाइंट में आमतौर पर टेक्स्ट प्रदर्शित करने और संपादित करने के लिए ग्राफिकल यूज़र इंटरफ़ेस होते हैं। कुछ एप्लिकेशन प्रोग्राम-बाहरी संपादक के उपयोग की अनुमति देते हैं।
ईमेल क्लाइंट इसके अनुसार फ़ॉर्मेटिंग करेंगे RFC 5322 ई-मेल#हेडर और ई-मेल#बॉडी के लिए, और गैर-पाठ्य सामग्री और अनुलग्नकों के लिए MIME। हेडर में गंतव्य फ़ील्ड, To, Cc (कार्बन कॉपी के लिए संक्षिप्त), और Bcc (ब्लाइंड कार्बन कॉपी), और प्रवर्तक फ़ील्ड जिसमें से संदेश का लेखक है, प्रेषक यदि अधिक लेखक हैं, और उत्तर-To शामिल हैं यदि प्रतिक्रियाएँ किसी भिन्न मेलबॉक्स को संबोधित की जानी चाहिए। गंतव्य फ़ील्ड में उपयोगकर्ता की बेहतर सहायता के लिए, कई ग्राहक एक या अधिक पता पुस्तिकाएँ बनाए रखते हैं और/या एलडीएपी निर्देशिका सर्वर से जुड़ने में सक्षम होते हैं। प्रवर्तक क्षेत्रों के लिए, ग्राहक विभिन्न पहचानों का समर्थन कर सकते हैं।
क्लाइंट सेटिंग्स के लिए प्रत्येक उपयोगकर्ता की पहचान के लिए उपयोगकर्ता का वास्तविक नाम और ईमेल पता और संभवतः एलडीएपी सर्वर की एक सूची की आवश्यकता होती है।
सर्वर पर संदेश सबमिट करना
जब कोई उपयोगकर्ता ईमेल बनाना और भेजना चाहता है, तो ईमेल क्लाइंट कार्य संभाल लेगा। ईमेल क्लाइंट आमतौर पर उपयोगकर्ता के मेल सर्वर से कनेक्ट करने के लिए स्वचालित रूप से सेट किया जाता है, जो आमतौर पर या तो मेल सबमिशन एजेंट या मेल परिवहन एजेंट होता है, जो एसएमटीपी प्रोटोकॉल के दो रूप हैं। एसएमटीपी प्रोटोकॉल का उपयोग करने वाला ईमेल क्लाइंट एक प्रमाणीकरण एक्सटेंशन बनाता है, जिसका उपयोग मेल सर्वर प्रेषक को प्रमाणित करने के लिए करता है। यह विधि मॉड्यूलरिटी और खानाबदोश कंप्यूटिंग को आसान बनाती है। पुरानी विधि मेल सर्वर के लिए क्लाइंट के आईपी पते को पहचानने के लिए थी, उदाहरण के लिए क्योंकि क्लाइंट एक ही मशीन पर है और आंतरिक पता 127.0.0.1 का उपयोग करता है, या क्योंकि क्लाइंट का आईपी पता उसी इंटरनेट सेवा प्रदाता द्वारा नियंत्रित किया जाता है जो इंटरनेट एक्सेस और मेल सेवाएं दोनों प्रदान करता है।
क्लाइंट सेटिंग्स के लिए पसंदीदा आउटगोइंग मेल सर्वर का नाम या आईपी पता, पोर्ट नंबर (एमटीए के लिए 25, एमएसए के लिए 587), और प्रमाणीकरण के लिए उपयोगकर्ता नाम और पासवर्ड, यदि कोई हो, की आवश्यकता होती है। परिवहन परत सुरक्षा एन्क्रिप्टेड एसएमटीपी सत्रों के लिए एक गैर-मानक पोर्ट 465 है, जिसे कई क्लाइंट और सर्वर बैकवर्ड संगतता के लिए समर्थन करते हैं।
एन्क्रिप्शन
बिना किसी एन्क्रिप्शन के, पोस्टकार्ड की तरह, ईमेल गतिविधि किसी भी सामयिक छिपकर बात करने वाले द्वारा स्पष्ट रूप से दिखाई देती है। ईमेल एन्क्रिप्शन मेल सत्र, संदेश के मुख्य भाग या दोनों को एन्क्रिप्ट करके गोपनीयता को सुरक्षित रखने में सक्षम बनाता है। इसके बिना, नेटवर्क एक्सेस और सही टूल वाला कोई भी व्यक्ति ईमेल की निगरानी कर सकता है और लॉगिन पासवर्ड प्राप्त कर सकता है। चिंता के उदाहरणों में सरकारी सेंसरशिप और निगरानी और इंटरनेट कैफे जैसे साथी वायरलेस नेटवर्क उपयोगकर्ता शामिल हैं।
उपयोगकर्ता के नाम और पासवर्ड को पैकेट खोजी होने से रोकने के लिए, सभी प्रासंगिक ईमेल प्रोटोकॉल में पूरे सत्र को एन्क्रिप्ट करने का विकल्प होता है। इन्हें खानाबदोश उपयोगकर्ताओं के लिए दृढ़ता से सुझाया जाता है और जब भी इंटरनेट एक्सेस प्रदाता पर भरोसा नहीं किया जाता है।[1] मेल भेजते समय, उपयोगकर्ता केवल क्लाइंट से उसके कॉन्फ़िगर किए गए आउटगोइंग मेल सर्वर पर पहली हॉप पर एन्क्रिप्शन को नियंत्रित कर सकते हैं। किसी भी आगे की स्थिति में, संदेशों को एन्क्रिप्शन के साथ या उसके बिना प्रसारित किया जा सकता है, जो केवल ट्रांसमिटिंग सर्वर के सामान्य कॉन्फ़िगरेशन और प्राप्तकर्ता की क्षमताओं पर निर्भर करता है।
एन्क्रिप्टेड मेल सत्र उपयोगकर्ता के स्थानीय मेलबॉक्स और गंतव्य सर्वर पर उनके मूल प्रारूप, यानी सादे पाठ या एन्क्रिप्टेड बॉडी में संदेश वितरित करते हैं। बाद वाला सर्वर एक ईमेल होस्टिंग सेवा प्रदाता द्वारा संचालित होता है, जो संभवतः वर्तमान में मौजूद इंटरनेट एक्सेस प्रदाता से भिन्न इकाई है।
ईमेल पुनर्प्राप्ति सत्र को एन्क्रिप्ट करना, उदाहरण के लिए, एसएसएल, सत्र के दोनों हिस्सों (प्रमाणीकरण, और संदेश स्थानांतरण) की रक्षा कर सकता है।[2][3] वैकल्पिक रूप से, यदि उपयोगकर्ता के पास अपने मेल सर्वर तक सुरक्षित शेल पहुंच है, तो वे एक एन्क्रिप्टेड सुरंग बनाने के लिए एसएसएच अग्रेषण पोर्ट का उपयोग कर सकते हैं, जिस पर वे अपने ईमेल पुनः प्राप्त कर सकते हैं।[4]
संदेश के मुख्य भाग का एन्क्रिप्शन
क्रिप्टोग्राफ़िक कुंजियों के प्रबंधन के लिए दो मुख्य मॉडल हैं। S/MIME एक विश्वसनीय प्रमाणपत्र प्राधिकारी (CA) पर आधारित एक मॉडल नियोजित करता है जो उपयोगकर्ताओं की सार्वजनिक कुंजी पर हस्ताक्षर करता है। ओपन-पीजीपी कुछ अधिक लचीले भरोसे का जाल तंत्र का उपयोग करता है जो उपयोगकर्ताओं को एक दूसरे की सार्वजनिक कुंजी पर हस्ताक्षर करने की अनुमति देता है। ओपनपीजीपी संदेशों के प्रारूप में भी अधिक लचीला है, इसमें यह अभी भी सादे संदेश एन्क्रिप्शन और हस्ताक्षर का समर्थन करता है जैसा कि वे MIME मानकीकरण से पहले काम करते थे।
दोनों ही मामलों में, केवल संदेश का मुख्य भाग एन्क्रिप्ट किया गया है। प्रवर्तक, प्राप्तकर्ता और अक्सर विषय सहित हेडर फ़ील्ड सादे पाठ में रहते हैं।
वेबमेल
डेस्कटॉप कंप्यूटर पर चलने वाले ईमेल क्लाइंट के अलावा, दूरस्थ रूप से होस्ट किए गए क्लाइंट भी होते हैं, या तो टेलनेट (यानी एक शैल खाता ) द्वारा पहुंच योग्य रिमोट यूनिक्स इंस्टॉलेशन के हिस्से के रूप में, या वर्ल्ड वाइड वेब पर होस्ट किए जाते हैं। इन दोनों दृष्टिकोणों के कई फायदे हैं: वे वेब ब्राउज़र या टेलनेट क्लाइंट का उपयोग करके उपयोगकर्ता के सामान्य आधार से दूर ईमेल भेजने और प्राप्त करने की क्षमता साझा करते हैं, जिससे उपयोगकर्ता के डिवाइस पर एक समर्पित ईमेल क्लाइंट स्थापित करने की आवश्यकता समाप्त हो जाती है।
कुछ वेबसाइटें ईमेल सेवाएँ प्रदान करने के लिए समर्पित हैं, और कई इंटरनेट सेवा प्रदाता अपने इंटरनेट सेवा पैकेज के हिस्से के रूप में वेबमेल सेवाएँ प्रदान करते हैं। वेबमेल की मुख्य सीमाएं यह हैं कि उपयोगकर्ता की बातचीत वेबसाइट के ऑपरेटिंग सिस्टम के अधीन होती है और ईमेल संदेशों को डाउनलोड करने और संदेशों को ऑफ़लाइन लिखने या काम करने में सामान्य असमर्थता होती है, हालांकि ऐसे सॉफ़्टवेयर पैकेज हैं जो वेबमेल कार्यक्षमता के कुछ हिस्सों को ओएस में एकीकृत कर सकते हैं ( उदाहरण के लिए MAPI के माध्यम से तीसरे पक्ष के एप्लिकेशन से सीधे संदेश बनाना)।
IMAP और MAPI की तरह, वेबमेल ईमेल संदेशों को मेल सर्वर पर बने रहने की सुविधा प्रदान करता है। #दूरस्थ संदेश देखें.
दूरस्थ संदेश
POP3 में सर्वर पर संदेश छोड़ने का विकल्प होता है। इसके विपरीत, IMAP और वेबमेल दोनों संदेशों को अपने संचालन के तरीके के रूप में सर्वर पर रखते हैं, हालांकि उपयोगकर्ता अपनी इच्छानुसार स्थानीय प्रतियां बना सकते हैं। सर्वर पर संदेश रखने के फायदे और नुकसान दोनों हैं।[5]
फायदे
- संदेशों को विभिन्न क्लाइंटों का उपयोग करके विभिन्न स्थानों पर विभिन्न कंप्यूटरों या मोबाइल उपकरणों से एक्सेस किया जा सकता है।
- किसी प्रकार का बैकअप आमतौर पर सर्वर द्वारा प्रदान किया जाता है।
नुकसान
- सीमित बैंडविड्थ के साथ, लंबे संदेशों तक पहुंच लंबी हो सकती है, जब तक कि ईमेल क्लाइंट स्थानीय प्रतिलिपि को कैश न कर ले।
- गोपनीयता संबंधी चिंताएँ हो सकती हैं क्योंकि जो संदेश हर समय सर्वर पर रहते हैं, उनके आईटी कर्मियों द्वारा आकस्मिक रूप से एक्सेस किए जाने की संभावना अधिक होती है, जब तक कि एंड-टू-एंड एन्क्रिप्शन का उपयोग नहीं किया जाता है।
प्रोटोकॉल
मेल पुनर्प्राप्त करने के लिए लोकप्रिय प्रोटोकॉल में POP3 और IMAP4 शामिल हैं। मेल भेजना आमतौर पर SMTP प्रोटोकॉल का उपयोग करके किया जाता है।
अधिकांश ईमेल क्लाइंट द्वारा समर्थित एक अन्य महत्वपूर्ण मानक MIME है, जिसका उपयोग बाइनरी फ़ाइल ईमेल संलग्नक भेजने के लिए किया जाता है। अनुलग्नक वे फ़ाइलें हैं जो ईमेल का हिस्सा नहीं हैं लेकिन ईमेल के साथ भेजी जाती हैं।
अधिकांश ईमेल क्लाइंट उपयोगकर्ता-एजेंट का उपयोग करते हैं[6] संदेश भेजने के लिए उपयोग किए गए सॉफ़्टवेयर की पहचान करने के लिए हेडर (कंप्यूटिंग)। यह हेडर फ़ील्ड नेटन्यूज़ के लिए परिभाषित है, लेकिन ई-मेल के लिए नहीं, और, इस प्रकार, गैर-मानक है[7] ई-मेल हेडर में.
RFC 6409, मेल के लिए संदेश सबमिशन, मेल सबमिशन एजेंट की भूमिका का विवरण देता है।
RFC 5068, ईमेल सबमिशन ऑपरेशंस: एक्सेस और जवाबदेही आवश्यकताएँ, एमटीए, एमएसए, एमडीए और एमयूए की अवधारणाओं का एक सर्वेक्षण प्रदान करता है। इसमें उल्लेख किया गया है कि एक्सेस प्रदाताओं को उपयोगकर्ताओं को सबमिशन पोर्ट 587 का उपयोग करके बाहरी इंटरनेट तक पहुंचने से नहीं रोकना चाहिए और एमयूए को संदेश सबमिशन के लिए सबमिशन पोर्ट का उपयोग करना चाहिए।
RFC 5965, ईमेल फीडबैक रिपोर्ट के लिए एक एक्स्टेंसिबल प्रारूप, एक एक्स्टेंसिबल प्रारूप और एमआईएमई प्रकार प्रदान करता है जिसका उपयोग मेल ऑपरेटरों द्वारा अन्य पार्टियों को प्राप्त ईमेल के बारे में फीडबैक रिपोर्ट करने के लिए किया जा सकता है।
पोर्ट संख्या
परंपरा के अनुसार ईमेल सर्वर और क्लाइंट निम्न तालिका में टीसीपी और यूडीपी पोर्ट नंबरों की सूची का उपयोग करते हैं। एमएसए, आईएमएपी और पीओपी3 के लिए, तालिका उन लेबलों की भी रिपोर्ट करती है जिनका उपयोग ग्राहक एसआरवी रिकार्ड को क्वेरी करने और संबंधित सेवा के होस्ट नाम और पोर्ट नंबर दोनों को खोजने के लिए कर सकता है।[8]
| Protocol | Use | Plain text or encrypt sessions |
Plain text sessions only |
Encrypt sessions only |
|---|---|---|---|---|
| POP3 | incoming mail | 110 _pop3._tcp |
995 _pop3s._tcp | |
| IMAP4 | incoming mail | 143 _imap._tcp |
993 _imaps._tcp | |
| SMTP | outgoing mail | 25 | 587 | |
| MSA | outgoing mail | 587 _submission._tcp |
465[9] _submissions._tcp | |
| HTTP | webmail | 80 | 443 |
जबकि वेबमेल एन्क्रिप्ट और सादे पाठ सत्रों के लिए अलग-अलग पोर्ट रखने के पहले HTTP स्वभाव का पालन करता है, मेल प्रोटोकॉल STARTTLS तकनीक का उपयोग करते हैं, जिससे एन्क्रिप्शन को पहले से स्थापित टीसीपी कनेक्शन पर शुरू करने की अनुमति मिलती है। जबकि RFC 2595 पहले से स्थापित बंदरगाहों 995 और 993 के उपयोग को हतोत्साहित करने के लिए उपयोग किया जाता है, RFC 8314 उपलब्ध होने पर अंतर्निहित ट्रांसपोर्ट लेयर सुरक्षा के उपयोग को बढ़ावा देता है।
मालिकाना क्लाइंट प्रोटोकॉल
Microsoft मेल सिस्टम Microsoft एक्सचेंज सर्वर इलेक्ट्रॉनिक मेल सर्वर तक पहुँचने के लिए Microsoft आउटलुक जैसे क्लाइंट अनुप्रयोगों में मालिकाना सॉफ़्टवेयर मैसेजिंग एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (MAPI) का उपयोग करते हैं।
यह भी देखें
- ईमेल क्लाइंट की तुलना
- मेल सबमिशन एजेंट (एमएसए)
- इन्हें मेल करें
- संदेश वितरण एजेंट (एमडीए)
- संदेश स्थानांतरण एजेंट (एमटीए)
- सरल डाक स्थानांतरण प्रोटोकॉल
- टेक्स्ट-आधारित ईमेल क्लाइंट
संदर्भ
- ↑ 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.
