Pourquoi avons-nous toujours des restrictions de taille de fichier aussi petites pour les courriers électroniques? [fermé]

Quelle est la limite technique nous empêchant, en la glorieuse année 2011, d’envoyer des fichiers de 1 Go par courrier électronique?

Ou est-ce seulement les principales plates-formes de messagerie qui traînent les pieds?

Si je peux configurer ma boîte de réception pour qu'elle ne saisisse que les en-têtes, puis les pièces jointes complètes si je les souhaite, quel est le problème?

J'ai l'impression que les tailles de pièces jointes sont bloquées en 1992 ...

Le problème est le suivant: le courrier électronique (SMTP / POP3 / IMAP / what-have-you) est un protocole ancien et simple, destiné à l’origine à l’envoi de messages en texte brut dans un réseau sécurisé. Son utilisation pour envoyer ou recevoir de grandes quantités de données binaires sur Internet est un piratage complet, complètement différent du cas d'utilisation d'origine, et ses performances sont plutôt lamentables dans ce rôle.

Lorsque vous joignez un fichier à un courrier électronique, il est encodé en base64, ce qui augmente sa taille de 1/3. Ainsi, votre fichier de 1 Go devient 300 Mo plus volumineux; de plus, il n'y a pas de compression intégrée au protocole de téléchargement, donc aucun moyen d'accélérer le transfert (et dans certains cas (SMTP pour l'envoi, POP3 pour la réception), voire aucun moyen de reprendre un transfert interrompu - la connexion a été interrompue à 1,2 Désolé, vous devez retransmettre le tout à nouveau). De plus, SMTP est un protocole de stockage et de retransmission. Devine quoi? Eh oui, ce fichier de 1,3 Go doit être copié sur plusieurs serveurs; signaler le bonheur sans bornes des administrateurs du serveur de messagerie.

C'était un problème dans les années 90, alors qu'il n'existait aucune alternative utile (FTP? HTTP / 1.0? Puh-leeze); mais dans la glorieuse année 2011, avec différentes manières de monter / télécharger des données de manière transparente vers / depuis le nuage (par exemple, Dropbox, Ubuntu One, Amazon S3, pour nommer la plus connue), l'excuse "qu'il n'y a pas d'autre moyen utile de le faire "n'est plus vrai.

Notez également que tout le monde n’est pas connecté à Internet à 100 Mbits - par exemple, mobile et smartphone; pas tous les client de messagerie est capable de télécharger uniquement les en- têtes (par exemple POP3 est encore utilisé beaucoup), et non chaque utilisateur est prêt à télécharger le « regard sur ce funneh 1 Go vidéo » 20 inévitable e-mails par semaine qui va apparaître ( les gens vont envoyer des fichiers aussi volumineux que le système le leur permet, et oui, il existe quelque chose comme FUP avec la plupart des FAI).

TL; DR : bien qu’il soit techniquement possible de faire des choses telles que l’envoi par courrier électronique d’un fichier de 1 Go, il serait également techniquement possible d’enfoncer un clou avec un tournevis - ce n’est tout simplement pas un bon moyen de le faire, car des outils plus adaptés à ces tâches.

Le même mais d'un point de vue légèrement différent:

Le courrier électronique est un courrier électronique. Vous connaissez le courrier en tant qu'ancien truc en papier dans une autre petite enveloppe en papier. Vous pourriez écrire beaucoup de texte dessus, mais pas plus de 5 ou 6 pages. Et le courrier électronique est le même mais électronique. Il est conçu pour le texte (texte brut comme sur une machine à écrire). Ensuite, il y avait une extension MIME où vous pouvez envoyer ces mails HTML fantaisistes qui clignotent en rouge.

Personne dans le monde ne se plaindrait et ne dirait "Oh, le courrier est bloqué comme il était à 1322. Pourquoi ne puis-je pas envoyer un éléphant dans une enveloppe en papier?" C'est comme ça. Pour ce genre de choses, les gens ont inventé quelque chose comme un paquet ou un conteneur de transport. Voici comment envoyer des marchandises et des éléphants. Et les gars d'Internet ont inventé le FTP (protocole de transfert de fichiers), vous l'avez appelé?

Dans le monde réel, il existe de nombreuses alternatives au FTP car le FTP est aussi un protocole ancien avec de gros inconvénients (principalement en matière de sécurité et non de transfert de fichiers). Mais HTTP n’est pas une alternative car il a été développé pour le stockage centralisé de documents avec métadonnées. Le fait que vous puissiez télécharger et télécharger des fichiers est une extension brutale.

Utilisez donc une lettre pour envoyer du texte et un paquet pour envoyer des marchandises. utiliser la messagerie électronique pour envoyer des informations et des protocoles de transport de fichiers pour envoyer des fichiers.

Pour rester sur la photo, je dois ajouter que même si vous persuadez votre bureau de poste local d'accepter les éléphants dans des enveloppes en papier (et de payer les frais supplémentaires), davantage de parties sont impliquées dans la livraison de l'éléphant. Il y a le facteur qui doit le porter au prochain bureau de poste et probablement il n'a pas le bon sac pour que l'éléphant puisse s'intégrer. Mais peut-être qu'il a et veut le remettre au prochain bureau de poste qui dit à son tour: "Non nous n'acceptons pas les éléphants ".

Que faire alors? Le bon facteur dans le monde réel ramènerait l'éléphant au premier bureau de poste - à l'expéditeur ensuite. (Dans le monde électronique, ce serait un mauvais facteur, car il aurait dû abattre l'éléphant et ne restituer que le certificat de décès à l'expéditeur).

Donc, même si vous pouviez convaincre tous les maillons de la chaîne de post-livraison d'accepter les éléphants, vous êtes confronté au destinataire. Il pourrait dire qu'il veut l'éléphant, mais la boîte aux lettres est trop petite pour qu'un éléphant puisse s'y intégrer. (Sans parler de ce qui se passe si l'éléphant ne rentre pas dans la boîte aux lettres de l'expéditeur ...)

Etre dans une situation avec Exchange 2007 où la direction a souscrit à la philosophie "Aucune limite de taille de courrier électronique":

Un utilisateur interne a envoyé un message à son adresse hotmail avec un .iso d’un CD de musique. Blocage de la file d’attente sur un serveur de transport lors du traitement du message, retour de pression, arrêt de la soumission du message. Les perspectives de l'utilisateur ont ensuite consciencieusement soumis le message à l'autre serveur de transport qui fonctionnait; pression de retour, pas de soumission de message.

Le message étant étouffé par les deux serveurs de transport, tous les courriers électroniques sortants se sont arrêtés pendant environ 90 secondes. Hotmail, bien sûr, a rejeté le message. Il y avait une limite de taille en place très peu de temps après.

Voici une autre vue:

Etant donné qu'un courrier électronique est stocké dans plusieurs instances au cours du processus, l'envoi d'un fichier de 1 Go utiliserait plusieurs fois tout ce chemin.

Ce sera généralement une copie sur votre client dans "Éléments envoyés", et si vous utilisez IMAP, une copie sur le serveur peut également apparaître (sur votre compte).

Ensuite, le destinataire conservera une copie (le serveur), également sur le client local du destinataire. Si vous utilisez IMAP, il ne sera pas supprimé (une fois de plus) sur le serveur.

C'est un total de 4 Go pour un seul fichier de 1 Go. Bien sûr, vous pouvez considérer cela comme une sauvegarde, mais il existe également de meilleures options pour cela. Sans parler de la lenteur qui pourrait se produire sur le serveur car les boîtes aux lettres des utilisateurs grandissent indéfiniment.

Et je viens de me rendre compte que si le fichier est encodé en base64, il sera encore plus gros (environ 33% plus gros, je suppose).

Pour compléter la réponse de Piskvor.

Oui, les "principales plates-formes de courrier électronique" traînent les pieds. Pour ce faire, ils utilisent un protocole (SMTP) qui n’est pas conforme aux normes actuelles (à bien des égards).

Dans le monde actuel, nous pourrions facilement concevoir un protocole pour remplacer SMTP qui résoudrait le problème actuel des pièces jointes.

Le problème serait de faire basculer le monde vers ce monde.

Le problème mentionné concerne principalement des problèmes logistiques liés au stockage et à la transmission de données. Dans l’abstraction dans le cloud moderne, un fichier n’est plus forcément physique, une abstraction de descripteur de fichier peut être utilisée pour englober diverses méthodes de stockage (par exemple, disque local, ftp). , http, torrent, youtube, stockage en nuage, darknet, pièce jointe, mule, fs distribués, extraits, révisions) - ce n’est pas une idée nouvelle, ce n’est tout simplement pas tout à fait ici ou en un seul morceau. quand ou si elle arrive, votre pièce jointe sera tout simplement un pointeur de fichier pouvant être utilisé directement(par exemple pas un fichier .torrent ni un lien) par des lecteurs vidéo ou tout autre logiciel. le traitement réel du téléchargement ou du stockage du contenu se produirait de manière transparente, le contenu peut être partiellement localisé à partir de plusieurs sources définies dans un manifeste révisable en collaboration (par exemple, un fichier .torrent mais universellement accepté, et avec des contraintes de disponibilité et de localité révisables); Le téléchargement et le stockage / la mise en cache réels peuvent souvent être partiels, en fonction de la partie visionnée et du fait que vous ayez même pris la peine d'accéder au contenu - de sorte que l'énorme pièce jointe de votre belle-mère ne consomme pas votre bande passante interne. si vous n'êtes pas fan de ses emails. Pour la permanence ou la disponibilité, peut-être que vous