Le saviez-vous ? kaz.bzh a (génialement) mis en place une « dépollution » de leur e-mail. La chose est « simple » : un « filtre » postfix qui prend les pièces jointes, les déposent dans un service de partage de fichier contre lien temporaire (jirafeau chez kaz) et met un bandeau avec le lien temporaire en signature du message.
Aussi j’ai « forké » le code de François pour ajouter quelques fonctionnalités :
Ré-écriture du filtre postfix en Perl
Pouvoir faire des exceptions, dépolluer tout ou partie du trafic selon des regex…) sur le FROM et/ou le TO
Que l’utilisateur puisse décider de dépolluer ou non (selon le mode de fonctionnement) en ajoutant des TAG dans le sujet ou un e-mail en copie cacher type nepasdepolluer@retzien.fr
Chez retzien.fr (association qui héberge des particuliers/asso) on a fait un sondage auprès des utilisateurs et ils étaient favorables à 92% au déploiement du service (finalement le bureau était plus réticent que les utilisateurs…). Du coup on est en mode « tout sauf » (bon faut dire qu’on les tanne pas mal depuis un moment sur les e-mail (1) (2) (3) )
Chez retzo.net (entreprise qui héberge entreprise privé, public, asso…) là ça va être selon le choix du client (certain souhait ou non) et donc les 2 modes seront possibles (tout sauf ou uniquement sur demande explicite).
Si vous transférer un e-mail contenant une pièce jointe dépollué (donc un lien) la date n’est pas repoussé (#1) (uniquement sur mon fork, sur la version de François (kaz) c’est le cas)
Belle journée à tous,
David
[1] Ce gain s’explique en partie par le fait que notre service de partage de fichier contre lien (file2link) ne stockent pas 2 fois le même fichier, il fait un link
Pour ton souci avec hotmail/live/etc. vérifie que tu ne crée pas des mails MIME invalides, je sais qu’à un moment le script de kaz créait des mails invalides qui rendaient une page blanche dans roundcube chez moi.
Idéalement tu réécrirais ta part text/plain avec une en-tête Content-Type: utf-8 avec éventuellement le Content-Transfer-Encoding qui va bien (quote ou base64).
Autrement, vous pourriez simplement envelopper le message existant dans un multipart/mixed et rajouter votre part (soit un text/plain seul, soit un multipart/alternate avec un text/plain suivi d’un text/html) sans interférer avec les autres parts du message.
Après, faudrait voir le support en pratique (inexistant à mon avis), mais il y a une feature de MIME pour faire exactement ce que vous voulez : message/external-body (cf RFC2017.)
Extraits :
This memo defines a new access-type for message/external-body MIME parts for Uniform Resource Locators (URLs). URLs provide schemes to access external objects via a growing number of protocols, including HTTP, Gopher, and TELNET.
Content-type: message/external-body; access-type=URL;
URL="http://www.foo.com/file"
Content-type: text/html
Content-Transfer-Encoding: binary
THIS IS NOT REALLY THE BODY!
De mémoire Microsoft ne supporte pas message/external-body par exemple.
Dans tous les cas, je rejoins Bowaz : pour modifier un email, il faut le parser en suivant la RFC, car tout est intriqué : on ne peut pas simplement le modifier avec des regex ou équivalent sans tout casser.
juste pour dire que moi je voyais cette solution dans le cadre de listes de discussion, mais après réflexion, si vous l’appliquez dans le cadre de la correspondance privée des gens dont vous hébergez les mails, ça me semble peut-être un peu plus compliqué d’un point de vue éthique, notamment au regard du secret des correspondances.
En effet, tu transforme une donnée privée, le fichier joint, contenant potentiellement des infos assez sensibles, en fichier accessible publiquement, dont il faut seulement connaître l’URL.
Perso en tant qu’utilisateur d’un service de mail, je serai assez refroidi de voir que mes mails privés sont modifiés et les fichiers joints hébergés sur un serveur, en dehors de la boîte mail du destinataire.
Voilà juste ma remarque après un peu de réflexion sur le sujet
On le fait dans les mailings listes & dans le trafic BAL.
Effectivement, ceci étant tu peux aussi :
Ne pas dépolluer ton message s’il contient des infos sensibles (il faut ajouter un TAG dans le message : NEPASDEPOLLUER )
Dépolluer préalablement ton message en utilisant un système de fichier contre lien protéger par un mot de passe
Et c’est là ou la diversité des C.H.A.T.O.N.S. est une force, chacun trouve midi à sa porte. Nous c’est affiché, on fait ça…
Un gros syndicat m’a approché parce que je dépollue automatiquement les e-mails… (idem, ils ont fait de la pédagogie longtemps mais… ça marche pas :-p )
L’échange massif de pièces jointes peut-être aussi le signe du besoin d’une autre solution de travail en groupe et de méthodes de partage d’information: wiki, pad, partage de fichiers, … un groupeware comme on disait dans le temps.
je tombe sur ce thread, j’en profite pour dire pourquoi le dépollueur a été conçu à la base: pour la sobriété numérique (limiter la place disque). Sans paramétrage particulier, toutes les PJ sont supprimées au bout d’un mois. On ne se retrouve plus avec des BAL qui font du stockage de données pendant 20 ans
Concernant la sécu, vous avez raison, la connaissance d’un lien (même tout bizarre) suffit pour accéder à une PJ. Après, pour construire une url qui contient un lien valide, ça doit être un peu long. Toujours concernant la sécu des PJ, je me demande au final si c’est pas pire d’avoir des PJ stockées sur un serveur, on ne sait où, pendant des années, plutôt que d’avoir des PJ qui disparaissent au bout d’un mois.
La sécurité d’un lien contenant des caractères générés aléatoirement est la même que celle d’un mot de passe de compte mail contenant le même nombre de caractères générés aléatoirement également.
Donc à partir du moment que la partie aléatoire du lien est assez longue, la sécurité n’est pas vraiment un problème.
: 