Service de dépollution d'e-mail (fin des pièces jointes)

Bonjour à tous,

Projet initial

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.

Le projet initial : KAZ/depollueur: Dépollution des courriel par substitution des pièces jointes par un lien temporaire; - depollueur - Gitea: Git with a cup of tea

@Kaz je vous laisse développer si vous voulez…

Exemple d’e-mail dépollué :

Fork

Au retzien.fr nous l’avons mis en place. Le gain de trafic est significatif. Parfois des divisions par 4 (le 4 septembre) : https://retzien.fr/mail-stats/depollueur.php et je suis en cours de déploiement chez retzo.net [1]

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
  • Utiliser file2link plutôt que jirafeau

Mon fork : David / depollueur · GitLab

De cette façon plusieurs modes de fonctionnement possible :

  • Tout avec exception = tout dépolluer, sauf :
    • Si l’adresse de FROM ou de TO est root@* ou www-data@*
    • Si l’utilisateur a mis en BCC l’adresse nepasdeepolluer@mondomaine.com
    • Si l’utilisateur à mis dans le sujet tag « NEPASDEPOLLUER » (qui sera supprimé)
  • Uniquement certains domaines + sur demande = dépolluer uniquement si :
    • Si l’adresse de FROM se termine en @domain1.com ou @domain2.com
    • Sauf si l’adresse de FROM est root@* ou www-data@*
    • Sauf si l’adresse de TO est michel@domain1.com
    • Si l’utilisateur à mis en BCC l’adresse depolluer@mondomaine.com ou depollueur@mondomaine.com
    • Si l’utilisateur à mis dans le sujet tag « NEPASDEPOLLUER » (qui sera supprimé)
  • Plus d’info : David / depollueur · GitLab

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

Les bémoles

A noter pour le moment :

  • 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

5 Likes

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.

1 Like

Tu avais vu juste, merci pour la piste, j’ai pas trouvé de solution parfaite mais j’ai plus de problème avec microsoft :slight_smile: : Format du message modifié (eMailShrinker) - SPAM (#2) · Issues · David / depollueur · GitLab j

qui eut crut qu’il suffisait de faire des mails valides :wink:

Bon par contre ça règle pas le souci de devoir parser/encoder les mails correctement de juste supprimer les accents, même si effectivement ça marche :wink:

1 Like

Pour info j’ai dév une lib Rust qui parse les emails en suivant les RFC ici : https://git.deuxfleurs.fr/Deuxfleurs/eml-codec . L’encoder n’est pas (encore ?) écrit.

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.

1 Like

Merci pour la découverte, on va mettre ça à l’étude dans ma boîte :slight_smile:

1 Like

Hello,

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 :slight_smile:

3 Likes

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 )

David

2 Likes

Je suis complètement d’accord, et en plus cela mélange les protocoles.

1 Like

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.

1 Like

Pour info François (@Kaz) à corrigé le problème MIME : fix no space after token in MIME header · eb5b3b3ec7 - depollueur - Gitea: Git with a cup of tea

Hello,

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 :wink:

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.

Bonne journée :wink:

2 Likes

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.

2 Likes