Perché abbiamo ancora restrizioni così piccole sulla dimensione dei file degli allegati e-mail? [chiuso]


52

Qual è la limitazione tecnica che ci impedisce, nel glorioso anno 2011, di inviarci via email file da 1 GB?

O sono solo le principali piattaforme di posta elettronica che trascinano i piedi?

Se posso impostare la mia casella di posta in modo che prenda solo le intestazioni e, se le voglio, gli allegati completi, qual è il problema?

Sento che le dimensioni degli allegati di posta elettronica sono bloccate nel 1992 ...


23
Dimensioni dell'attacco bloccate nel 1992? Puh-leeze. Mi piacerebbe vederti trasferire un file da 50 MB nel 1992, con qualsiasi metodo disponibile, figuriamoci allegarlo a un'e-mail (sì, ho diverse e-mail di questo mese corrente nel 2011, no, io non ne sono molto felice). Suggerimento: il metodo preferito, nel 1992, avrebbe potuto includere la copia su nastro e la guida verso la destinazione, o forse un dial-up e una uucpsessione per tutta la notte .
Piskvor,

4
@Piskvor: in alternativa, un sacchetto della spesa pieno di dischi contenenti archivi arj multi-volume. Kinda non correlato: cs-exhibitions.uni-klu.ac.at/index.php?id=187
sum1stolemyname

17
La larghezza di banda ha poco o nulla a che fare con esso; se ciò che devi comunicare con qualcun altro è maggiore di 20 megabyte, l' e-mail non è il modo per inviarlo .
Shadur,

2
@Shadur: In caso di posta indesiderata, un collegamento in un'e-mail (che il destinatario sceglie di fare clic o meno) richiede migliaia di byte all'estremità; un file allegato in un'e-mail viene, nella maggior parte dei casi, scaricato senza richiesta (sono consapevole delle capacità di IMAP a questo proposito, ma la maggior parte degli utenti ha questo set per "scaricare tutto", che influirebbe in qualche modo sulla larghezza di banda - utilizzato anche per altri scopi oltre alla posta: la solita lamentela degli utenti non IT prima della banda larga: "Perché il mio Web è così lento? Sì, ho inviato un'e-mail da 10 MB con maiali danzanti con 100 persone nel CCB, come è rilevante? ")
Piskvor,

4
@Piskvo "Non sottovalutare mai la larghezza di banda di un camion pieno di nastri"; oggi più vero che mai: puoi ottenere> 1 TB su un nastro ....
Richard,

Risposte:


163

Il problema è questo: la posta elettronica (SMTP / POP3 / IMAP / what-have-you) è un protocollo semplice e antico originariamente destinato all'invio di messaggi in chiaro in una rete fidata. Usarlo per inviare o ricevere grandi quantità di dati binari su Internet di oggi è un hack imbullonato, completamente diverso dal caso d'uso originale, e si comporta piuttosto miseramente in questo ruolo.

Quando si allega un file all'e-mail, viene codificato in base64, che ne aumenta le dimensioni di 1/3. Pertanto, il file da 1 GB diventa di altri 300 MB più grandi; inoltre, non esiste una compressione integrata al protocollo di download, quindi nessun modo per accelerare il trasferimento (e in alcuni casi (SMTP per l'invio, POP3 per la ricezione), nemmeno un modo per riprendere un trasferimento interrotto - la connessione si è interrotta a 1.2 GB? Scusa, devi ritrasmetterlo di nuovo). Inoltre, SMTP è un protocollo store-and-forward. Indovina un po? Sì, quel file da 1,3 GB deve essere copiato su più server; cue felicità illimitata dagli amministratori del mail server.

Questo era un problema negli anni '90, quando non c'erano alternative utili (FTP? HTTP / 1.0? Puh-leeze); ma nel glorioso anno 2011, con vari modi di caricare / scaricare i dati senza problemi sul / dal cloud (ad esempio Dropbox, Ubuntu One, Amazon S3, per citare il più noto), la scusa di "non c'è altro modo utile per farlo "non è più vero.

Si noti inoltre che non tutti si trovano su un collegamento a 100 Mbit a Internet, ad esempio mobile e smartphone; non tutti i client di posta elettronica è in grado di scaricare solo le intestazioni (ad esempio POP3 è ancora in uso molto), e non ogni utente è disposto a scaricare la 20 "un'occhiata a questo funneh 1 GB video" inevitabile e-mail a settimana che verrà visualizzata ( le persone invieranno file di grandi dimensioni come il sistema permetterà loro; e sì, c'è qualcosa come FUP con la maggior parte degli ISP).

TL; DR : mentre sarebbe tecnicamente possibile fare cose come inviare via e-mail un file da 1 GB, sarebbe anche tecnicamente possibile martellare un chiodo usando un cacciavite - non è un buon modo per farlo, dato che ci sono strumenti più adatti a tali compiti.


10
+1 Questa è un'ottima risposta :)
Antoine Benkemoun,

1
Link da 100 Mb? A meno che tu non sia una società, nessuno ha un link da 100 Mb qui in Australia.
Matthew Scharley,

15
+1 per la versione TLDR :-)
Ripristina Monica

