इस पर एक अच्छा विकिपीडिया लेख है।
एनसीपी के रूप में एआरपीएनेट द्वारा उपयोग किए जाने वाले शुरुआती पुनरावृत्तियां बाइट धाराओं की तुलना में बिट धाराओं की तरह थीं, या एक सुविधाजनक बाइट आकार के साथ बातचीत करने का प्रयास करती थीं; 8-बिट बाइट केवल बहुत बाद में मानकीकृत किया गया था। फ़ाइल ट्रांसफर प्रोटोकॉल बनाने में भी कई प्रयास किए गए थे जो विभिन्न मशीनों में काम करेंगे (मेल शुरू में एफ़टीपी प्रोटोकॉल का एक फ़ंक्शन था, मुख्य रूप से MAILऔरMLFL कमांड के रूप में , फिर एमटीपी , बाद में एसएमटीपी में विभाजित ।)। उन मशीनों में अक्सर अलग-अलग वर्ण एन्कोडिंग होते थे - ASCII बनाम EBCDIC - या यहां तक कि अलग - अलग बाइट आकार , 8-बिट बाइट्स 6-बिट बनाम ...
इसलिए, मेल ट्रांसफर फ़ंक्शन को शुरू में सादे पाठ में अपेक्षाकृत छोटे संदेशों को स्थानांतरित करने के लिए परिभाषित किया गया था; विशेष रूप से, "एनवीटी-एएससीआईआई"। उदाहरण के लिए, RFC 772 कहता है:
मेल रिप्रेजेंटेशन और स्टोरेज
मेल भेजने वाले होस्ट में स्टोरेज डिवाइस से स्टोरेज डिवाइस में ट्रांसफर हो जाता है। यह मेल पर कुछ परिवर्तन करने के लिए आवश्यक हो सकता है क्योंकि दो प्रणालियों में डेटा भंडारण प्रतिनिधित्व अलग हैं। उदाहरण के लिए, NVT-ASCII में विभिन्न प्रणालियों में अलग-अलग डेटा स्टोरेज अभ्यावेदन हैं। पीडीपी -10 के आम तौर पर एनवीटी-एएससीआईआई को पांच 7-बिट एएससीआईआई पात्रों के रूप में संग्रहीत किया जाता है, जो 36-बिट शब्द में बाएं-न्यायसंगत है। 360 के स्टोर NVT-ASCII में एक 32-बिट शब्द में चार 8-बिट EBCDIC कोड के रूप में है। मल्टीिक्स एक 36-बिट शब्द में चार 9-बिट वर्ण के रूप में NVT-ASCII को संग्रहीत करता है।
सादगी के लिए, सभी डेटा को एमटीपी में एनवीटी-एएससीआईआई के रूप में दर्शाया जाना चाहिए। इसका मतलब यह है कि पाठ को प्रसारित करते समय वर्णों को मानक NVT-ASCII प्रतिनिधित्व में परिवर्तित किया जाना चाहिए, भले ही भेजने और प्राप्त करने वाले मेजबान असंतुष्ट हों। प्रेषक अपने आंतरिक चरित्र प्रतिनिधित्व से डेटा को मानक 8-बिट NVT-ASCII प्रतिनिधित्व में परिवर्तित करता है (TELNET विनिर्देश देखें)। रिसीवर डेटा को मानक रूप से अपने आंतरिक रूप में परिवर्तित करता है। इस मानक के अनुसार, पाठ की एक पंक्ति के अंत को दर्शाने के लिए अनुक्रम का उपयोग किया जाना चाहिए।
भले ही आठ बिट्स को तार के माध्यम से प्रेषित किया जा रहा था, 8 वीं बिट अक्सर खारिज हो जाएगी या खराब हो जाएगी, क्योंकि इसे संरक्षित करने की कोई आवश्यकता नहीं थी; वास्तव में, कुछ प्रोटोकॉल को शून्य पर सेट होने के लिए 8 बिट की आवश्यकता होती है, जैसे कि प्रारंभिक एसएमटीपी आरएफसी नीचे उद्धृत। दूसरे शब्दों में, सॉफ्टवेयर 8-बिट साफ नहीं था ।
डेटा स्थानांतरण
टीसीपी कनेक्शन 8-बिट बाइट्स के प्रसारण का समर्थन करता है। SMTP डेटा 7-बिट ASCII वर्ण है। प्रत्येक वर्ण को 8-बिट बाइट के रूप में प्रसारित किया जाता है, जिसमें उच्च-क्रम बिट शून्य को साफ किया जाता है।
8-बिट ISO-8859 के बाद भी यह लंबे समय तक बरकरार रहा- # वर्ण एन्कोडिंग व्यापक हो गया। हालांकि कुछ सर्वर पहले से ही 8-बिट साफ थे, कई अन्य नहीं थे, और नेत्रहीन रूप से 8 बिट डेटा भेजने के परिणामस्वरूप मैसेज किए गए संदेश होंगे।
बाद में, "विस्तारित एसएमटीपी" प्रकाशित किया गया था, जिससे मेल सर्वरों को एसएमटीपी एक्सटेंशन की घोषणा करने में मदद मिली; उनमें से एक था 8BITMIME, यह दर्शाता है कि प्राप्त सर्वर 8-बिट डेटा को सुरक्षित रूप से स्वीकार कर सकता है। MIME संदेश भागों में " सामग्री-स्थानांतरण-एन्कोडिंग : 8 बिट" हो सकता है, यह दर्शाता है कि वे किसी भी तरह से एन्कोडेड नहीं हैं।
हालांकि, एसएमटीपी प्रोटोकॉल लाइन-आधारित रहा और इसमें 998 ऑक्टेट लाइन की सीमा है, साथ ही साथ ."संदेश के अंत" संकेतक के रूप में एक लाइन (0D 0A 2E 0D 0A) का उपयोग किया गया है। इसका मतलब यह है कि भले ही अधिकांश बाइनरी फ़ाइलों को अनलॉक्ड भेजा जा सकता है, फिर भी यह संभव है कि इस ऑक्टेट अनुक्रम वाली फ़ाइलों को स्थानांतरित संदेश के अंत के रूप में व्याख्या की जाएगी, और शेष फाइल एसएमटीपी कमांड के रूप में संभवतः नुकसान पहुंचाएगी। इसी तरह, एक "लाइन" 998 ओकटेट्स को प्राप्त करने वाले सर्वर द्वारा काट दिया जा सकता है।
2000 में, "BINARYMIME" ESMTP एक्सटेंशन को RFC 3030 के रूप में प्रकाशित किया गया था , जिससे SMTP पर कच्चे बाइनरी डेटा के हस्तांतरण की अनुमति मिली । यह संदेश अब पूर्व-इंगित लंबाई के टुकड़ों में स्थानांतरित किया गया है, एक शून्य-लंबाई वाले चंक को टर्मिनेटर के रूप में उपयोग किया जाता है, और बेस 64 और इसी तरह के एन्कोडिंग की अब आवश्यकता नहीं है। दुर्भाग्य से, कुछ एसएमटीपी सर्वर इस एक्सटेंशन का समर्थन करते हैं; उदाहरण के लिए, CHUNKINGEHLO के जवाब में न तो पोस्टफिक्स और न ही Exim4 विज्ञापन । BINARYMIME का लाभ उठाने के लिए, उसे संदेश पथ के सभी सर्वरों का समर्थन करना होगा , जो केवल एक या दो से अधिक हो सकता है।
यह भी देखें: