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


52

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


23
Les tailles d'attachement sont bloquées en 1992? Puh-leeze. J'aimerais que vous transfériez un fichier de 50 Mo en 1992, quelle que soit la méthode disponible, et encore moins de le joindre à un courrier électronique (oui, j'ai plusieurs courriels du même mois en 2011, non, je ne suis pas très heureux à ce sujet). Astuce: la méthode préférée, en 1992, aurait pu inclure la copie sur bande et le trajet à destination, ou peut-être une connexion et une uucpsession toute la nuit .
Piskvor

4
@Piskvor: vous pouvez également utiliser un sac d'épicerie contenant des disques contenant des archives d'arj couvrant plusieurs volumes. Kinda non lié: cs-exhibitions.uni-klu.ac.at/index.php?id=187
sum1stolemyname

17
La bande passante n'a que peu ou rien à voir avec cela; Si ce que vous devez communiquer avec quelqu'un d'autre dépasse 20 mégaoctets, le courrier électronique n'est pas le moyen de l'envoyer .
Shadur

2
@Shadur: En cas de courrier indésirable, un lien dans un courrier électronique (sur lequel le destinataire choisit de cliquer ou non) prend des milliers d'octets à l'extrême; un fichier joint dans un e-mail est, dans la plupart des cas, téléchargé sans invite (je suis conscient des capacités de l'IMAP à cet égard, mais la plupart des utilisateurs l'ont paramétré pour "tout télécharger", ce qui affecterait quelque peu la bande passante - également utilisé autres raisons que le courrier: la plainte habituelle des non-utilisateurs avant le haut débit: "Pourquoi mon site Web est-il si lent? Oui, j’ai envoyé un courrier électronique de 10 Mo avec des cochons dansants avec 100 personnes dans BCC, en quoi cela est-il pertinent?" ")
Piskvor

4
@Piskvo "Ne sous-estimez jamais la bande passante d'un camion rempli de cassettes"; toujours aussi vrai aujourd'hui: vous pouvez obtenir> 1 To sur une bande ....
Richard

Réponses:


163

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.


10
+1 C'est une très très bonne réponse :)
Antoine Benkemoun

1
Lien 100Mo? À moins que vous ne soyez une entreprise, personne n’a un lien de 100 Mo ici en Australie.
Matthew Scharley

15
+1 pour la version TLDR :-)
Réintégrer Monica

2
Mon client de messagerie aimerait un fichier de 1 Go encodé en base64.
Prisonnier

3
+1 aucun moyen de reprendre un transfert interrompu.
mr_eclair

32

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.


Modifier:

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


18
Venez sur ! Tant que l'en- Content-Type: application/x-pachydermtête existe , HTTP est parfaitement capable de transmettre des éléphants;) De bons points, même si mon protocole de choix serait rsync- raisonnablement disponible, permet la compression, la synchronisation delta, le transfert continu, et fonctionne bien avec SSH (pour authentification + chiffrement).
Piskvor

1
Même une approche P2P est raisonnable. Cela dépend du public. La multidiffusion d'un fichier par courrier électronique doit sonner l'alarme de tout le monde. Et comme vous l'avez dit en d'autres termes, il ne faut pas suivre cette approche: "Si vous n'avez qu'un marteau, alors chaque problème ressemble à un clou".
mailq

Hmm, oui - pour plusieurs destinataires, par exemple, les torrents ont beaucoup de sens; mais selon mon expérience, vous avez toujours besoin d'une solution de secours (FTP? HTTP?) pour les utilisateurs qui ne sont pas au courant de tous ces protocoles de transfert novateurs. Cela dépend du public, comme vous l'avez dit.
Piskvor

17

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.


Au cours des années 90, j'ai reçu un courriel de 20 Mo. l'e-mail a bien été livré dans ma boîte aux lettres, mais le serveur a renvoyé une erreur de taille 4.5.1. à quel point le serveur d'envoi a renvoyé le message. créer une boucle qui se répète jusqu'à ce que ma boîte aux lettres ou notre serveur soit plein et que l'administrateur doive le réparer manuellement en supprimant le courrier de la file d'attente.
eMBee

5

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


4

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.



-2

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


2
Bien que je déteste la terminologie «nuage», votre description est à moitié vraie; mais il y a toujours des exigences de transfert (bande passante), de stockage même s'il n'est que intermédiaire, et un retard important pourrait être induit par le manque de présence sur un serveur "local". Même si le fichier n’est jamais accédé par le destinataire, l’expéditeur initial doit toujours transmettre le fichier entier "au cloud", le "nuage" doit contenir le fichier entier (peut-être indéfiniment), et les structures pour communiquer tout cela doivent être mis en place. Si nous réinventons la roue, nous pourrions faire mieux que cela.
Chris S

1
"un fichier dont vous n'avez plus besoin d'être physique" - attendez pendant que je me débarrasse de mes disques, car ils ne sont plus nécessaires pour ces fichiers spirituels ;) Vous avez un bon point: le stockage et le transfert peuvent être résumés , mais ils sont simplement cachés quelque part par l'abstraction, pas partis. Vous aurez besoin d'un très gros tuyau pour réduire la latence d'accès aux fichiers - par exemple, commencer à lire une vidéo HD, chercher au milieu, tourner les pouces pendant quelques minutes pendant que les données demandées vous sont transmises (plutôt que quelques millisecondes pour le stockage local) . Et il y a aussi la vitesse de la lumière ennuyeuse d'un pied par nanoseconde.
Piskvor

vrai - tout cela pourrait devenir assez lent si la localité ou la disponibilité n'est pas définie ou mise en œuvre correctement. mais l'utilisateur peut les définir et assumer une part de responsabilité en ce qui concerne divers compromis de vitesse, de bande passante, de disponibilité, etc., à l'aide de règles prédéfinies, de règles de filtrage, d'attributs, de balises et de règles d'inférence. lorsque j'envoie un e-mail avec pièce jointe, je n'ai pas besoin de les "télécharger", car les données sont simplement mises à la disposition du destinataire, puis les données se déplacent ou se répliquent sur des disques et / ou sur un stockage en nuage en fonction du comportement de deux parties Règles d'inférence configurées par l'utilisateur des «gestionnaires de stockage».
Alife Toy

"l'utilisateur doit les définir et assumer certaines responsabilités" - Vous devez être un gestionnaire.
Chris S

pas un manager mais quelque chose de bien pire - un futuriste brisé
Alife Toy
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.