Vraag Waarom hebben we nog steeds zulke kleine beperkingen voor het beperken van e-mailbijlagen? [Gesloten]


Wat is de technische beperking die ons verhindert om in het glorieuze jaar 2011 elkaars 1 GB-bestanden te e-mailen?

Of slepen alleen de belangrijkste e-mailplatforms hun voeten?

Als ik mijn inbox kan instellen om alleen headers te pakken en vervolgens volledige bijlagen als ik ze wil hebben, wat is dan het probleem?

Ik heb het gevoel dat de omvang van e-mailbijlagen in 1992 vastzit ...


50
2017-08-24 07:30


oorsprong


Bevestigingsmaten vast in 1992? Puh-Leeze. Ik zou je graag willen zien overdracht een bestand van 50 MB in 1992, door ieder beschikbare methode, laat staan ​​koppelen aan een e-mail (ja, ik heb verschillende van dergelijke e-mails van deze huidige maand in 2011, nee, ik ben er niet erg blij mee). Tip: de voorkeursmethode, in 1992, had kunnen bestaan ​​uit het kopiëren naar band en het rijden naar de bestemming, of misschien een dial-up voor de hele nacht en uucp sessie. - Piskvor
@Piskvor: alternatief een boodschappentas vol schijven met arra-archieven die meerdere volumes overspannen. Nogal niet gerelateerd: cs-exhibitions.uni-klu.ac.at/index.php?id=187 - sum1stolemyname
Bandbreedte heeft er weinig of niets mee te maken; als wat je met iemand anders moet communiceren groter is dan 20 megabytes, e-mail is niet de manier om het te verzenden. - Shadur
@Shadur: Het doet, in het geval van ongewenste e-mail - een link in een e-mail (die de ontvanger kiest om te klikken of niet) neemt duizenden bytes aan het uiterste einde; een bijgevoegd bestand in een e-mail wordt in de meeste gevallen gedownload zonder te vragen (ik ben me bewust van de mogelijkheden van IMAP in dit opzicht, maar de meeste gebruikers hebben deze set om alles te downloaden, wat zou iets invloed op de bandbreedte - ook gebruikt voor andere doeleinden dan mail: de gebruikelijke klacht van de niet-IT-gebruikers voor breedband: "Waarom is mijn web zo langzaam? Ja, ik heb een 10 MB e-mail met dansende varkens met 100 mensen verzonden in BCC , hoe is dat relevant? ") - Piskvor
@Piskvo "Onderschat nooit de bandbreedte van een vrachtwagen vol met banden"; zo waar als vandaag: je kunt> 1TB op krijgen een band.... - Richard


antwoorden:


Het probleem is dit: e-mail (SMTP / POP3 / IMAP / what-have-you) is een oud, eenvoudig protocol dat oorspronkelijk was bedoeld voor het verzenden van leesbare berichten in een vertrouwd netwerk. Het gebruiken ervan voor het verzenden of ontvangen van grote hoeveelheden binaire gegevens op het internet van vandaag is een vastgelopen hack, compleet anders dan de originele use-case, en het presteert nogal miserabel in deze rol.

Wanneer u een bestand bijvoegt bij de e-mail, krijgt het een base64-codering, die de grootte met 1/3 vergroot. Uw bestand van 1 GB wordt dus nog eens 300 MB groter; ook is er geen ingebouwde compressie op het downloadprotocol, dus geen manier om de overdracht te versnellen (en in sommige gevallen (SMTP voor verzenden, POP3 voor ontvangen), zelfs geen manier om hervatten een gebroken overdracht - verbinding verbroken bij 1,2 GB? Sorry, je moet het allemaal opnieuw opnieuw verzenden). Bovendien is SMTP een store-and-forward-protocol. Raad eens? Ja, dat bestand van 1,3 GB moet op meerdere servers worden gekopieerd; cue onbegrensd geluk van de e-mailserverbeheerders.

Dit was een probleem in de jaren negentig, toen er geen bruikbaar alternatief was (FTP? HTTP / 1.0? Puh-leeze); maar in het glorieuze jaar 2011, met verschillende manieren om gegevens naadloos naar / van de cloud te downloaden / downloaden (bijv. Dropbox, Ubuntu One, Amazon S3, om de meest bekende te noemen), het excuus van "er is geen andere handige manier om dit te doen "is niet meer waar.

