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


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

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

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

मुझे लगता है कि ईमेल संलग्नक आकार 1992 में फंस गए हैं ...


50
2017-08-24 07:30


मूल


1 99 2 में अटैचमेंट आकार फंस गए? Puh-leeze। मैं तुम्हें देखना चाहूँगा स्थानांतरण 1 99 2 में 50 एमबी फाइल, द्वारा कोई भी विधि उपलब्ध है, इसे अकेले ई-मेल से संलग्न करें (हां, मेरे पास 2011 में इस चालू माह से कई ऐसे ई-मेल हैं, नहीं, मैं इसके बारे में बहुत खुश नहीं हूं)। संकेत: 1 99 2 में पसंदीदा विधि में टेप की प्रतिलिपि बनाना और गंतव्य पर ड्राइविंग, या शायद एक रात्रि डायल-अप शामिल हो सकता था और uucp सत्र। - Piskvor
@Piskvor: वैकल्पिक रूप से, मल्टी-वॉल्यूम-स्पैनिंग arj archives युक्त डिस्क से भरा किराने का थैला। किंडा असंबंधित: cs-exhibitions.uni-klu.ac.at/index.php?id=187 - sum1stolemyname
बैंडविड्थ के पास इसके साथ बहुत कम या कुछ नहीं है; अगर आपको किसी और के साथ संवाद करना है तो 20 मेगाबाइट से बड़ा है, ईमेल भेजने का तरीका नहीं है। - Shadur
@ शदूर: यह अवांछित मेल के मामले में होता है - एक ई-मेल में एक लिंक (जो प्राप्तकर्ता चुनता क्लिक करने के लिए या नहीं) चरम अंत में हजारों बाइट लेता है; किसी ई-मेल में एक संलग्न फ़ाइल, ज्यादातर मामलों में, बिना संकेत के डाउनलोड की जाती है (मुझे इस संबंध में आईएमएपी की क्षमताओं के बारे में पता है, लेकिन अधिकांश उपयोगकर्ताओं के पास यह सेट "सबकुछ डाउनलोड करने" के लिए है, जो होगा कुछ हद तक बैंडविड्थ को प्रभावित करता है - मेल के अलावा अन्य उद्देश्यों के लिए भी उपयोग किया जाता है: ब्रॉडबैंड से पहले गैर-आईटी उपयोगकर्ताओं की सामान्य शिकायत: "मेरा वेब इतना धीमा क्यों है? हाँ, मैंने बीसीसी में 100 लोगों के साथ नृत्य सूअरों के साथ 10 एमबी ई-मेल भेजा था , यह कैसे प्रासंगिक है? ") - Piskvor
@Piskvo "टेप से भरे ट्रक के बैंडविड्थ को कभी कम मत समझें"; आज के रूप में आज के रूप में सच है: आप> 1TB पर प्राप्त कर सकते हैं एक फीता.... - Richard


जवाब:


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

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

1 99 0 के दशक में यह कोई समस्या नहीं थी, जब कोई उपयोगी विकल्प नहीं था (एफ़टीपी? HTTP / 1.0? पुह-लीज); लेकिन गौरवशाली वर्ष 2011 में, क्लाउड से डेटा को डाउनलोड / डाउनलोड करने के विभिन्न तरीकों के साथ (जैसे ड्रॉपबॉक्स, उबंटू वन, अमेज़ॅन एस 3, सबसे ज्यादा ज्ञात नाम), इसका बहाना "ऐसा करने का कोई और उपयोगी तरीका नहीं है "अब और सच नहीं है।

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

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


160
2017-08-24 07:48



+1 यह एक बहुत अच्छा जवाब है :) - Antoine Benkemoun
100 एमबी लिंक? जब तक आप एक निगम नहीं हो, कोई नहीं ऑस्ट्रेलिया में यहां 100 एमबी लिंक है। - Matthew Scharley
टीएलडीआर संस्करण के लिए +1 :-) - Doctor Jones
मेरा ईमेल क्लाइंट बेस 64 में एन्कोडेड 1 जीबी फ़ाइल से प्यार करेगा। - Prisoner
टूटी हुई स्थानांतरण को फिर से शुरू करने का कोई तरीका नहीं है। - mr_eclair


वही लेकिन थोड़ा अलग दृश्य से:

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

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

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

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


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

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

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

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


30
2017-08-24 11:04



आइए पर! जब तक वहाँ है Content-Type: application/x-pachyderm हेडर, HTTP हाथियों को प्रेषित करने में पूरी तरह से सक्षम है;) अच्छे अंक, हालांकि पसंद का मेरा प्रोटोकॉल होगा rsync - उचित रूप से अच्छी तरह से उपलब्ध, संपीड़न, डेल्टा syncs, निरंतर स्थानांतरण के लिए अनुमति देता है, प्लस एसएसएच (ऑथ + एन्क्रिप्शन के लिए) के साथ अच्छी तरह से काम करता है। - Piskvor
यहां तक ​​कि एक पी 2 पी दृष्टिकोण भी उचित है। यह दर्शकों पर निर्भर करता है। ईमेल के माध्यम से फ़ाइल को मल्टीकास्टिंग करने से सभी की अलार्म घंटी बजनी चाहिए। और जैसा कि आपने दूसरे शब्दों में कहा था, किसी को इस दृष्टिकोण का पालन नहीं करना चाहिए: "यदि आपके पास केवल हथौड़ा है तो हर समस्या एक नाखून की तरह दिखती है"। - mailq
हम्म, हाँ - एकाधिक इच्छित प्राप्तकर्ताओं के लिए, उदा। टॉरेंट्स बहुत समझ में आता है; लेकिन मेरे अनुभव में, आपको अभी भी उन उपयोगकर्ताओं के लिए एक (एफ़टीपी? HTTP?) फॉलबैक चाहिए जो इन सभी नए ट्रांसफर प्रोटोकॉल की समझदार नहीं हैं। जैसा कि आपने कहा, दर्शकों पर निर्भर करता है। - Piskvor


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

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

संदेश पर चकमा देने वाले दोनों परिवहन सर्वरों के साथ, सभी आउटबाउंड ईमेल लगभग 90 सेकंड तक रुक गए। Hotmail, निश्चित रूप से, संदेश खारिज कर दिया। बहुत जल्द बाद में आकार की सीमा थी।


16
2017-08-24 17:43





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

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

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

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

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

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


5
2017-08-24 13:53





Piskvor के जवाब को पूरक करने के लिए।

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

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

समस्या दुनिया को उस पर स्विच करने के लिए मिल जाएगी।


4
2017-08-24 15:25



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


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


-2
2017-08-24 18:37



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