ईमेल क्लाइंट
एक ईमेल ग्राहक, ईमेल पठक या, और औपचारिक रूप से, संदेश उपयोक्ता एजेंट (एमयूए) या मेल उपयोक्ता एजेंट एक कंप्यूटर प्रोग्राम होता है जिसका उपयोग उपयोक्ता के ईमेल तक अभिगम करने और प्रबंधन करने के लिए किया जाता है।
एक वेब अनुप्रयोग जो संदेश प्रबंधन, संयोजन और अभिग्रहण प्रकार्यों को प्रदान करता है तथा एक वेब ईमेल ग्राहक के रूप में कार्य कर सकता है, और कंप्यूटर हार्डवेयर या सॉफ़्टवेयर का एक भाग जिसकी प्राथमिक या सबसे अधिक दिखाई देने वाली भूमिका ईमेल ग्राहक के रूप में काम करना है, वह भी इस शब्द का उपयोग कर सकता है।
मेलबॉक्स से संदेश पुनर्प्राप्त करना
अधिकांश ग्राहक प्रोग्रामों की तरह, एक ईमेल ग्राहक केवल तभी सक्रिय होता है जब कोई उपयोक्ता इसे चलाता है। सामान्य व्यवस्था एक ईमेल उपयोक्ता (ग्राहक) के लिए ग्राहक के ईमेल के अभिग्रहण और भंडारण के लिए दूरस्थ मेल अंतरण एजेंट (एमटीए) सर्वर के साथ व्यवस्था करना है। एमटीए, एक उपयुक्त मेल वितरण एजेंट (एमडीए) का उपयोग करके, ग्राहक के भंडारण में ईमेल संदेश आते ही जोड़ देता है। दूरस्थ मेल संग्रहण को उपयोक्ता का मेलबॉक्स कहा जाता है। कई यूनिक्स तंत्रों पर व्यतिक्रम सेटिंग मेल सर्वर के लिए उपयोक्ता की निजी निर्देशिका के भीतर तथा एमबॉक्स में संरूपित संदेशों को संग्रहीत करने के लिए है। निस्सन्देह, तंत्र के उपयोक्ता लॉग-इन कर सकते हैं और उसी कंप्यूटर पर मेल क्लाइंट चला सकते हैं जो उनके मेलबॉक्स को होस्ट करता है; इस स्थिति में, सामान्य अर्थ के अतिरिक्त, सर्वर वास्तव में सुदूर नहीं है।
ईमेल को सुदूर सर्वर पर उपयोगकर्ता के मेलबॉक्स में तब तक संग्रहीत किया जाता है जब तक कि उपयोगकर्ता का ईमेल क्लाइंट उन्हें उपयोगकर्ता के कंप्यूटर पर डाउनलोड करने का अनुरोध नहीं करता है, या अन्यथा संभवतः सुदूर सर्वर पर उपयोगकर्ता के मेलबॉक्स तक अभिगम नहीं किया जा सकता है। ईमेल क्लाइंट को एक ही समय में कई मेलबॉक्सों से संबंधित करने और स्वचालित रूप से ईमेल डाउनलोड करने का अनुरोध करने के लिए सेट किया जा सकता है, जैसे कि पूर्व-निर्धारित अंतरालों पर, या उपयोक्ता द्वारा अनुरोध मैन्युअल रूप से शुरू किया जा सकता है।
उपयोक्ता के मेलबॉक्स तक दो समर्पित तरीकों से अभिगम किया जा सकता है। पोस्ट ऑफिस प्रोटोकाॅल (पीओपी) उपयोक्ता को एक समय में एक संदेश डाउनलोड करने की अनुमति देता है और स्थानीय भंडारण पर सफलतापूर्वक सहेजे जाने के बाद ही उन्हें सर्वर से हटाता है। किसी अन्य ग्राहक को उन तक अभिगम करने की अनुमति देने के लिए सर्वर पर संदेशों को छोड़ना संभव है। हालांकि, किसी विशिष्ट संदेश को देखा गया, उत्तर दिया गया या आगे भेजा गया इसे चिह्नित करने के लिए कोई प्रावधान नहीं है, इस प्रकार पीओपी उन उपयोक्ताओं के लिए सुविधाजनक नहीं है जो विभिन्न यंत्रों से एक ही मेल तक अभिगम करते हैं।
वैकल्पिक रूप से, इंटरनेट संदेश अभिगम संदेशाचार (आईएमएपी) उपयोक्ताओं को संदेशों को सर्वर पर रखने देता है तथा उन्हें उपयुक्त रूप में चिह्नित करने की सुविधा प्रदान करता है। आईएमएपी फ़ोल्डर्स और उप-फ़ोल्डर्स प्रदान करता है, जिन्हें विभिन्न उपयोगकर्ताओं के बीच साझा किया जा सकता है, जिनमें संभावत: विभिन्न अभिगम अधिकार हो सकते हैं। आमतौर पर, प्रेषित, ड्राफ्ट औरट्रैश फ़ोल्डर व्यतिक्रम रूप से बनाए जाते हैं। आईएमएपी में वास्तविक समय के अद्यतन के लिए एकअक्रिय विस्तार की सुविधा है, जो क्रमवरण की तुलना में तेज़ अधिसूचना प्रदान करता है तथा जहां लंबे समय तक चलने वाले संबंध संभव हैं। नीचे सुदूर संदेश अनुभाग भी देखें।
JSON मेटा अनुप्रयोग संदेशाचार (JMAP) को HTTP पर JSON API का उपयोग करके कार्यान्वित किया गया है और इसे IMAP/SMTP के विकल्प के रूप में विकसित किया गया है।
इसके अतिरिक्त, मेलबॉक्स भण्डारण को सर्वर पर चल रहे प्रोग्राम या सहभाजी डिस्क के माध्यम से सीधे अभिगम किया जा सकता है। प्रत्यक्ष अभिगम अधिक सक्षम हो सकता है लेकिन यह सुवाहय नहीं होता क्योंकि यह मेलबॉक्स संरुप पर निर्भर करता है; इसका उपयोग कुछ ईमेल ग्राहकों द्वारा किया जाता है, जिनमें कुछ वेबमेल अनुप्रयोग भी सम्मिलित हैं।
संदेश संयोजन
ईमेल क्लाइंटों में आमतौर पर उपयोक्ता अंतरापृष्ठ सम्मिलित होते हैं जो पाठ्य को प्रदर्शित और संपादित करने के लिए होते हैं। कुछ अनुप्रयोगों में प्रोग्राम-बाह्य संपादक का उपयोग करने की अनुमति होती है।
ईमेल ग्राहक प्रवेशिका और निकाय के लिए RFC 5322 और गैर-पाठ्य अन्तर्वस्तु और संलग्नकों के लिए एमआईएमई के अनुसार संरूपण करते हैं। प्रवेशिका में गंतव्य क्षेत्रों से सीसी (कार्बन कॉपी के लिए संक्षिप्त), और बीसीसी (ब्लाइंड कार्बन कॉपी), और प्रवर्तक क्षेत्र सम्मिलित हैं | गंतव्य क्षेत्रो में उपयोक्ता की बेहतर सहायता के लिए, कई ग्राहक एक या अधिक पता पुस्तिकाएँ बनाए रखते हैं और/या एलडीएपी निर्देशिका सर्वर से जुड़ने में सक्षम होते हैं। प्रवर्तक क्षेत्रों के लिए, ग्राहक विभिन्न पहचानों का समर्थन कर सकते हैं।
ग्राहक सेटिंग्स के लिए प्रत्येक उपयोक्ता की पहचान के लिए उपयोक्ता कावास्तविक नाम औरईमेल पता और संभवतः एलडीएपी सर्वर की एक सूची की आवश्यकता होती है।
सर्वर पर संदेश प्रस्तुत करना
जब कोई उपयोक्ता ईमेल बनाना और भेजना चाहता है, तो ईमेल ग्राहक इस कार्य का संचालन करता है | ईमेल ग्राहक आमतौर पर उपयोक्ता के मेल सर्वर से संबंधित करने के लिए स्वचालित रूप से सेट किया जाता है, जो आमतौर पर या तो एमएसए या एमटीए होता है, जो एसएमटीपी संदेशाचार के दो रूप हैं। एसएमटीपी संदेशाचार का उपयोग करने वाला ईमेल ग्राहक एक सत्यापन विस्तार बनाता है, जिसका उपयोग मेल सर्वर प्रेषक को सत्यापित करने के लिए करता है। यह विधि माड्यूलता और नोमेडिक कंप्यूटिंग को आसान बनाती है। पुरानी विधि मेल सर्वर के लिए ग्राहक के आईपी पते को पहचानने के लिए थी, उदाहरण के लिए क्योंकि ग्राहक एक ही यंत्र पर है और आंतरिक पता 127.0.0.1 का उपयोग करता है, या क्योंकि ग्राहक का आईपी पता उसी इंटरनेट सेवा प्रदाता द्वारा नियंत्रित किया जाता है जो इंटरनेट अभिगम और मेल सेवाएं दोनों प्रदान करता है।
ग्राहक सेटिंग्स के लिए मुख्य निवर्तमान मेल सर्वर का नाम या आईपी पता, पोर्ट संख्या (एमटीए के लिए 25, एमएसए के लिए 587), और प्रमाणीकरण के लिए उपयोक्ता नाम और पासवर्ड, यदि कोई हो, की आवश्यकता होती है। एसएसएल एन्क्रिप्टेड एसएमटीपी सत्रों के लिए एक अमानक पोर्ट 465 है, जिसे कई ग्राहक और सर्वर पश्च संगतता के लिए समर्थन करते हैं।
एन्क्रिप्शन
बिना किसी एन्क्रिप्शन के, पोस्टकार्ड की तरह, ईमेल सक्रियता किसी भी सामयिक प्रच्छन्नश्रावी द्वारा स्पष्ट रूप से दिखाई देती है। ईमेल एन्क्रिप्शन मेल सत्र, संदेश के मुख्य भाग या दोनों को एन्क्रिप्ट करके गोपनीयता को सुरक्षित रखने में सक्षम बनाता है। इसके बिना, नेटवर्क अभिगम करने और सही टूल वाला कोई भी व्यक्ति ईमेल की जांच कर सकता है और लॉगिन पासवर्ड प्राप्त कर सकता है। चिंता के उदाहरणों में सरकारी सेंसरशिप और जांच और इंटरनेट कैफे जैसे साथी बेतार नेटवर्क उपयोक्ता सम्मिलित हैं।
सभी उपयुक्त ईमेल संदेशाचारों में पूरे सत्र को एनक्रिप्ट करने का एक विकल्प होता है, जिससे उपयोगकर्ता केनाम औरपासवर्ड को स्निफ़ किया जाने से रोका जा सकता है। इन्हें नोमेडिक उपयोक्ताओं के लिए दृढ़ता से व्यक्त किया जाता है और जब भी इंटरनेट अभिगम प्रदाता पर विश्वास नहीं किया जाता है।[1] मेल भेजते समय, उपयोक्ता केवल पहले प्लुति के लिए एन्क्रिप्शन को नियंत्रित कर सकते हैं, जो एक ग्राहक से उसके कॉन्फ़िगर किए गए निवर्तमान मेल सर्वर तक होता है। किसी भी अन्य प्लुति में, संदेशों को एन्क्रिप्शन के साथ या उसके बिना प्रसारित किया जा सकता है, जो केवल संचरण सर्वर के सामान्य विन्यास और प्राप्तकर्ता की क्षमताओं पर निर्भर करता है।
एन्क्रिप्टेड मेल सत्र उपयोक्ता के स्थानीय मेलबॉक्स और गंतव्य सर्वर पर उनके मूल संरूप, यानी सादे पाठ या एन्क्रिप्टेड निकाय में संदेश वितरित करते हैं। बाद वाला सर्वर एक ईमेल होस्टिंग सेवा प्रदाता द्वारा संचालित होता है, जो संभवतः वर्तमान में उपस्थित इंटरनेट अभिगम प्रदाता से भिन्न इकाई का है।
ईमेल पुनर्प्राप्ति सत्र को एन्क्रिप्ट करना, उदाहरण के लिए, एसएसएल, सत्र के दोनों भागों (प्रमाणीकरण, और संदेश स्थानांतरण) की सुरक्षा कर सकता है।[2][3]
वैकल्पिक रूप से, यदि उपयोक्ता के पास अपने मेल सर्वर तक एसएसएच अभिगम है, तो वे एक एन्क्रिप्टेड टनल बनाने के लिए एसएसएच पोर्ट अग्रक का उपयोग कर सकते हैं, जिस पर वे अपने ईमेल पुनः प्राप्त कर सकते हैं।[4]
संदेश के मुख्य भाग का एन्क्रिप्शन
क्रिप्टोग्राफ़िक कुंजियों के प्रबंधन के लिए दो प्रमुख प्रारूप हैं। S/MIME एक विश्वसनीय प्रमाणपत्र प्राधिकारी (सीए) पर आधारित एक प्रारूप नियोजित करता है जो उपयोक्ताओं की सार्वजनिक कुंजियों पर हस्ताक्षर करता है। ओपनपीजीपीट्रस्ट यंत्र के कुछ अधिक नम्य वेब को नियोजित करता है जो उपयोक्ताओं को एक दूसरे की सार्वजनिक कुंजियों पर हस्ताक्षर करने की अनुमति देता है। ओपनपीजीपी संदेशों के संरूप में भी अधिक नम्य है, जिसमें यह अभी भी सादे संदेश एन्क्रिप्शन और हस्ताक्षर करने का समर्थन करता है क्योंकि कि वे MIME मानकीकरण से पहले काम करते थे।
दोनों ही स्थितियों में, केवल संदेश का मुख्य भाग एन्क्रिप्ट किया गया है। प्रवर्तक, प्राप्तकर्ता और अधिकतर विषय सहित प्रवेशिका क्षेत्र सादे पाठ में रहते हैं।
वेबमेल
डेस्कटॉप कंप्यूटर पर चलने वाले ईमेल ग्राहकों के अतिरिक्त, सुदूर रूप से होस्ट किए गए ग्राहक भी होते हैं, या तो टेलनेट (यानी एक शैल खाता) द्वारा अभिगम योग्य सुदूर यूनिक्स अधिष्ठापन के भाग के रूप में, या वेब पर होस्ट किए जाते हैं। इन दोनों दृष्टिकोणों के कई लाभ हैं: वे वेब ब्राउज़र या टेलनेट ग्राहक का उपयोग करके उपयोक्ता के सामान्य आधार से दूर ईमेल भेजने और प्राप्त करने की क्षमता साझा करते हैं, जिससे उपयोक्ता के उपकरण पर एक समर्पित ईमेल ग्राहक स्थापित करने की आवश्यकता समाप्त हो जाती है।
कुछ वेबसाइटें ईमेल सेवाएँ प्रदान करने के लिए प्रस्तुत हैं, और कई इंटरनेट सेवा प्रदाता अपने इंटरनेट सेवा पैकग के भाग के रूप में वेबमेल सेवाएँ प्रदान करते हैं। वेबमेल की प्रमुख सीमाएँ यह हैं कि उपयोक्ता की अन्योन्यक्रियाऐं वेबसाइट के प्रचालन तंत्र के अधीन होती है और ईमेल संदेशों को डाउनलोड करने और संदेशों को ऑफ़लाइन लिखने या काम करने में सामान्य असमर्थता होती है, हालांकि ऐसे सॉफ़्टवेयर पैकग हैं जो वेबमेल प्रकार्यात्मकता के कुछ भागों को ओएस में एकीकृत कर सकते हैं (उदाहरण के लिए एमएपीआई के माध्यम से तीसरे पक्ष के अनुप्रयोग से सीधे संदेश बनाना)।
आईएमएपी और एमएपीआई की तरह, वेबमेल ईमेल संदेशों को मेल सर्वर पर बने रहने की सुविधा प्रदान करता है। अगला भाग देखें |
सुदूर संदेश
पीओपी3 में सर्वर पर संदेश छोड़ने का विकल्प होता है। इसके विपरीत, आईएमएपी और वेबमेल दोनों सर्वर पर संदेशों को अपने प्रचालन की विधि के रूप में रखते हैं, हालांकि उपयोक्ता अपनी इच्छानुसार स्थानीय प्रतियां बना सकते हैं। सर्वर पर संदेशों को रखने के लाभ और हानि दोनों हैं।[5]
लाभ
- संदेशों को विभिन्न क्लाइंटों का उपयोग करके विभिन्न स्थानों पर विभिन्न कंप्यूटरों या मोबाइल उपकरणों से अभिगम किया जा सकता है।
- किसी प्रकार का बैकअप आमतौर पर सर्वर द्वारा प्रदान किया जाता है।
हानि
- सीमित बैंडविड्थ के साथ, लंबे संदेशों का अभिगम लंबा समय ले सकता है, जब तक कि ईमेल ग्राहक स्थानीय प्रतिलिपि को कैश न कर ले।
- गोपनीयता संबंधी चिंताएँ हो सकती हैं क्योंकि सर्वर पर हर समय रहने वाले संदेशों को आईटी कर्मिकों द्वारा आकस्मिक रूप से अभिगम किए जाने की अधिक संभावना होती है, जब तक कि आद्यांत अनुप्रयोग का उपयोग नहीं किया जाता है।
संदेशाचार
मेल पुनर्प्राप्त करने के लिए लोकप्रिय संदेशाचारों में POP3 और IMAP4 सम्मिलित हैं। मेल भेजने के लिए आमतौर पर एसएमटीपी संदेशाचार का उपयोग किया जाता है।
अधिकांश ईमेल ग्राहकों द्वारा समर्थित एक अन्य महत्वपूर्ण मानक एमआईएमई है, जिसका उपयोग बाइनरी फ़ाइल ईमेल संलग्नक भेजने के लिए किया जाता है। संलग्नक वे फ़ाइलें हैं जो ईमेल का भाग नहीं होती हैं लेकिन ईमेल के साथ भेजी जाती हैं।
अधिकांश ईमेल ग्राहक संदेश भेजने के लिए उपयोग किए जाने वाले सॉफ़्टवेयर की पहचान करने के लिए उपयोक्ता-एजेंट प्रवेशिका क्षेत्र का उपयोग करते हैं।[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 |
जबकि वेबमेल एन्क्रिप्ट और सादे पाठ सत्रों के लिए अलग-अलग संद्वार रखने के पहले एचटीटीपी प्रबंध का पालन करता है, मेल संदेशाचार STARTTLS तकनीक का उपयोग करते हैं, जिससे एन्क्रिप्शन को पहले से स्थापित टीसीपी संबंध पर शुरू करने की अनुमति मिलती है। जबकि RFC 2595 पहले से स्थापित संद्वारों 995 और 993 के उपयोग को निषेध करता था, RFC 8314 उपलब्ध होने पर अंतर्निहित टीएलएस के उपयोग को बढ़ावा देता है।
सांपत्तिक ग्राहक संदेशाचार
माइक्रोसॉफ्ट मेल तंत्र माइक्रोसॉफ्ट विनिमय इलेक्ट्रॉनिक मेल सर्वर तक अभिगमन के लिए माइक्रोसॉफ्ट आउटलुक जैसे ग्राहक अनुप्रयोगों में सांपत्तिक संदेश अनुप्रयोग प्रोग्रामिंग अंतरापृष्ठ (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.