Merk ook op dat niet iedereen op een 100 Mbit link naar internet zit - bijv. mobiel en smartphone; niet elke e-mailclient is in staat alleen de headers te downloaden (bijvoorbeeld POP3 is nog steeds in gebruik), en niet elke gebruiker is bereid om de 20 onvermijdelijke "look to this funne 1 GB video" e-mails per week te downloaden die zullen verschijnen (mensen sturen zo grote bestanden als het systeem ze toestaat; en ja, er is zoiets als FUP bij de meeste ISP's).

TL; DR: hoewel het technisch mogelijk zou zijn om bijvoorbeeld een bestand van 1 GB te e-mailen, zou het ook technisch mogelijk zijn om met een schroevendraaier in een spijker te slaan - het is gewoon geen goede manier om het te doen, want er zijn gereedschappen die meer geschikt voor dergelijke taken.


160
2017-08-24 07:48



+1 Dat is een heel erg goed antwoord :) - Antoine Benkemoun
100 MB koppeling? Tenzij je een bedrijf bent, niemand heeft hier een link van 100Mb in Australië. - Matthew Scharley
+1 voor de TLDR-versie :-) - Doctor Jones
Mijn e-mailclient zou dol zijn op een bestand van 1 GB dat is gecodeerd in base64. - Prisoner
+1 geen manier om een ​​afgebroken overdracht te hervatten. - mr_eclair


Hetzelfde, maar vanuit een iets andere kijk:

E-mail is elektronische post. Je kent mail als dit oude papieren dingetje in een andere kleine papieren envelop. Je zou er veel tekst op kunnen schrijven, maar niet meer dan 5 of 6 pagina's. En e-mail is hetzelfde, maar elektronisch. Het is ontworpen voor tekst (platte tekst zoals op een typemachine). Dan was er een MIME-extensie waar je deze mooie rood knipperende HTML-mails kon sturen.

Niemand in de wereld zou klagen en zeggen: "Oh mail zit vast zoals het was in 1322. Waarom kan ik geen olifant in een papieren envelop sturen?" Het is hoe het is. Voor dit soort dingen bedachten mensen zoiets als een pakket of een transportcontainer. Dit is hoe je goederen en olifanten verzendt. En het internet jongens uitgevonden FTP (bestandsoverdracht protocol), kreeg de naam?

In de echte wereld zijn er veel alternatieven voor FTP omdat FTP ook een oud protocol is met grote nadelen (meestal in veiligheid en niet in het overbrengen van bestanden). Maar HTTP is niet een alternatief zoals het is ontwikkeld voor gecentraliseerde opslag van documenten met metadata. Dat je bestanden kunt downloaden en uploaden, is een brute uitbreiding ervan.

Gebruik dus een brief om tekst en een pakket te verzenden om goederen te verzenden; gebruik e-mail om informatie en bestandstransportprotocollen te verzenden om bestanden te verzenden.


Bewerk:

Om in beeld te blijven moet ik toevoegen: zelfs als je je lokale postkantoor ervan overtuigt om olifanten in papieren enveloppen te accepteren (en de extra kosten te betalen) zijn er meer betrokken partijen die de olifant leveren. Er is de postbode die hem naar het volgende postkantoor moet dragen en waarschijnlijk heeft hij niet de juiste tas voor de olifant om in te passen. Maar misschien heeft hij het wel en wil het naar het volgende postkantoor brengen, dat op zijn beurt zegt: "Nee we accepteren geen olifanten ".

Wat te doen dan? De goede postbode in de echte wereld zou de olifant terug naar het eerste postkantoor brengen - daarna terug naar de afzender. (In de elektronische wereld zou dit een zijn slecht postbode omdat hij de olifant had moeten neerschieten en alleen het certificaat van overlijden aan de afzender had moeten teruggeven).

Dus zelfs als je alle links in de keten van postbezorging kunt overtuigen om olifanten te accepteren, sta je voor de ontvanger. Hij zou kunnen zeggen dat hij de olifant wil, maar de brievenbus is te klein voor een olifant om in te passen. Dit leidt tot een aflevering van olifanten die terugkeren naar afzender. (Om nog maar te zwijgen van wat er gebeurt als de olifant niet in de brievenbus van de afzender past ...)