2
Il mio client di posta elettronica adorerebbe un file da 1 GB codificato in base64.
Prigioniero

3
+1 nessun modo per riprendere un trasferimento interrotto.
mr_eclair,

32

Lo stesso ma da una visione leggermente diversa:

L'email è posta elettronica. Conosci la posta come questo antico oggetto di carta in un'altra piccola busta di carta. Potresti scrivere molto testo su di esso, ma non più di 5 o 6 pagine. E l'email è la stessa ma elettronica. È progettato per il testo (testo normale come su una macchina da scrivere). Poi c'era un'estensione MIME in cui era possibile inviare queste fantastiche mail HTML lampeggianti in rosso.

Nessuno al mondo si sarebbe lamentato e avrebbe detto "Oh, la posta era bloccata com'era nel 1322 d.C. Perché non posso mandare un elefante in una busta di carta?" È così. Per questo tipo di cose le persone hanno inventato qualcosa come un pacchetto o un contenitore di trasporto. Ecco come inviare merci ed elefanti. E i ragazzi di Internet hanno inventato FTP (protocollo di trasferimento file), hai preso il nome?

Nel mondo reale ci sono molte alternative all'FTP perché l'FTP è anche un protocollo antico con grandi svantaggi (principalmente nella sicurezza e non nel trasferimento di file). Ma HTTP non è un'alternativa in quanto è stato sviluppato per l'archiviazione centralizzata di documenti con metadati. Il fatto di poter scaricare e caricare file è un'estensione brutale.

Quindi usa una lettera per inviare testo e un pacchetto per inviare merci; utilizzare la posta elettronica per inviare informazioni e protocolli di trasporto file per inviare file.


Modificare:

Per rimanere nella foto devo aggiungere: anche se convinci il tuo ufficio postale locale ad accettare elefanti in buste di carta (e paghi la tariffa aggiuntiva), ci sono più parti coinvolte nella consegna dell'elefante. C'è il postino che deve portarlo all'ufficio postale successivo e probabilmente non ha la borsa giusta per l'elefante. Ma forse ha e vuole consegnarlo all'ufficio postale successivo che a sua volta dice: "No non accettiamo elefanti ".

Cosa fare allora? Il buon postino nel mondo reale avrebbe riportato l'elefante al primo ufficio postale, dopo di nuovo al mittente. (Nel mondo elettronico questo sarebbe un cattivo postino perché avrebbe dovuto sparare all'elefante e consegnare il certificato di morte al mittente).

Quindi, anche se riuscissi a convincere tutti i collegamenti della catena di consegna postale ad accettare elefanti, ti troverai di fronte al destinatario. Poteva dire di volere l'elefante, ma la cassetta delle lettere è troppo piccola per un elefante. (Per non parlare di cosa succede se l'elefante non si adatta alla cassetta delle lettere del mittente ...)


18
Andiamo su ! Finché c'è l' Content-Type: application/x-pachydermintestazione, HTTP è perfettamente in grado di trasmettere elefanti;) I punti positivi, anche se il mio protocollo di scelta sarebbe rsync- ragionevolmente ben disponibile, consente la compressione, le sincronizzazioni delta, il trasferimento continuo, inoltre funziona bene con SSH (per auth + crittografia).
Piskvor,

1
Anche un approccio P2P è ragionevole. Dipende dal pubblico. Il multicasting di un file tramite e-mail dovrebbe suonare il campanello di allarme di tutti. E come hai detto in altre parole, non si dovrebbe seguire questo approccio: "Se hai solo un martello, allora ogni problema sembra un chiodo".
mailq,

Hmm, sì - per più destinatari previsti, ad esempio i torrent hanno molto senso; ma nella mia esperienza, hai ancora bisogno di un fallback (FTP? HTTP?) per quegli utenti che non sono esperti di tutti questi nuovi protocolli di trasferimento. Dipende dal pubblico, come hai detto.
Piskvor,

17

Essendo stato in una situazione con Exchange 2007 in cui il management ha aderito alla filosofia "nessun limite sulla dimensione della posta elettronica":

Un utente interno ha inviato un messaggio al proprio indirizzo hotmail con un .iso di un CD musicale. Inceppata la coda su un server di trasporto durante l'elaborazione del messaggio, riaccesa la pressione, interruzione dell'invio del messaggio. L'outlook dell'utente ha quindi rispedito doverosamente il messaggio all'altro server di trasporto che stava funzionando; contropressione, nessun invio di messaggi.

Con entrambi i server di trasporto soffocati sul messaggio, tutta la posta in uscita si è fermata per circa 90 secondi. Hotmail, ovviamente, ha rifiutato il messaggio. Un limite di dimensione era in atto molto presto dopo.


negli anni '90 ho ricevuto un'e-mail di 20 MB. l'e-mail è stata effettivamente recapitata nella mia casella di posta, ma il server ha restituito un errore di dimensione 4.5.1. a quel punto il server di invio rinvia il messaggio. creando un ciclo che continuava a ripetersi fino a quando la mia casella di posta o il nostro server era pieno e dovevano essere riparati manualmente dall'amministratore rimuovendo la posta dalla coda.
eMBee,

