ईमेल: Difference between revisions

1983 में ARPANET पर [[ सरल डाक स्थानांतरण प्रोटोकॉल ]](SMTP) लागू किया गया था। 1980 के दशक के मध्य में लोकल एरिया नेटवर्क ईमेल सिस्टम का उदय हुआ। 1980 के दशक के अंत मे और 1990 के दशक की शुरुआत में एक समय, यह संभावना प्रतीत हुई कि या तो एक मालिकाना वाणिज्यिक प्रणाली या X.400 ईमेल प्रणाली, [[ गवर्नमेंट ओपन सिस्टम्स इंटरकनेक्शन प्रोफाइल ]] (GOSIP) का हिस्सा, प्रबल होगया। हालांकि, 1995 में इंटरनेट पर वाणिज्यिक यातायात ले जाने पर अंतिम प्रतिबंध समाप्त होने के बाद, ref>[https://merit.edu/research/nsfnet_article.php NSFNET बैकबोन सर्विस को रिटायर करना: एक युग के अंत का इतिहास] {{webarchive|url=https://web.archive.org/web/20160101025735/https://merit.edu/research/nsfnet_article.php |date=2016-01-01 }}, सुसान आर. हैरिस, पीएच.डी., और एलिस गेरिच, कनेक्शंस, वॉल्यूम। 10, नंबर 4, अप्रैल 1996</ref><ref>{{cite journal | url= https://www.walthowe.com/navnet/history.html | title= इंटरनेट का एक संक्षिप्त इतिहास| url-status= live | archive-url= https://web.archive.org/web/20150811053448/https://www.walthowe.com/navnet/history.html | archive-date= 2015-08-11 | bibcode= 1999cs........1011L | last1= Leiner | first1= Barry M. | last2= Cerf | first2= Vinton G. | last3= Clark | first3= David D. | last4= Kahn | first4= Robert E. | last5= Kleinrock | first5= Leonard | last6= Lynch | first6= Daniel C. | last7= Postel | first7= Jon | last8= Roberts | first8= Larry G. | last9= Wolf | first9= Stephen | year= 1999 | arxiv= cs/9901011 }}</ref>  कारकों के संयोजन ने SMTP, POP3 और IMAP ईमेल प्रोटोकॉल के वर्तमान इंटरनेट सूट को मानक बना दिया।।{{Refn|See [[Protocol Wars]].|group=nb}}

# एमयूए ईमेल प्रारूप में संदेश को प्रारूपित करता है और इस मामले में smtp.a.org को स्थानीय मेल सबमिशन एजेंट (एमएसए) को संदेश सामग्री भेजने के लिए सरल मेल ट्रांसफर प्रोटोकॉल (एसएमटीपी) की एक प्रोफाइल सबमिशन प्रोटोकॉल का उपयोग करता है।

# smtp.a.org SMTP का उपयोग करके mx.b.org को संदेश भेजता है। अंतिम संदेश वितरण एजेंट (एमडीए) तक संदेश पहुंचने से पहले इस सर्वर को संदेश अन्य एमटीए को अग्रेषित करने की आवश्यकता हो सकती है।

}}</ref>  हेडर को ईमेल के बारे में, सीसी,  विषय, दिनांक और अन्य जानकारी जैसे फ़ील्ड में संरचित किया गया है। सिस्टम के बीच ईमेल संदेशों के  परिवाहक की प्रक्रिया में, एसएमटीपी (SMTP) संदेश हेडर फ़ील्ड का उपयोग करके वितरण मापदंडों और सूचनाओं का संचार करता है।  मुख्य भाग में संदेश होता है, असंरचित पाठ के रूप में, कभी-कभी अंत में एक हस्ताक्षर ब्लॉक होता है। शीर्षलेख को मुख्य भाग से एक रिक्त रेखा द्वारा अलग किया जाता है।

प्रत्येक फ़ील्ड का नाम हेडर सेक्शन में एक नई पंक्ति के पहले वर्ण से शुरू होता है, और एक गैर-व्हाट्सएप प्रिंट करने योग्य वर्ण से शुरू होता है। यह विभाजक वर्ण : के साथ समाप्त होता है। विभाजक के बाद फ़ील्ड मान(फ़ील्ड बॉडी) होता है। मान बाद की पंक्तियों पर जारी रह सकता है यदि उन पंक्तियों में उनके पहले वर्ण के रूप में स्थान या टैब हो। फ़ील्ड नाम और, SMTPUTF8 के बिना, फ़ील्ड निकाय 7-बिट ASCII वर्णों तक सीमित हैं। कुछ गैर-ASCII मानों को MIME एन्कोडेड शब्दों का उपयोग करके प्रदर्शित किया जा सकता है।

* प्रति: ईमेल पता(पते), और वैकल्पिक रूप से संदेश के प्राप्तकर्ताओं के नाम प्राथमिक प्राप्तकर्ताओं को इंगित करता है,(एकाधिक अनुमत), द्वितीयक प्राप्तकर्ताओं के लिए नीचे Cc: और Bcc: देखें।

* बीसीसी: ब्लाइंड कार्बन कॉपी; पते सामान्यतः केवल SMTP वितरण के दौरान निर्दिष्ट किए जाते हैं, और सामान्यतः संदेश शीर्षलेख में सूचीबद्ध नहीं होते हैं।

* वरीयता: सामान्यतः  "बल्क", "जंक", या "लिस्ट" मानों के साथ; स्वचालित "अवकाश" या "कार्यालय से बाहर" इंगित करने के लिए उपयोग की जाने वाली प्रतिक्रियाओं को इस मेल के लिए वापस नहीं किया जाना चाहिए, उदा। मेलिंग सूची के अन्य सभी ग्राहकों को अवकाश नोटिस भेजे जाने से रोकने के लिए। Send mail कतारबद्ध ईमेल की प्राथमिकता को प्रभावित करने के लिए इस फ़ील्ड का उपयोग करता है, "वरीयता: विशेष-वितरण" संदेशों को जल्द ही वितरित किया जाता है। आधुनिक उच्च-बैंडविड्थ नेटवर्क के साथ, वितरण प्राथमिकता पहले से कम समस्या है। माइक्रोसॉफ्ट एक्सचेंज एक बारीक-बारीक स्वचालित प्रतिक्रिया दमन तंत्र, X-ऑटो-रिस्पांस-सप्रेस फ़ील्ड का सम्मान करता है।<ref>Microsoft, Auto Response Suppress, 2010, [https://msdn.microsoft.com/en-us/library/ee219609(v=EXCHG.80).aspx Microsoft reference] {{webarchive|url=https://web.archive.org/web/20110407033540/https://msdn.microsoft.com/en-us/library/ee219609(v=EXCHG.80).aspx |date=2011-04-07 }}, 2010 Sep 22</ref>

* प्रेषक: प्रेषक का पता जो प्रेषक: फ़ील्ड(सचिव, सूची प्रबंधक, आदि) में सूचीबद्ध लेखक की ओर से कार्य करता है।

* आर्काइव्ड-एट: एक व्यक्तिगत ईमेल संदेश के आर्काइव्ड फॉर्म का सीधा लिंक।

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

SMTP निम्नलिखित दो क्षेत्रों का उपयोग करके हेडर में सहेजे गए संदेश की ट्रेस जानकारी को परिभाषित करता है:<ref>{{cite IETF|title=सरल डाक स्थानांतरण प्रोटोकॉल|rfc=5321|author=[[John Klensin]]|sectionname=Trace Information|section=4.4| date=October 2008 |publisher=[[Internet Engineering Task Force|IETF]]}}</ref>

* प्राप्त: एक SMTP सर्वर द्वारा एक संदेश स्वीकार करने के बाद, यह हेडर के शीर्ष पर इस ट्रेस रिकॉर्ड को सम्मिलित करता है(अंतिम से पहले)।

* रिटर्न-पाथ: डिलीवरी के बाद SMTP सर्वर किसी संदेश की अंतिम डिलीवरी करता है, यह हेडर के शीर्ष पर इस फ़ील्ड को सम्मिलित करता है।

* डीकेआईएम-हस्ताक्षर: यह सत्यापित करने के लिए कि संदेश भेजे जाने के बाद बदला नहीं गया था, [[ DomainKeys Identified Mail | Domain Keys Identified Mail]](DKIM) डिक्रिप्शन के परिणामों को संग्रहीत करता है।<ref name="DKIM">{{cite journal |title=लात मारो|year=2011 |doi=10.17487/लात मारो|url=https://tools.ietf.org/html/rfc6376 |access-date=28 January 2020|editor-last1=Crocker |editor-last2=Hansen |editor-last3=Kucherawy |editor-first1=D |editor-first2=T |editor-first3=M |last1=Crocker |first1=D. |last2=Hansen |first2=T. |last3=Kucherawy |first3=M. }}</ref>

====सादा पाठ और HTML====

अधिकांश आधुनिक ग्राफ़िक ईमेल क्लाइंट उपयोगकर्ता के विकल्प पर संदेश के मुख्य भाग के लिए सादा पाठ या HTML#HTML ई-मेल के उपयोग की अनुमति देते हैं। HTML ईमेल संदेशों में आधिकांश्तःअनुकूलता के लिए स्वचालित रूप से जेनरेट की गई सादा पाठ प्रति सम्मलित होती है।

HTML के लाभों में इन-लाइन लिंक और छवियों को सम्मलित करने की क्षमता सम्मलित है, पिछले संदेशों को [[ ब्लॉक उद्धरण ]] में अलग करना, किसी भी डिस्प्ले पर स्वाभाविक रूप से लपेटना, [[ रेखांकन ]] और इटैलिक जैसे जोर का उपयोग करना और [[ फ़ॉन्ट ]] शैलियों को बदलना सम्मलित है। नुकसान में ईमेल का बढ़ा हुआ आकार, [[ वेब बग ]] के बारे में गोपनीयता संबंधी चिंताएं, [[ फ़िशिंग ]] हमलों के लिए वेक्टर के रूप में HTML ईमेल का दुरुपयोग और [[ मैलवेयर ]] का प्रसार सम्मलित हैं।<ref>{{cite web|url=https://advosys.ca/papers/mail-policies.html|title=ईमेल नीतियां जो वायरस को रोकती हैं|archive-url=https://web.archive.org/web/20070512053927/https://advosys.ca/papers/mail-policies.html|archive-date=2007-05-12|url-status=bot: unknown}}</ref>

कुछ ई-मेल क्लाइंट एक के अभाव में भी शरीर को HTML के रूप में व्याख्या करते हैं <code>Content-Type: html</code> हेडर फ़ील्ड; इससे विभिन्न समस्याएं हो सकती हैं।

URI योजना, जैसा कि IANA के साथ पंजीकृत है, मेल को परिभाषित करती है: SMTP ईमेल पतों के लिए योजना। हालांकि इसके उपयोग को सख्ती से परिभाषित नहीं किया गया है, इस फॉर्म के यूआरएल का उपयोग यूआरएल सक्रिय होने पर उपयोगकर्ता के मेल क्लाइंट की नई संदेश विंडो खोलने के लिए किया जाता है, यूआरएल द्वारा प्रति: फ़ील्ड में परिभाषित पते के साथ। <ref>RFC 2368 section 3 : by Paul Hoffman in 1998 discusses operation of the "mailto" URL.</ref><ref name="Barnett 2011 p. 245" /> कई ग्राहक अन्य ईमेल क्षेत्रों के लिए क्वेरी स्ट्रिंग मापदंडों का भी समर्थन करते हैं, जैसे कि इसकी विषय पंक्ति या कार्बन कॉपी प्राप्तकर्ता।<ref>{{Cite web|url=https://developer.mozilla.org/en-US/docs/Learn/HTML/Introduction_to_HTML/Creating_hyperlinks|title=हाइपरलिंक बनाना § ई-मेल लिंक|website=MDN Web Docs|language=en|access-date=2019-09-30}}</ref>

ईमेल संदेशों में एक या एक से अधिक अटैचमेंट हो सकते हैं, जो ईमेल में संलग्न अतिरिक्त फाइलें होती हैं। विशिष्ट अनुलग्नकों में Microsoft Word दस्तावेज़, PDF दस्तावेज़ और कागज दस्तावेज़ों की स्कैन की गई छवियां सम्मलित हैं। सिद्धांत रूप में, अनुलग्नकों के आकार या संख्या पर कोई तकनीकी प्रतिबंध नहीं है। हालाँकि, व्यवहार में, ईमेल क्लाइंट, सर्वर(कंप्यूटिंग) और इंटरनेट सेवा प्रदाता फ़ाइलों के आकार, या पूर्ण ईमेल - सामान्यतः  पर 25MB या उससे कम पर विभिन्न सीमाओं को लागू करते हैं।<ref>[https://exchangepedia.com/2007/09/exchange-server-2007-setting-message-size-limits.html ''"Setting Message Size Limits in Exchange 2010 and Exchange 2007"''] {{webarchive|url=https://web.archive.org/web/20130212114611/https://exchangepedia.com/2007/09/exchange-server-2007-setting-message-size-limits.html |date=2013-02-12 }}.</ref><ref>[https://www.geek.com/articles/news/google-updates-file-size-limits-for-gmail-and-youtube-20090629 ''"Google updates file size limits for Gmail and YouTube"'', geek.com] {{webarchive|url=https://web.archive.org/web/20111219141547/https://www.geek.com/articles/news/google-updates-file-size-limits-for-gmail-and-youtube-20090629 |date=2011-12-19 }}.</ref><ref>[https://mail.google.com/support/bin/answer.py?answer=8770&topic=1517 ''"Maximum attachment size"'', mail.google.com].</ref> इसके अलावा, तकनीकी कारणों से, इन परिवहन प्रणालियों द्वारा देखे गए अनुलग्नक आकार उपयोगकर्ता द्वारा देखे जाने वाले आकार से भिन्न हो सकते हैं,<ref>{{cite magazine |last=Walther |first=Henrik |date=January 2009 |url=https://docs.microsoft.com/en-us/previous-versions/technet-magazine/dd314394(v=msdn.10) |title=रहस्यमय अटैचमेंट का आकार बढ़ता है, सार्वजनिक फ़ोल्डरों की प्रतिकृति, और बहुत कुछ|department=[https://docs.microsoft.com/en-us/previous-versions/technet-magazine/cc135877(v=msdn.10) Exchange Queue & A] |magazine=[[TechNet Magazine]] |via=[[Microsoft Docs]] |access-date=2021-11-07}}</ref> जो प्रेषकों के लिए भ्रमित करने वाला हो सकता है जब यह आकलन करने का प्रयास किया जाता है कि क्या वे सुरक्षित रूप से ईमेल द्वारा फ़ाइल भेज सकते हैं। जहाँ बड़ी फ़ाइलों को साझा करने की आवश्यकता होती है, वहाँ विभिन्न [[ फ़ाइल होस्टिंग सेवा ]]एँ उपलब्ध हैं और सामान्यतः  पर उपयोग की जाती हैं।<ref>[https://support.office.com/en-us/article/Send-large-files-to-other-people-7005da19-607a-47d5-b2c5-8f3982c6cc83 "Send large files to other people"] {{webarchive|url=https://web.archive.org/web/20160807110751/https://support.office.com/en-us/article/Send-large-files-to-other-people-7005da19-607a-47d5-b2c5-8f3982c6cc83 |date=2016-08-07 }}, Microsoft.com</ref><ref>[https://www.makeuseof.com/tag/8-ways-to-email-large-attachments/ "8 ways to email large attachments"] {{webarchive|url=https://web.archive.org/web/20160702171053/https://www.makeuseof.com/tag/8-ways-to-email-large-attachments/ |date=2016-07-02 }}, Chris Hoffman, December 21, 2012, makeuseof.com</ref>

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

ऐसे क्रिप्टोग्राफी अनुप्रयोग हैं जो उपरोक्त में से एक या अधिक के लिए एक उपाय के रूप में काम कर सकते हैं। उदाहरण के लिए, वर्चुअल प्राइवेट नेटवर्क या टोर नेटवर्कका उपयोग उपयोगकर्ता मशीन से ट्रैफ़िक को सुरक्षित नेटवर्क पर एन्क्रिप्ट करने के लिए किया जा सकता है जबकि जबकि GPG, PGP, SMEmail,<ref>[https://www.arxiv.org/pdf/1002.3176 SMEmail – A New Protocol for the Secure E-mail in Mobile Environments], Proceedings of the Australian Telecommunications Networks and Applications Conference (ATNAC'08), pp. 39–44, Adelaide, Australia, Dec. 2008.</ref> या S/MIME का उपयोग [[ एंड-टू-एंड सिद्धांत |एंड-टू-एंड सिद्धांत]] के लिए किया जा सकता है। और SMTP STARTTLS या SMTP ओवर ट्रांसपोर्ट लेयर सिक्योरिटी/सिक्योर सॉकेट्स लेयर का उपयो