Moi aussi je peux faire de la merde avec les mails 😑

Après « Le pouvoir de nuisance des silos de mail » (égale­ment paru sur le Frama­blog sous le titre « Être un géant du mail, c’est faire la loi… »), après « Four­nis­seurs d’emails, arrê­tez de faire de la merde ! (#PasMonCaca) » et « I don’t want any spam ! », voici la suite de mes aven­tures avec les spams et les géants du mail.


Atten­tion ! Cet article est erroné ! Tout est de ma faute ! Franck m’a fait remarquer à juste titre que j’avais des erreurs dans mon enre­gis­tre­ment SPF (des adresses IPv6 en /18 à la place de /128). C’était clai­re­ment ça qui a fait que Google a accepté du spam.

Je laisse tout de même l’ar­ticle, par honnê­teté.

Son titre était « Être un géant du mail, c’est faire de la merde avec les spams »


Coucou, vous envoyez du spam

Nous avons reçu récem­ment chez Frama­soft un mail de notre regis­traire de nom de domaine Gandi disant qu’on avait envoyé du spam depuis le domaine frama­listes.org.

Jusque-là, rien de bien étrange, il arrive fréquem­ment que des spam­meurs ciblent des listes de diffu­sions héber­gées chez nous et notre anti­spam n’est pas infaillible (aucun ne l’est).

J’in­ves­tigue donc et me rends sur la page des archives de la liste.
Pas d’ar­chives. Ok, ce n’est pas aber­rant, on a bien le droit de les désac­ti­ver.

Je regarde donc la liste des abon­nées.
Ah, étrange : c’est une liste à nous, l’as­so­cia­tion Frama­soft.
Et pas juste à nous : réser­vée (pour éviter que des gens se fassent passer pour nous avec une adresse qui pour­rait sembler offi­cielle), avec juste 4 membres de l’équipe tech­nique en abon­nés.

Si c’est flou, c’est qu’il y a un loup

Là, je commence à être suspi­cieux.
Je recherche l’adresse mail de la personne qui a reçu le spam dans les fichiers jour­naux des serveurs de mails (nous avons plusieurs serveurs qui envoient du mail, pour répar­tir la charge).

Résul­tat : rien, zéro, nada, que tchi, peau de balle.

Read the headers, Luke

Bon, là, il faut plon­ger dans la bouillie d’en-têtes du spam.
Je n’avais pas commencé par là parce que c’est un méli-mélo pas agréable à lire et que c’est encore forte­ment le matin.
Bref, je m’y mets.

Ah : ça ne vient pas de chez nous.
Mais alors, comment ce spam a-t-il bien pu être accepté ?
On a bien un enre­gis­tre­ment SPF pour dire quels sont les serveurs auto­ri­sés à envoyer des mails venant du domaine frama­listes.org, un enre­gis­tre­ment DKIM pour l’em­preinte publique de la clé qui signe les mails et une poli­tique DMARC qui dit que si un mail n’est pas auto­risé via SPF ou que la signa­ture ne corres­pond pas, il faut le reje­ter sans ména­ge­ment.

Bref, on est norma­le­ment en mode « coupez tout ce qui dépasse ».

Le spam a été accepté pour une raison fort étrange : Google dit que le serveur qui l’a envoyé était bien auto­risé dans notre poli­tique SPF.

Received-SPF: pass (google.com: domain of info@framalistes.org designates 2a01:7c8:bb02:XXXX:XXXX:XXXX:XXX:XXXX as permitted sender) client-ip=2a01:7c8:bb02:XXXX:XXXX:XXXX:XXX:XXXX;

Je ne sais pas si c’est Google qui a fait de la merde ou s’il a été victime d’un empoi­son­ne­ment de son cache DNS mais voilà : si l’en­re­gis­tre­ment SPF qui est dans la zone DNS chez Gandi avait été respecté, ça ne serait pas arrivé.

Conclu­sion

J’ai encore perdu du temps à cause d’un géant du mail et la fusion du titre de mes 3 articles précé­dents était trop tentante pour ne pas en faire un nouvel article 😁

Pous­ser ses filtres SIEVE en ligne de commande et sans mot de passe (avec Kwal­let)

Les filtres Sieve sont des régles de filtrage de mails exécu­tées par le serveur de messa­ge­rie (NB : tous ne le proposent pas). C’est à mon sens l’op­tion la plus propre pour filtrer ses mails : quelque soit mon logi­ciel de consul­ta­tion de mes mails (webmail, client graphique ou textuel sur ordi­na­teur, client sur smart­phone…), le filtrage sera toujours le même, sans avoir besoin de reco­pier les règles.

Pour éditer ces règles, il y a plusieurs solu­tions. La solu­tion de group­ware Blue­mind, que j’uti­lise à titre person­nel et profes­sion­nel four­nit un éditeur graphique sur le webmail, mais il est trop limité pour mon usage : je ne peux que cumu­ler des règles et non pas les mixer, créer des sous règles, etc. Un exemple de sous-règle : si je souhaite que les mails prove­nant de l’adresse foo@example.org soit rangés dans un dossier foo, et que si, parmi ces mails, le sujet contient bar, le mail soit marqué comme lu, je peux écrire en Sieve :

if allof ( address :contains "from" ["foo@example.org"] ) {
    if allof ( header :contains "Subject" "bar" ) {
        setflag "\\Seen";
    }
    fileinto "foo";
    stop;
}

Mais Blue­mind ne permet pas cela, les règles seront plus basiques (ah, les limi­ta­tions des inter­faces graphiques !). Thun­der­bird peut utili­ser une exten­sion, Sieve pour gérer les filtres Sieve, mais je ne sais plus trop ce que ça vaut, ça fait long­temps que je n’uti­lise plus Thun­der­bird. Kmail, le client de messa­ge­rie de KDE et que j’uti­lise, permet de gérer (nati­ve­ment) les filtres Sieve de façon graphique mais pous­sée ou… de les écrire direc­te­ment. Voilà qui est top ! Ah mais… c’est pas ouvert dans Vim. Dommage, j’ai mes petites habi­tudes et j’ai horreur d’uti­li­ser un autre éditeur de texte.

La ligne de commande : sieve-connect

Donc, person­nel­le­ment, j’uti­lise Vim pour écrire mes scripts Sieve et sieve-connect pour les envoyer à mon serveur de messa­ge­rie. Exemple :

sieve-connect -s serveur.example.org -p 2000 -u luc@example.org \
 --localsieve /home/luc/filter.siv --upload --remotesieve mes_regles.sieve

Expli­ca­tion des options :

  • -s serveur.example.org : l’adresse du serveur ;
  • -p 2000 : le port utilisé par le serveur pour l’in­ter­face de gestion des filtres Sieve ;
  • -u luc@example.org : mon login ;
  • --localsieve /home/luc/filter.siv : l’adresse du fichier à pous­ser ;
  • --upload : l’ac­tion à entre­prendre, donc l’en­voi au serveur ;
  • --remotesieve mes_regles.sieve : le nom du fichier distant dans lequel je vais pous­ser mes règles. On peut effec­ti­ve­ment avoir plusieurs fichiers de règles, mais un seul sera actif. Pratique pour avoir des règles spéciales pour les vacances : il n’y a qu’à acti­ver le fichier qui les contient et zou 🙂

Là-dessus, sieve-connect va me deman­der mon mot de passe et hop, c’est poussé !

Sieve-connect permet d’en­voyer des règles, de les récu­pé­rer, de lister les fichiers de règles, d’ac­ti­ver l’un ou l’autre. Bien pratique donc !

Et le mot de passe ?

Pour ne pas avoir à donner mon mot de passe à chaque fois sans pour autant le mettre dans un script, je vais profi­ter de KWal­let, le gestion­naire de mot de passe de KDE contient déjà le mot de passe de mon compte mail, puisque j’uti­lise Kmail. Donc autant le lui deman­der !

Je peux deman­der l’ac­cès au porte­feuille de mot de passe via D-Bus :

qdbus org.kde.kwalletd5 /modules/kwalletd5 open kdewallet imap "Sieve push"

La chaîne "Sieve push" est le nom que je déclare pour mon « appli­ca­tion ». Kwal­let me deman­dera si j’au­to­rise l’ap­pli­ca­tion « Sieve push » à accé­der au porte­feuille. Cette commande va me retour­ner un handle que je vais utili­ser dans mes demandes ulté­rieures. En allant voir dans l’ap­pli­ca­tion graphique de gestion Kwal­let, KWal­letMa­na­ger, je vois que le mot de passe de mon compte de messa­ge­rie est akonadi_imap_resource_1rc du dossier imap. Donc pour en deman­der le mot de passe, je fais :

qdbus org.kde.kwalletd5 /modules/kwalletd5 readPassword le_handle_obtenu_avant \
 imap akonadi_imap_resource_1rc "Sieve push"

NB : on notera que je répète le nom de mon appli­ca­tion, "Sieve push", dans la commande. C’est néces­saire.

Plus qu’à donner le mot de passe à sieve-connect. Pour simpli­fier, je combine tout ça dans une fonc­tion que je vais mettre dans mon ~/.zshrc :

sievepush() {
    ID=$(qdbus org.kde.kwalletd5 /modules/kwalletd5 open kdewallet imap "Sieve push")
    echo $(qdbus org.kde.kwalletd5 /modules/kwalletd5 readPassword $ID imap akonadi_imap_resource_1rc "Sieve push") | sieve-connect -s serveur.example.org -p 2000 -u luc@example.org --localsieve /home/luc/filter.siv --upload --remotesieve mes_regles.sieve
}

Et voilà ! Plus qu’à lancer sievepush depuis mon termi­nal et ça enverra mon fichier de filtres à mon serveur de messa­ge­rie. Si mon porte­feuille KWal­let est ouvert, ça partira direct, sinon, ça me deman­dera le mot de passe du porte­feuille.

Crédit : Photo par Tyler Nix sur Unsplash