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

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 ...

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.

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.

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 ...)

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.

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).

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.

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 '