30
2017-08-24 11:04



Komen op! Zolang daar het is Content-Type: application/x-pachyderm header, HTTP is perfect in staat om olifanten over te brengen;) Goede punten, hoewel mijn voorkeursprotocol zou zijn rsync - redelijk goed beschikbaar, maakt compressie mogelijk, delta syncs, voortgezette overdracht, plus werkt goed met SSH (voor auth + encryptie). - Piskvor
Zelfs een P2P-benadering is redelijk. Het hangt van het publiek af. Multicasting van een bestand via e-mail moet ieders alarmbel luiden. En zoals je zei, met andere woorden, je zou deze benadering niet moeten volgen: "Als je maar een hamer hebt, lijkt elk probleem op een spijker". - mailq
Hmm, ja - voor meerdere beoogde ontvangers, bijvoorbeeld torrents zijn logisch; maar in mijn ervaring heb je nog steeds een (FTP? HTTP?) terugval nodig voor die gebruikers die niet op de hoogte zijn van al deze nieuwerwetse overdrachtsprotocollen. Afhankelijk van het publiek, zoals je zei. - Piskvor


In een situatie met Exchange 2007 geweest zijn waar het management zich op de filosofie "geen limiet op e-mailgrootte" heeft geabonneerd:

Een interne gebruiker stuurde een bericht naar zijn hotmail-adres met .iso van een muziek-CD. Heeft de wachtrij op één transportserver geblokkeerd tijdens het verwerken van het bericht, verlichtte tegendruk en stopte het verzenden van berichten. De vooruitzichten van de gebruiker hebben vervolgens het bericht netjes doorgestuurd naar de andere transportserver die functioneerde; tegendruk, geen bericht indienen.

Terwijl beide transportservers verstikken in het bericht, stopte alle uitgaande e-mail gedurende ongeveer 90 seconden. Hotmail heeft het bericht natuurlijk afgewezen. Er was heel snel een limiet ingesteld.


16
2017-08-24 17:43





Hier is een andere weergave:

Omdat een e-mail onderweg in meerdere exemplaren wordt opgeslagen, zou het verzenden van een 1 GB-bestand meerdere keren volledig worden gebruikt.

Het is meestal een kopie op uw client in "Verzonden items" en als u IMAP gebruikt, kan er ook een kopie op de server verschijnen (in uw account).

De ontvangende kant bewaart vervolgens een kopie (de server), evenals de lokale client aan de ontvangende kant. Als u IMAP gebruikt, wordt het niet op de server verwijderd (nogmaals).

Dat is een totaal van 4 GB voor een enkel bestand van 1 GB. Je kunt het natuurlijk als een back-up beschouwen, maar daar zijn ook betere opties voor. Om nog maar te zwijgen van de traagheid die op de server kan optreden, omdat de mailboxen van de gebruikers eindeloos groeien.

En ik realiseerde me net dat als het bestand base64 gecodeerd is, het nog groter zal zijn (ongeveer 33% groter denk ik).


5
2017-08-24 13:53





Om het antwoord van Piskvor aan te vullen.

Ja, de "belangrijkste e-mailplatforms" slepen hun voeten. Ze doen dit door een protocol (SMTP) te gebruiken dat niet voldoet aan de normen van vandaag (op veel manieren).

In de wereld van vandaag zouden we gemakkelijk een protocol kunnen ontwerpen om SMTP te vervangen dat de huidige bijlageproblematiek zou oplossen.

Het probleem zou zijn om de wereld ertoe te brengen erover te schakelen.


4
2017-08-24 15:25



Inderdaad. "E-mail is de kakkerlak van communicatiemiddelen: je kunt het gewoon niet doden." - Piskvor


