हम अभी भी इस तरह के छोटे ईमेल अटैचमेंट पर प्रतिबंध क्यों लगाते हैं? [बन्द है]

Question

क्या तकनीकी सीमा हमें रोक रही है, गौरवशाली वर्ष 2011 में, एक दूसरे को 1GB फाइल करने से?

या यह सिर्फ मुख्य ईमेल प्लेटफॉर्म को अपने पैरों को खींच रहा है?

यदि मैं केवल हेडर हड़पने के लिए अपना इनबॉक्स सेट कर सकता हूं, और फिर पूर्ण संलग्नक यदि मैं उन्हें चाहता हूं, तो समस्या क्या है?

मुझे लगता है कि ईमेल अटैचमेंट साइज़ 1992 में अटके हुए हैं ...

Comments

1992 में अटैचमेंट साइज? Puh-leeze। मैं चाहता हूं कि आप 1992 में 50 एमबी की फाइल ट्रांसफर करें , जो किसी भी तरीके से उपलब्ध हो, उसे अकेले ई-मेल से अटैच कर दें (हां, मेरे पास इस चालू महीने से 2011 में कई ऐसे ई-मेल हैं, नहीं, मैं 'मैं इसके बारे में बहुत खुश नहीं हूं)। संकेत: 1992 में पसंदीदा तरीका, टेप की नकल करना और गंतव्य तक ड्राइविंग करना, या शायद एक ऑल-नाइट डायल-अप और uucpसत्र शामिल हो सकता है।

— पिस्कवॉर

@ मूल्य: वैकल्पिक रूप से, बहु-मात्रा-फैले हुए आर्जे अभिलेखागार वाले डिस्क से भरा एक किराने का बैग। किंडा असंबंधित: cs-exhibitions.uni-klu.ac.at/index.php?id=187

— sum1stolemyname

बैंडविड्थ का इससे बहुत कम या कोई लेना-देना नहीं है; अगर आपको किसी और के साथ संवाद करने के लिए 20 मेगाबाइट से बड़ा है, तो ईमेल इसे भेजने का तरीका नहीं है ।

— शादुर

@ बहादुर: यह अवांछित मेल के मामले में होता है - एक ई-मेल में एक लिंक (जिसे प्राप्तकर्ता क्लिक करने या न चुनने का विकल्प देता है) चरम छोर पर हजारों बाइट्स लेता है; एक ई-मेल में संलग्न फ़ाइल, ज्यादातर मामलों में, बिना संकेत के डाउनलोड की जाती है (मुझे इस संबंध में IMAP की क्षमताओं के बारे में पता है, लेकिन अधिकांश उपयोगकर्ताओं के पास "सब कुछ डाउनलोड करने" के लिए यह सेट है, जो कुछ हद तक बैंडविड्थ को प्रभावित करेगा - भी उपयोग किया जाता है मेल के अलावा अन्य उद्देश्यों के लिए: ब्रॉडबैंड से पहले गैर-आईटी उपयोगकर्ताओं की सामान्य शिकायत: "मेरा वेब इतना धीमा क्यों है? हां, मैंने बीसीसी में 100 लोगों के साथ डांसिंग सूअरों के साथ एक 10 एमबी ई-मेल भेजा था, यह कैसे प्रासंगिक है?" ")

— पिस्कवर

@ पिस्कोवो "कभी भी टेप से भरे ट्रक की बैंडविड्थ को कम न समझें"; आज के रूप में हमेशा की तरह सच: आप एक टेप पर> 1TB प्राप्त कर सकते हैं ....

— रिचर्ड

Answer 1

समस्या यह है: ई-मेल (SMTP / POP3 / IMAP / what-have-you) एक प्राचीन, सरल प्रोटोकॉल है जो मूल रूप से एक विश्वसनीय नेटवर्क में सादा संदेश भेजने के लिए है। आज के इंटरनेट पर बड़ी मात्रा में बाइनरी डेटा भेजने या प्राप्त करने के लिए इसका उपयोग करना, एक बोल्ट-ऑन हैक है, जो मूल उपयोग के मामले से पूरी तरह से अलग है, और यह इस भूमिका में बुरी तरह से प्रदर्शन करता है।

जब आप किसी फ़ाइल को ई-मेल से जोड़ते हैं, तो वह बेस 64-एनकोडेड हो जाती है, जिससे उसका आकार 1/3 बढ़ जाता है। इस प्रकार, आपकी 1 जीबी फ़ाइल एक और 300 एमबी बड़ी हो जाती है; इसके अलावा, डाउनलोड प्रोटोकॉल में कोई अंतर्निहित संपीड़न नहीं है, इस प्रकार स्थानांतरण को गति देने का कोई तरीका नहीं है (और कुछ मामलों में (भेजने के लिए SMTP, प्राप्त करने के लिए POP3), यहां तक ​​कि टूटे हुए हस्तांतरण को फिर से शुरू करने का कोई तरीका नहीं है - कनेक्शन 1.2 पर टूट गया GB (क्षमा करें, आपको इसे फिर से प्रसारित करने की आवश्यकता है)। इसके अलावा, SMTP एक स्टोर-एंड-फॉरवर्ड प्रोटोकॉल है। अंदाज़ा लगाओ? हाँ, उस 1.3 जीबी फ़ाइल को कई सर्वरों पर कॉपी करना होगा; मेल सर्वर व्यवस्थापक से क्यू असीम खुशी।

यह 1990 के दशक में एक समस्या थी, जब कोई उपयोगी विकल्प नहीं था (FTP; HTTP / 1.0; Puh-leeze); लेकिन शानदार वर्ष 2011 में, क्लाउड से / से डेटा को डाउनलोड करने के लिए (जैसे ड्रॉपबॉक्स, उबंटू वन, अमेज़ॅन एस 3, सबसे अधिक ज्ञात नाम के लिए) के विभिन्न तरीकों के साथ, ऐसा करने का कोई और उपयोगी तरीका नहीं है। “कोई और सच नहीं है।

यह भी ध्यान दें कि हर कोई इंटरनेट पर 100 Mbit लिंक पर नहीं है - जैसे मोबाइल और स्मार्टफोन; नहीं हर मेल क्लाइंट केवल हेडर को डाउनलोड करने में सक्षम है (उदाहरण के लिए पॉप 3 ज्यादा भी उपयोग में है), और नहीं हर उपयोगकर्ता 20 अपरिहार्य "इस funneh 1 जीबी वीडियो पर नज़र" डाउनलोड करने के लिए तैयार है प्रति सप्ताह ई मेल है कि होगा दिखाई ( लोग बड़ी फ़ाइलों के रूप में भेजेंगे क्योंकि सिस्टम उन्हें जाने देगा; और हाँ, कुछ ऐसा है जैसे कि अधिकांश ISPs के साथ FUP)।

टीएल; डीआर : जबकि तकनीकी रूप से ऐसी चीजें करना संभव होगा जैसे कि 1 जीबी फाइल ई-मेल करना, यह भी एक पेचकश का उपयोग करके नाखून में पाउंड करना तकनीकी रूप से संभव होगा - यह ऐसा करने का एक अच्छा तरीका नहीं है, जैसा कि वहाँ हैं। ऐसे उपकरण जो इस तरह के कार्यों के लिए अधिक उपयुक्त हैं।

Comments

+1 यह एक बहुत अच्छा जवाब है :)

— एंटोनी बेनकेमॉन

100Mb लिंक? जब तक आप एक निगम कर रहे हैं, कोई नहीं ऑस्ट्रेलिया में एक 100Mb लिंक यहाँ है।

— मैथ्यू शार्ले

TLDR संस्करण के लिए +1 :-)

— मोनिका

मेरा ईमेल क्लाइंट आधार में एन्कोडेड 1GB फ़ाइल को पसंद करेगा।

— कैदी

+1 टूटे हुए स्थानांतरण को फिर से शुरू करने का कोई तरीका नहीं।

— mr_eclair 17

Answer 2

वही लेकिन थोड़ा अलग नज़रिए से:

ईमेल इलेक्ट्रॉनिक मेल है। आप मेल को इस प्राचीन कागज़ की चीज़ के रूप में जानते हैं जो एक और छोटे कागज़ के लिफाफे में है। आप इस पर बहुत सारा पाठ लिख सकते हैं लेकिन 5 या 6 पृष्ठों से अधिक नहीं। और ईमेल एक ही है लेकिन इलेक्ट्रॉनिक है। यह पाठ के लिए डिज़ाइन किया गया है (एक टाइपराइटर पर सादे पाठ)। फिर एक MIME एक्सटेंशन था जहां आप इन फैंसी रेड-ब्लिंकिंग HTML मेल को भेज सकते थे।

दुनिया का कोई भी व्यक्ति यह नहीं कहेगा कि "ओह मेल 1322 ईस्वी सन् में हुआ था। मैं एक कागज के लिफाफे में हाथी को क्यों नहीं भेज सकता?" यह कैसा है। इस तरह के सामान के लिए लोगों ने एक पैकेट या परिवहन कंटेनर की तरह कुछ का आविष्कार किया। यह माल और हाथियों को भेजने का तरीका है। और इंटरनेट वालों ने एफ़टीपी (फाइल ट्रांसफर प्रोटोकॉल) का आविष्कार किया, नाम मिला?

वास्तविक दुनिया में एफ़टीपी के कई विकल्प हैं क्योंकि एफ़टीपी एक प्राचीन प्रोटोकॉल भी है जिसमें बड़े नुकसान हैं (ज्यादातर सुरक्षा में और फाइलों को स्थानांतरित करने में नहीं)। लेकिन HTTP एक विकल्प नहीं है क्योंकि इसे मेटा डेटा के साथ केंद्रीकृत दस्तावेज़ भंडारण के लिए विकसित किया गया था। आप फ़ाइलों को डाउनलोड कर सकते हैं और अपलोड कर सकते हैं, इसका एक क्रूर विस्तार है।

तो माल भेजने के लिए एक पत्र का उपयोग करें और सामान भेजने के लिए एक पैकेट; ईमेल भेजने के लिए ईमेल का उपयोग करें और फाइल भेजने के लिए ट्रांसपोर्ट प्रोटोकॉल फाइल करें।

---

संपादित करें:

चित्र में रहने के लिए मुझे जोड़ना होगा: भले ही आप कागज के लिफाफे में हाथियों को स्वीकार करने के लिए अपने स्थानीय डाकघर को मना लें (और अतिरिक्त शुल्क का भुगतान करें) हाथी को वितरित करने में अधिक पार्टियां शामिल हैं। एक डाकिया है, जिसे उसे अगले डाकघर में ले जाना है और शायद उसके पास हाथी को फिट करने के लिए सही बैग नहीं है। लेकिन हो सकता है कि वह अगले डाकघर में उसे पहुंचाना चाहता हो, जो कहता है: "नहीं हम हाथी को स्वीकार नहीं करते हैं ”।

फिर क्या करें? असली दुनिया का अच्छा डाकिया हाथी को पहले डाकघर में ले जाएगा - बाद में वापस भेजने वाले को। (इलेक्ट्रॉनिक दुनिया में यह एक बुरा मेलमैन होगा क्योंकि उसे हाथी को मारना चाहिए था और केवल प्रेषक को मृत्यु का प्रमाण पत्र प्रदान करना चाहिए)।

यहां तक ​​कि अगर आप हाथियों को स्वीकार करने के लिए पोस्ट डिलीवरी की श्रृंखला के सभी लिंक को स्वीकार कर सकते हैं, तो आप प्राप्तकर्ता के साथ सामना कर रहे हैं। वह कह सकता है कि वह हाथी चाहता है लेकिन एक हाथी को फिट करने के लिए लेटरबॉक्स बहुत छोटा है। एक रिटर्न-टू-सेंडर हाथी डिलीवरी के लिए अग्रणी। (अगर हाथी हाथी के लेटरबॉक्स में फिट नहीं होता है तो क्या होगा इसका उल्लेख नहीं ...)

Comments

आओ पर ! जब तक Content-Type: application/x-pachydermहेडर है, HTTP हाथियों को संचारित करने में पूरी तरह से सक्षम है;) अच्छे अंक, हालांकि मेरी पसंद का प्रोटोकॉल होगा rsync- यथोचित रूप से उपलब्ध, संपीड़न, डेल्टा सिंक के लिए अनुमति देता है, निरंतर स्थानांतरण, प्लस SSH के साथ अच्छी तरह से काम करता है (+ के लिए) एन्क्रिप्शन)।

— पिस्कवर

यहां तक ​​कि एक पी 2 पी दृष्टिकोण उचित है। यह दर्शकों पर निर्भर करता है। ईमेल के माध्यम से किसी फ़ाइल को मल्टीकास्टिंग करके हर किसी की खतरे की घंटी बजनी चाहिए। और जैसा कि आपने दूसरे शब्दों में कहा है कि किसी को इस दृष्टिकोण का पालन नहीं करना चाहिए: "यदि आपके पास केवल एक हथौड़ा है तो हर समस्या नाखून की तरह दिखती है"।

— मेल

हम्म, हाँ - कई इरादा प्राप्तकर्ताओं के लिए, जैसे टोरेंट बहुत मायने रखते हैं; लेकिन मेरे अनुभव में, आपको उन उपयोगकर्ताओं के लिए अभी भी एक (एफ़टीपी; एचटीटीपी?) कमबैक की आवश्यकता है, जो इन सभी नए-नए हस्तांतरण वाले प्रोटोकॉल के जानकार नहीं हैं। जैसा कि आपने कहा, दर्शकों पर निर्भर करता है।

— पिस्कवर

Answer 3

एक्सचेंज 2007 के साथ ऐसी स्थिति में होने पर जहां प्रबंधन ने "ईमेल आकार पर कोई सीमा नहीं" के लिए सदस्यता ली:

एक आंतरिक उपयोगकर्ता ने एक संगीत सीडी के .iso के साथ अपने हॉटमेल पते पर एक संदेश भेजा। संदेश को संसाधित करते समय एक ट्रांसपोर्ट सर्वर पर कतारबद्ध, संदेश को जमा करना, दबाव को जलाया। उपयोगकर्ता के दृष्टिकोण ने तब संदेश को अन्य परिवहन सर्वर पर फिर से प्रस्तुत किया, जो कार्य कर रहा था; वापस दबाव, कोई संदेश प्रस्तुत नहीं।

संदेश पर घुट रहे दोनों परिवहन सर्वरों के साथ, सभी आउटबाउंड ईमेल लगभग 90 सेकंड के लिए रुक गए। हॉटमेल ने, बेशक, संदेश को अस्वीकार कर दिया। इसके तुरंत बाद आकार की सीमा थी।

Comments

90 के दशक में कुछ समय बाद मुझे 20MB का ईमेल मिला। ईमेल वास्तव में मेरे मेलबॉक्स में वितरित किया गया था, लेकिन सर्वर ने 4.5.1 आकार की त्रुटि वापस भेजी। जिस बिंदु पर भेजने वाला सर्वर संदेश को नाराज करता है। एक लूप बनाना जो मेरे मेलबॉक्स या हमारे सर्वर तक भरा हुआ था और कतार से मेल को हटाकर व्यवस्थापक द्वारा मैन्युअल रूप से तय किया जाना था।

— eMBee

Answer 4

यहाँ एक और दृश्य है:

चूंकि एक ईमेल रास्ते में कई उदाहरणों में संग्रहीत किया जाता है, इसलिए 1 जीबी फ़ाइल भेजने से कई बार उपयोग होता है।

यह आमतौर पर "भेजे गए आइटम" में आपके क्लाइंट पर एक कॉपी होगा, और यदि IMAP का उपयोग कर रहा है, तो सर्वर पर एक कॉपी आपके खाते में भी दिखाई दे सकती है।

तब प्राप्त अंत एक प्रतिलिपि (सर्वर) रखेगा, साथ ही प्राप्त अंत पर स्थानीय क्लाइंट पर। अगर IMAP का उपयोग कर रहे हैं, तो यह सर्वर पर (एक बार फिर से) डिलीट नहीं होगा।

जो कि एक सिंगल 1 जीबी फाइल के लिए कुल 4 जीबी है। बेशक, आप इसे एक बैकअप मान सकते हैं, लेकिन इसके लिए बेहतर विकल्प भी हैं। सर्वर पर हो सकने वाली सुस्ती का उल्लेख नहीं है क्योंकि उपयोगकर्ता मेलबॉक्स अनिश्चित काल तक बढ़ते हैं।

और मुझे सिर्फ यह एहसास हुआ कि अगर फ़ाइल base64 एन्कोडेड है तो यह और भी बड़ा होगा (लगभग 33% बड़ा मुझे लगता है)।

Answer 5

पिस्कोवर के उत्तर के पूरक के लिए।

हां, "मुख्य ईमेल प्लेटफ़ॉर्म" उनके पैरों को खींच रहे हैं। वे एक प्रोटोकॉल (SMTP) का उपयोग करके ऐसा करते हैं जो आज के मानकों (कई मायनों में) तक नहीं है।

आज की दुनिया में, हम आसानी से SMTP को बदलने के लिए एक प्रोटोकॉल डिज़ाइन कर सकते हैं जो वर्तमान अटैचमेंट समस्या को हल करेगा।

समस्या यह होगी कि दुनिया इसे बंद कर दे।

Comments

वास्तव में। "ईमेल संचार माध्यमों का कॉकरोच है: आप इसे मार नहीं सकते।"

— Piskvor

Answer 6

वर्णित समस्या ज्यादातर डेटा के भंडारण और संचरण के साथ लॉजिस्टिक मुद्दे हैं - आधुनिक क्लाउड एब्स्ट्रेक्शन में, एक फ़ाइल को अब भौतिक होने की आवश्यकता नहीं है - एक फ़ाइल-हैंडल एब्सट्रैक्शन का उपयोग विभिन्न भंडारण विधियों (जैसे स्थानीय डिस्क, ftp) के चारों ओर लपेटने के लिए किया जा सकता है , http, टोरेंट, यूट्यूब, क्लाउड स्टोरेज, डार्कनेट, अटैचमेंट, खच्चर, वितरित fs, अंश, संशोधन) - यह एक नया विचार नहीं है, यह अभी पूरी तरह से यहाँ या एक टुकड़े में अभी तक नहीं है। जब या यदि यह आता है, तो आपका मेल अनुलग्नक केवल एक फ़ाइल पॉइंटर होगा जो सीधे उपयोग किया जा सकता है(उदाहरण के लिए वीडियो प्लेयर्स या जो भी सॉफ्टवेयर हो, न तो .torrent फाइल और न ही लिंक)। सामग्री डाउनलोड या भंडारण की वास्तविक हैंडलिंग पारदर्शी रूप से होती है, सामग्री आंशिक रूप से सहयोगात्मक-परिक्रामी प्रकट में परिभाषित कई स्रोतों से हो सकती है (जैसे .torrent फ़ाइल की तरह, लेकिन सार्वभौमिक रूप से स्वीकार की गई, और पुन: प्रयोज्य उपलब्धता और स्थानीयता बाधाओं के साथ); वास्तविक डाउनलोड और भंडारण / कैशिंग अक्सर आंशिक हो सकते हैं, जिसके आधार पर कौन सा भाग देखा गया था और यदि आपने सामग्री तक पहुंचने की भी जहमत उठाई है - तो आपकी सास का बहुत बड़ा लगाव आपके घर के किसी भी बैंडविड्थ को नहीं खाएगा। यदि आप उसके ईमेल के प्रशंसक नहीं हैं। स्थायित्व या उपलब्धता के लिए, शायद आप '

Comments

जितना मुझे "क्लाउड" शब्दावली से नफरत है, आपका वर्णन आधा सच है; लेकिन अभी भी हस्तांतरण की आवश्यकताएं (बैंडविड्थ) हैं, भले ही यह केवल मध्यवर्ती है, और "स्थानीय" सर्वर पर उपस्थिति की कमी से महत्वपूर्ण देरी को प्रेरित किया जा सकता है। यहां तक ​​कि अगर फ़ाइल प्राप्तकर्ता द्वारा कभी एक्सेस नहीं की जाती है, तो मूल प्रेषक को अभी भी पूरी फ़ाइल को "क्लाउड" में संचारित करना है, "क्लाउड" को पूरी फ़ाइल (शायद अनिश्चित काल तक) पकड़नी है, और यह सब संवाद करने के लिए संरचनाएं होंगी। जगह पर रखना होगा। यदि हम पहिया को फिर से मजबूत कर रहे हैं, तो यह इससे बेहतर हो सकता है।

— क्रिस एस

"एक फ़ाइल को अब भौतिक होने की आवश्यकता नहीं है" - जब मैं अपने डिस्क से छुटकारा पाता हूं, तो पकड़ कर रखें, क्योंकि उन्हें उन आध्यात्मिक फ़ाइलों की अब आवश्यकता नहीं है ;) आपके पास एक अच्छा बिंदु है कि भंडारण और हस्तांतरण को दूर किया जा सकता है; , लेकिन वे केवल अमूर्तता से कहीं छिपे हुए हैं , गए नहीं। आपको फ़ाइल एक्सेस विलंबता को कम करने के लिए वास्तव में वसा पाइप की आवश्यकता होगी - जैसे कि एचडी वीडियो खेलना शुरू करें, मध्य की तलाश करें, अपने अंगूठे को मिनटों तक घुमाएं जबकि अनुरोधित डेटा आपको स्ट्रीम किया गया है (स्थानीय भंडारण के लिए मात्र मिलीसेकंड के विपरीत) । और प्रकाश की एक फुट-प्रति-नैनोसेकंड पेसकी गति भी है।

— पिस्कवॉर

सच है - यह सब बहुत धीमा हो सकता है अगर इलाके या उपलब्धता को परिभाषित या अच्छी तरह से लागू नहीं किया जाता है। लेकिन उपयोगकर्ता उन्हें परिभाषित करने और गति, बैंडविड्थ, उपलब्धता के विभिन्न ट्रेड-ऑफ के लिए कुछ जिम्मेदारी लेता है, इसलिए, पहले से तय की गई नीतियों, फ़िल्टर नियमों, विशेषताओं, टैग, नियमों का उपयोग करते हुए। जब मैं अनुलग्नक के साथ एक ईमेल भेजता हूं, तो मुझे उन्हें 'अपलोड' करने की आवश्यकता नहीं है, क्योंकि डेटा बस रिसीवर को उपलब्ध कराया जाता है, फिर डेटा चलता है या दो डिस्क के व्यवहार के आधार पर डिस्क और / या क्लाउड स्टोरेज के लिए खुद को दोहराता है। 'स्टोरेज मैनेजर' यूजर-कॉन्फिगर किए गए इंट्रेंस रूल्स।

— एलिफ टॉय

"उपयोगकर्ता उन्हें परिभाषित करने और कुछ जिम्मेदारी लेने के लिए जाता है" - आपको एक प्रबंधक होना चाहिए।

— क्रिस एस

प्रबंधक नहीं, लेकिन कुछ और भी बदतर - एक टूटी हुई भविष्यवक्ता

— एलिफ टॉय