Quelle est la limitation technique qui nous empêche, dans l'année glorieuse 2011, de nous envoyer des fichiers de 1 Go par e-mail ?
Ou est-ce simplement les grandes plateformes de messagerie qui traînent les pieds ?
Si je peux configurer ma boîte de réception pour ne récupérer que les en-têtes, et ensuite les pièces jointes complètes si je le veux, quel est le problème ?
J'ai l'impression que les tailles des pièces jointes par e-mail sont restées bloquées en 1992...
Le problème est le suivant : l'e-mail (SMTP/POP3/IMAP/ou autre) est un ancien protocole simple initialement conçu pour l'envoi de messages en texte clair dans un réseau de confiance. L'utiliser pour envoyer ou recevoir de grandes quantités de données binaires à travers l'Internet d'aujourd'hui est un bidouillage ajouté, totalement différent du cas d'utilisation original, et il performe assez misérablement dans ce rôle.
Lorsque vous attachez un fichier à l'e-mail, il est encodé en base64, ce qui augmente sa taille de 1/3. Ainsi, votre fichier de 1 Go devient 300 Mo plus gros; 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), même pas de moyen de reprendre un transfert interrompu - la connexion s'est interrompue à 1,2 Go? Désolé, vous devez tout retransmettre à nouveau). De plus, SMTP est un protocole store-and-forward. Devinez quoi? Oui, ce fichier de 1,3 Go doit être copié à travers plusieurs serveurs; que les administrateurs de serveurs de messagerie se réjouissent sans fin.
C'était un problème dans les années 1990, lorsqu'il n'y avait pas d'alternative utile (FTP? HTTP/1.0? S'il vous plaît); mais en cette année glorieuse 2011, avec divers moyens de télécharger des données vers/des nuages de manière transparente (par exemple Dropbox, Ubuntu One, Amazon S3, pour ne citer que les plus connus), l'excuse de "il n'y a pas d'autre moyen utile de le faire" n'est plus valable.
Remarquez également que tout le monde n'est pas connecté à Internet via une liaison de 100 Mbit - par exemple en utilisant un mobile ou un smartphone; tous les clients de messagerie ne sont pas capables de télécharger uniquement les en-têtes (par exemple, POP3 est encore largement utilisé), et tous les utilisateurs ne sont pas prêts à télécharger les 20 inévitables e-mails "regardez cette vidéo de 1 Go amusante" qui apparaîtront (les gens enverront des fichiers aussi gros que le système le permettra; et oui, il y a quelque chose comme FUP avec la plupart des FAI).
TL;DR : bien qu'il soit techniquement possible de faire des choses telles qu'envoyer un fichier de 1 Go par e-mail, il serait également techniquement possible de marteler un clou avec un tournevis - ce n'est tout simplement pas une bonne façon de le faire, car il existe des outils plus adaptés à de telles tâches.
La même chose mais d'un point de vue légèrement différent :
Un email est un courrier électronique. Vous connaissez le courrier comme cette antique chose en papier placée dans une petite enveloppe en papier. Vous pourriez écrire beaucoup de texte dessus mais pas plus que 5 ou 6 pages. Et un email est la même chose mais électronique. Il est conçu pour du texte (texte brut comme sur une machine à écrire). Ensuite, il y a eu une extension MIME où vous pouviez envoyer ces emails HTML clignotants rouges et sophistiqués.
Personne dans le monde ne se plaindrait en disant "Oh, le courrier est resté tel qu'il était en 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. C'est ainsi qu'on envoie des marchandises et des éléphants. Et les gars d'Internet ont inventé FTP (protocole de transfert de fichiers), vous avez le nom ?
Dans le monde réel, il existe de nombreuses alternatives à FTP car FTP est aussi un protocole ancien avec de gros inconvénients (surtout en termes 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 des métadonnées. Le fait de pouvoir télécharger et téléverser des fichiers est une extension brutale.
Alors utilisez une lettre pour envoyer du texte et un paquet pour envoyer des marchandises ; utilisez un email pour envoyer des informations et des protocoles de transfert de fichiers pour envoyer des fichiers.
Édition :
Pour rester dans le sujet, je dois ajouter : même si vous parvenez à convaincre votre bureau de poste local d'accepter les éléphants dans des enveloppes en papier (et de payer des frais supplémentaires), il y a plus de parties impliquées dans la livraison de l'éléphant. Il y a le facteur qui doit le porter jusqu'au bureau de poste suivant et probablement il n'a pas le sac adéquat pour que l'éléphant rentre. Mais peut-être qu'il l'a et veut le livrer au prochain bureau de poste qui répondra : "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 -- retour à l'envoyeur ensuite. (Dans le monde électronique, ce serait un mauvais facteur car il aurait dû abattre l'éléphant et ne renvoyer que le certificat de décès à l'expéditeur).
Donc même si vous convainquez tous les maillons de la chaîne de livraison postale d'accepter les éléphants, vous êtes confronté au destinataire. Il pourrait dire qu'il veut l'éléphant mais que la boîte aux lettres est trop petite pour qu'un éléphant rentre. Ce qui entraînerait le retour à l'envoyeur de l'éléphant. (Sans parler de ce qui se passe si l'éléphant ne rentre pas dans la boîte aux lettres de l'expéditeur...)
Ayant été dans une situation avec Exchange 2007 où la direction souscrivait à la philosophie du "pas de limite de taille d'e-mail" :
Un utilisateur interne a envoyé un message à son adresse hotmail avec un fichier .iso d'un CD de musique. Celui-ci a bloqué la file d'attente sur un serveur de transport pendant le traitement du message, déclenchant un retour de pression, arrêtant la soumission de messages. Puis, Outlook de l'utilisateur a soumis de nouveau le message à l'autre serveur de transport qui fonctionnait. Nouveau retour de pression, aucune soumission de message.
Avec les deux serveurs de transport étouffés par le message, tout envoi d'e-mails sortants s'est interrompu pendant environ 90 secondes. Hotmail a bien sûr rejeté le message. Une limite de taille a été mise en place très rapidement après.
Voici un autre point de vue :
Étant donné qu'un email est stocké dans plusieurs instances tout au long du processus, l'envoi d'un fichier de 1 Go utiliserait plusieurs fois cette quantité.
Il sera généralement une copie dans votre client dans les "Éléments envoyés", et si vous utilisez IMAP, une copie sur le serveur pourrait également apparaître (sur votre compte).
Ensuite, le destinataire conservera une copie (sur le serveur), ainsi que dans le client local du destinataire. Si vous utilisez IMAP, alors elle ne sera pas supprimée sur le serveur (encore une fois).
Cela fait un total de 4 Go pour un seul fichier de 1 Go. Bien sûr, vous pouvez le considérer comme une sauvegarde, mais il existe de meilleures options pour cela également. Sans mentionner la lenteur qui pourrait se produire sur le serveur car les boîtes aux lettres des utilisateurs augmentent indéfiniment.
Et je viens de réaliser que si le fichier est encodé en base64, il sera encore plus volumineux (environ 33% de plus je suppose).
Pour compléter la réponse de Piskvor.
Oui, les "principales plateformes de messagerie électronique" traînent les pieds. Ils le font en utilisant un protocole (SMTP) qui n'est pas conforme aux normes actuelles (à bien des égards).
De nos jours, 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 convaincre le monde de passer à ce nouveau protocole.
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