Het genoemde probleem zijn meestal logistieke problemen met de opslag en overdracht van gegevens - in de moderne cloud abstractie moet een bestand niet langer fysiek zijn - een bestands-handle abstractie kan worden gebruikt om verschillende opslagmethoden te omzeilen (bijv. Lokale schijf, ftp , http, torrent, youtube, cloudopslag, darknet, bijlage, mule, gedistribueerde fs, fragmenten, revisies) - dit is geen nieuw idee, het is gewoon nog niet helemaal hier of in één stuk. wanneer of als het aankomt, zou uw e-mailbijlage eenvoudigweg een bestandsaanwijzer zijn die kan worden gebruikt direct (bijvoorbeeld geen .torrent-bestand of een koppeling) door videospelers of welke software dan ook. de feitelijke afhandeling van inhouddownload of -opslag zou transparant gebeuren, inhoud kan gedeeltelijk gelokaliseerd zijn vanuit meerdere bronnen die zijn gedefinieerd in een gezamenlijk herzienbaar manifest (bijvoorbeeld zoals een .torrent-bestand maar universeel geaccepteerd, en met aanpasbare beschikbaarheid en localiteitsbeperkingen); werkelijke download en opslag / caching kunnen vaak gedeeltelijk zijn, afhankelijk van welk deel werd bekeken en als je zelfs de moeite hebt genomen om toegang te krijgen tot de inhoud - dus de enorme bijlage van je schoonmoeder zou geen van je interne bandbreedte opeten als je geen fan bent van haar e-mails. Voor duurzaamheid of beschikbaarheid heeft u misschien een e-mailclient die het opslagmanifest kan filteren en herzien, wat vervolgens leidt tot verplaatsing van bepaalde ongeopende bijlagen van de bronnen naar uw cloudopslag wanneer de beschikbaarheid ervan afneemt, bijvoorbeeld


-2
2017-08-24 18:37



Hoezeer ik ook een hekel heb aan 'cloud'-terminologie, je beschrijving is voor de helft waar; maar er zijn nog steeds overdrachtsvereisten (bandbreedte), opslag zelfs als het slechts een tussenliggend gegeven is, en significante vertraging kan worden veroorzaakt door het gebrek aan aanwezigheid op een "lokale" server. Zelfs als het bestand nooit wordt geopend door de ontvanger, moet de oorspronkelijke afzender nog steeds het hele bestand "naar de cloud" verzenden, de "cloud" moet het hele bestand bevatten (misschien voor onbepaalde tijd), en de structuren om dit allemaal te communiceren zouden moet op zijn plaats worden gezet. Als we het wiel opnieuw uitvinden, kan het beter dan dit. - Chris S
"een bestand hoeft niet langer fysiek te zijn" - wacht even totdat ik mijn schijven kwijt ben, omdat ze niet langer nodig zijn voor die schijven geestelijk bestanden;) U hebt een goed punt dat de opslag en overdracht kunnen worden weggevaagd, maar ze zijn alleen verborgen ergens door de abstractie, niet verdwenen. Je hebt een werkelijk vette pijp om de latentie van de bestandstoegang te verlichten - b.v. begin met het afspelen van een HD-video, zoek naar het midden, twiddle je duimen voor minuten terwijl de gevraagde gegevens naar je worden gestreamd (in plaats van slechts milliseconden voor lokale opslag). En er is ook de one-foot-per-nanoseconde vervelende lichtsnelheid. - Piskvor
waar - dit zou allemaal behoorlijk traag kunnen worden als de lokaliteit of beschikbaarheid niet goed gedefinieerd of geïmplementeerd is. maar de gebruiker kan deze definiëren en enige verantwoordelijkheid nemen voor verschillende afwegingen van snelheid, bandbreedte, beschikbaarheid, enzovoort, met behulp van voorverpakt beleid, filterregels, attributen, tags, regelafwijkingen. wanneer ik een e-mail met bijlage verzend, hoef ik ze niet te 'uploaden', omdat de gegevens eenvoudig beschikbaar worden gemaakt voor de ontvanger, waarna de gegevens worden verplaatst of zichzelf repliceren naar schijven en / of cloudopslag op basis van gedrag van twee partijen 'gebruikersafhankelijkheidsregels voor opslagmanagers'. - Alife Toy
"de gebruiker moet ze definiëren en een zekere verantwoordelijkheid nemen" - je moet een manager zijn. - Chris S
geen manager, maar iets veel ergers - een kapotte futurist - Alife Toy