5

Ecco un'altra vista:

Poiché una e-mail viene archiviata in più istanze lungo il percorso, l'invio di un file da 1 GB consumerebbe più volte.

Di solito sarà una copia sul tuo client in "Articoli inviati" e, se si utilizza IMAP, potrebbe essere visualizzata anche una copia sul server (sul tuo account).

Quindi l'estremità ricevente manterrà una copia (il server), nonché sul client locale sull'estremità ricevente. Se si utilizza IMAP, non verrà eliminato sul server (ancora una volta).

Questo è un totale di 4 GB per un singolo file da 1 GB. Naturalmente, puoi considerarlo un backup, ma ci sono anche opzioni migliori per quello. Per non parlare della lentezza che potrebbe verificarsi sul server perché le cassette postali degli utenti crescono indefinitamente.

E ho appena realizzato che se il file è codificato in base64 sarà ancora più grande (immagino circa il 33% più grande).


4

Per integrare la risposta di Piskvor.

Sì, le "principali piattaforme di posta elettronica" stanno trascinando i piedi. Lo fanno usando un protocollo (SMTP) che non è conforme agli standard odierni (in molti modi).

Nel mondo di oggi, potremmo facilmente progettare un protocollo per sostituire SMTP che risolva l'attuale problema di attaccamento.

Il problema sarebbe indurre il mondo a passare ad esso.



-2

Il problema menzionato sono principalmente problemi logistici con l'archiviazione e la trasmissione dei dati - nella moderna astrazione del cloud, un file non deve più essere fisico - un'astrazione di gestione dei file può essere utilizzata per avvolgere vari metodi di archiviazione (ad esempio disco locale, ftp , http, torrent, youtube, cloud storage, darknet, allegato, mulo, fs distribuito, estratti, revisioni) - questa non è una nuova idea, non è solo completamente qui o in un unico pezzo. quando o se arriva, il tuo allegato di posta sarebbe semplicemente un puntatore a file che può essere utilizzato direttamente(ad es. non un file .torrent né un link) da lettori video o da qualsiasi software. l'effettiva gestione del download o dell'archiviazione del contenuto avverrebbe in modo trasparente, il contenuto potrebbe essere parzialmente localizzato da più fonti definite in manifest collaborativamente revisibili (ad es. come un file .torrent ma universalmente accettato, e con vincoli di disponibilità e località modificabili); il download e l'archiviazione / memorizzazione nella cache possono spesso essere parziali, a seconda di quale parte è stata visualizzata e se ti sei persino preso la briga di accedere al contenuto, quindi l'enorme allegato di tua suocera non consumerebbe la tua larghezza di banda interna se non sei un fan delle sue e-mail. Per permanenza o disponibilità, forse tu '


2
Per quanto io odio la terminologia "cloud", la tua descrizione è per metà vera; ma ci sono ancora requisiti di trasferimento (larghezza di banda), archiviazione anche se è solo intermedia e un ritardo significativo potrebbe essere indotto dalla mancanza di presenza su un server "locale". Anche se il destinatario non accede mai al file, il mittente originale deve comunque trasmettere l'intero file "al cloud", il "cloud" deve contenere l'intero file (forse indefinitamente) e le strutture per comunicare tutto ciò deve essere messo in atto. Se stiamo reinventando la ruota, potrebbe essere fatto meglio di così.
Chris S,

1
"un file non deve più essere fisico" - tieni duro mentre mi libero dai miei dischi, poiché non sono più necessari per quei file spirituali ;) Hai un buon punto che l'archiviazione e il trasferimento possono essere astratti , ma sono semplicemente nascosti da qualche parte dall'astrazione, non spariti. Avresti bisogno di una pipa davvero grassa per alleviare la latenza dell'accesso ai file - ad esempio, avvia la riproduzione di un video HD, cerca a metà, piega i pollici per minuti mentre i dati richiesti vengono trasmessi a te (al contrario di semplici millisecondi per l'archiviazione locale) . E c'è anche la fastidiosa velocità della luce di un piede per nanosecondo.
Piskvor,

vero: tutto ciò potrebbe rallentare se la località o la disponibilità non sono definite o implementate correttamente. ma l'utente può definirli e assumersi la responsabilità di vari compromessi di velocità, larghezza di banda, disponibilità, ecc., utilizzando politiche preconfezionate, regole di filtro, attributi, tag, regole di inferenza. quando invio un'e-mail con allegato, non è necessario "caricarli", poiché i dati vengono semplicemente resi disponibili al destinatario, quindi i dati si spostano o si replicano su dischi e / o archiviazione cloud in base al comportamento di due parti regole di inferenza configurate dall'utente 'gestori archiviazione'.
Alife Toy

"l'utente può definirli e assumersi delle responsabilità" - Devi essere un manager.
Chris S,

non manager ma qualcosa di molto peggio - un futurista distrutto
Alife Toy il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.