Discussion :

[clavier12AZQSWX]

bonjour,

ça fait longtemps que ça me tracace sans réponse.

quand j'envoie par mail un fichier qui fait par exemple 7*712*519 octets soit 7.35 Mo.
Pourquoi fait-il 10Mo dans le mail ? que ce soit dans le webmail orange ou avec outlook c'est pareil, le fichier grossit de presque 25% ! pourquoi ?

y-a-t-il des clients mails qui ne grosissent pas les fichiers envoyés ?

C'est chiant car dès fois les gens qui ont des messageries avec une taille limitée de pièce jointe à 10M ne peuvent pas recevoir un fichier de 8 ou 9Mo !

merci de vos explications

[clavier12AZQSWX]

bun voilà j'ai trouvé ma réponse.

http://ask-leo.com/why_are_emailed_a...inal_file.html


En gros le fichier est encodé en texte, des fois en base 64 des fois pas.
Du coup, suivant le mode, ça prend plus ou moins de place.
En gros (encore) c'est une technologie très vieille pas encore résolu.
Les fichiers PNG sont déjà encodés, donc ça prend encore plus de place car c'est incompressible!

Je sais pas si qq'un de responsable chez googlemail me lira, mais voiçi une methode pour y remédier.

Si j'étais chez google, je stockerais sur un serveur sécurisé chaque pièce jointe envoyée par mes utilisateurs (@gmail).A chaque nouveal upload, je regarde si quelqu'un n'a pas déjà uploadé ce même fichier (en vérifiant une emprunte ou qq chose comme ça, ou vraiment le fichier bit à bit). Si c'est le cas je le ruploade pas, je donne un lien public (donné à l'emmeteur et aux destinataires) de téléchargement https.
Ainsi il y a moins de traffic, les mails circulent plus vite ! les boites mails sont plus petites, moins d'espace de stockage pour les serveurs de messageries..Etc!
Je suis sûr que quelqu'un pondera une étude qui dirat que 80% des pièces jointes échangées par mails sont récurrentes (genre des blagues, ppt, music, images).

quoi? google va garder des fichiers privés de notre vie privée ? pas grâve, tout le monde aura cocher la case d'acceptation des conditions d'utilisations du service googlemail sans les lire.....

quoi ? ça va géner les entreprises qui tiennent à leurs données confidentielle, et bun alors les utilisateurs pro de gmail paieront un prix d'utilisation pour que leurs pièces jointes ne soient aggrégées/indéxées et restent donc dans l'ancien système classique actuel qui bouffe de l'espace pour rien.

quoi ? google tiera des stats des fichiers uploadées et en tirera profits pour dire "en septembre 20% de compte gmail se sont échangés des scans de charly hebdo.pdf". Là encore, pas grave tout le monde aura coché les conditions d'utilisations mises à jour ! Tu profites de gmail gratuitement alors tu la fermes ou tu vas voir ailleurs.


une autre idée?

Inventer un client mail qui remédie à ce problème ?

[Deaf]

Du coup, tu casses la compatibilité avec les autres clients mails et tu obliges à utiliser l'interface de GoogleMail pour lire tes mails.

De plus, ça ne marche que pour les mails depuis GoogleMail vers GoogleMail.

Cela ne me semble pas raisonnable...

[Sunchaser]

pourquoi les fichiers envoyés pèsent plus lourd dans un mail que leur taille d'orgine?

Parcequ'ils ont le coeur lourd de partir ?

Et oui, je sais, encore une réponse inutile ...

[sevyc64]

Michael REMY > C'est bien mal connaitre les fonctionnements des services de messagerie

Ceux-ci obéissent à des normes (entre-autre SMTP et IMAP dans le cadre de webmail) et doivent les respecter pour pouvoir avoir un service de messagerie qui fonctionne à travers le monde.

Ce que tu propose n'est tout simplement pas possible avec la norme SMTP et Google (ou un autre) ne peut tout simplement pas le mettre en place sauf à faire un service exclusif, et centro-centré sur lui-même.

[Bousk]

(en vérifiant une emprunte ou qq chose comme ça, ou vraiment le fichier bit à bit).

Si tu vérifies le fichier bit à bit, il faut bien envoyer les bits à vérifier, à ce moment-là, autant envoyer le fichier

[clavier12AZQSWX]

Michael REMY > C'est bien mal connaitre les fonctionnements des services de messagerie

Ceux-ci obéissent à des normes (entre-autre SMTP et IMAP dans le cadre de webmail) et doivent les respecter pour pouvoir avoir un service de messagerie qui fonctionne à travers le monde.

Ce que tu propose n'est tout simplement pas possible avec la norme SMTP et Google (ou un autre) ne peut tout simplement pas le mettre en place sauf à faire un service exclusif, et centro-centré sur lui-même.

Zimbra et autres messagerie refactoré sous marque blanche utilise déjà le système que je décris mais pas automatiquement : il laisse l'utilisateur lui-même uploader sur le serveur collaboratif public son fichier et le remplace par un lien http dans le mail (ça c'est automatique). Du coup, on peut s'envoyer des pièces jointes très lourdes en un éclair de temps sans les renvoyer. Et enfin, envoyer un fichier de 1Mo à 1000 contacts, ne pèse pas 1Go de boite mail au groupe !
Allez Zimbra ! (non je vais pas de la pub c'est open source)

[math_lab]

Surtout que le système de pièce jointe décrit ressemble un peu au système des blogs/réseaux sociaux (ou on partage des images, actualités et autres). Donc ça existe, mais c'est juste pas adapté pour les emails.

[sevyc64]

Zimbra et autres messagerie refactoré sous marque blanche utilise déjà le système que je décris mais pas automatiquement : il laisse l'utilisateur lui-même uploader sur le serveur collaboratif public son fichier et le remplace par un lien http dans le mail (ça c'est automatique). Du coup, on peut s'envoyer des pièces jointes très lourdes en un éclair de temps sans les renvoyer. Et enfin, envoyer un fichier de 1Mo à 1000 contacts, ne pèse pas 1Go de boite mail au groupe !
Allez Zimbra ! (non je vais pas de la pub c'est open source)

NE pas confondre ce que tu décrit de Zimbra avec un système de messagerie.

D'ailleurs ce n'est pas Zimbra qui le propose, je suppose, mais les fournisseurs de messagerie qui exploitent la plateforme zimbra.

Ce que tu indique n'est plus de la messagerie, c'est un système de messagerie couplé avec un système d’hébergement et de DirectDownload. Ça va bien au delà de la messagerie telle que définie dans les normes et peut ne pas être totalement compatible avec tout le monde.
Ca ne permet pas, notamment la consultation hors ligne de ses messages. (Le webmail non plus, mais la partie portail d'accès du webmail ne fait pas partie du service messagerie en terme de norme)

Et c'est pas nouveau, le spam publicitaire est basé sur ce principe depuis de nombreuses années. Tu reçois un mail avec un lien (ou une image cliquable, ce qui revient au même) qui te redirige vers le site promotionnel.

[thelvin]

C'est pas que l'idée me paraisse mauvaise car en effet, un peu tout ce qui se fait se tourne vers ça, et en effet, ça paraît logique de pas polluer les échanges avec des données redondantes.

Seulement, à mon sens, le mail tel qu'on le connaît est en fin de vie. Plutôt qu'essayer d'effacer encore un seul de ses défauts avec encore des nouveaux protocoles, il me semble plus logique de réfléchir à la suite. Enfin, plus logique, pas forcément, disons plutôt que de toute façon c'est la seule manière de faire qui marche.
Donc voilà, je sais pas à quoi ressemblera le mail 2.0 ni quand on commencera à le voir, mais à mon avis c'est plutôt lui qui s'occupera de ça.

Bon, et au passage, en principe on pourrait parfaitement inclure les fichiers sous forme numérique inchangée. En réalité la plupart des serveurs des pays habitués gèrent ça très bien. Mais comme il existe encore des serveurs dans le monde qui gèrent pas (et il en existera toujours,) eh bien les envoyeurs de mail ne prennent pas le risque. De mon temps il existait des options pour décider si oui ou non on encode, mais je en sais pas si elles existent encore.

[sevyc64]

Donc voilà, je sais pas à quoi ressemblera le mail 2.0 ni quand on commencera à le voir, mais à mon avis c'est plutôt lui qui s'occupera de ça.

Tu veux dire le 3.0, le 2.0, on y est depuis longtemps (depuis que l'on arrive à transmettre du binaire en fait)

Bon, et au passage, en principe on pourrait parfaitement inclure les fichiers sous forme numérique inchangée. En réalité la plupart des serveurs des pays habitués gèrent ça très bien. Mais comme il existe encore des serveurs dans le monde qui gèrent pas (et il en existera toujours,) eh bien les envoyeurs de mail ne prennent pas le risque. De mon temps il existait des options pour décider si oui ou non on encode, mais je en sais pas si elles existent encore.

Dans le pur respect de la norme, initialement l'échange était prévu pour uniquement du texte ascii (7bits). Le besoin de transmettre du binaire a fait apparaitre les types MIME et la nécessité d'encoder les binaires (8 bits) en ASCII avec émergence du codage BASE64.

[clavier12AZQSWX]

personnellement je pense que Open2mail (zimbra) est l'exemple type du mail 2.0 à savoir une messagerie collaborative. En tout cas pour les professionnels.

[Sunchaser]

pourquoi les fichiers envoyés pèsent plus lourd dans un mail que leur taille d'orgine?

Encore un coup du Boson de Higgs ?
(et encore un truc inutile de ma part ...)