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