Re: [fr@sympa] Blocklist

[Frédéric Mathy <adresse@cachée>]

J'ai tenté de faire ce nouveau scenario send.privateorpublickeyandeditorkey.

J'ai ajouté une liste blanche d'adresses pour que les messages d'utilisateurs non abonnés mais connus puissent diffuser en contournant cette double restriction.
Le search(whitelist.txt) provoque par contre une erreur en 6.2.70... Une idée du souci ?

title.gettext Privée, confirmation pour les non abonnés puis modération pour les non abonnés
is_subscriber([listname],[sender]) smtp,dkim,md5,smime    -> do_it
is_editor([listname],[sender])     smtp,dkim,md5,smime    -> do_it
search(whitelist.txt)              smtp,dkim,md5,smime    -> do_it
true()                             smtp,dkim          -> request_auth
true()                             smtp,dkim,md5,smime    -> editorkey

Fred

Le 24/06/2024 à 17:50, Frédéric Mathy a écrit :

Merci de vos retours ! Voici la première synthèse ;)

Piste 1 : imposer à toutes les listes la modération des messages pour les non abonnés
Il faut cacher le scenario  liste ouverte (public) avec un fichier vide /scenari/send.public:ignore  pour éviter toute nouvelle liste ouverte qui prenne le risque de diffuser du spam à tous ses abonnés.
Le scenario send.privateoreditorkey convient bien à ce que je veux.
Il faut rechercher/remplacer dans les fichiers de config des listes celles qui sont en ''send public'' pour les mettre en ''send privateoreditorkey''.

Piste 2 : demander à ce que chaque personne non abonnée à une liste confirme son message et que son message soit ensuite modéré.
Le scenario send.privateoreditorkey limite déjà le SPAM mais encombre le propriétaire de messages à valider.
Le scenario send.privateorpublickey demande la confirmation aux non-abonnés (les robots qui spamment ne feront pas la démarche). C'est bien mais il faudrait ensuite que le propriétaire modère ce message.
Bref, une compilation de ces 2 scenarios send.privateoreditorkey et send.privateorpublickey pour qu'ils fonctionnent par étape, le propriétaire n'ayant à valider que les messages eux-mêmes déjà validés...


Le scenario send.privateoreditorkey :

title.gettext Private, moderated for non subscribers

is_subscriber([listname],[sender]) smtp,dkim,md5,smime    -> do_it
is_editor([listname],[sender])     smtp,dkim,md5,smime    -> do_it
true() 

Le scenario send.privateorpublickey :

title.gettext Private, confirmation for non subscribers
true()                             md5,smime          -> do_it
is_subscriber([listname],[sender]) smtp,dkim          -> do_it
true()                             smtp,dkim          -> request_auth

Du coup un nouveau scenario send.privateorpublickeyandeditorkey ?
->Privée, confirmation pour les non abonnés puis modération pour les non abonnés
title.gettext Private, confirmation for non subscribers and moderated for non subscribers
Euh, tout reste à faire ;)

A voir si ce type de scenario pour filtrer le SPAM et la validation des propriétaires est pertinent ou un peu lourdingue.
Peut-être que la confirmation du message par le scenario send.privateorpublickey est déjà une étape suffisante ?

Fred M

Le 24/06/2024 à 12:23, Frédéric Mathy a écrit :

      Après
        quelques semaines de test, la solution de Dominique fonctionne
        bien. 
        Seul hic, les domaines qui spamment changent sans cesse et
        l'alimentation de fichiers de blacklists est fastidieuse ;( 
        L'auto-apprentissage de rspamd en lui signalant les messages non
        souhaités est lui aussi un peu lourd... 
        Ma piste d'un script pour  mutualiser les blocages des
        différents listes via une compilation des adresses ou domaines
        indésirables (blocklist.txt  de chaque liste) est trop risqué
        car certains propriétaires de liste peuvent avoir le
        blacklistage rapide ;) 
        
        D'autres pistes : 
        - imposer à toutes les listes la modération des messages pour
        les non abonnés" -> à voir si c'est possible. 
        - demander à ce que chaque personne non abonnée à une liste
        confirme son message par un retour de mail de SYMPA. -> à
        voir si ce type de scenario existe et peut être systématisé à
        l'ensemble des listes. 
        - interdite toute liste ouverte (public) -> à voir si c'est
        possible. 
        
        Cdt 
        Fred M 
        
        
        
        Le 07/06/2024 à 07:41, Dominique Fournier CNRS a écrit : 
> Bonjour 
>           
>           Nous avons mis en place des filtres dans rspamd depuis des
>           années : ils bloquent les mails ou les domaines expéditeurs. 
>           Pour cela, créer un fichier /etc/rspamd/local.d/multimap.conf
>           contenant : 
>           FROM_DOMAIN_BLACKLIST { 
>             type = "from"; 
>             filter = "email:domain"; 
>             map = "$CONFDIR/local.d/maps.d/from_domain_blacklist"; 
>             description = "Local from domain blacklist"; 
>             action = ""reject";" 
>             message = "Reject : forbidden domain sender"; 
>           } 
>           FROM_MAIL_BLACKLIST { 
>             type = "from"; 
>             map = "$CONFDIR/local.d/maps.d/from_blacklist"; 
>             symbol = "LOCAL_BL_FROM"; 
>             description = "Local from mail blacklist"; 
>             action = ""reject";" 
>             message = "Reject : forbidden mail sender"; 
>           } 
>           
>           Ensuite, créer les fichiers contenant les blacklists : 
>           /etc/rspamd/local.d/maps.d/from_blacklist 
>           /etc/rspamd/local.d/maps.d/from_domain_blacklist 
>           
>           Enfin redémarrer rspamd. 
>           
>           le format des fichiers de blacklist est : une valeur par
>           ligne. 
>           
>           Il est même possible de centraliser cela sur un serveur http
>           externe si vous avez plusieurs Rspamd, en utilisant dans la
>           configuration : 
>               map = "https://server.tld/rspamd/from_blacklist";
>           
>           Le fichier est alors vérifié/téléchargé toutes les minutes. 
>           
>           Comme les mails sont bloqués (reject) par Rspamd, Sympa ne les
>           voit même pas. 
>           
>           Bonne journée 
>           
>           Bien cordialement, 
>           
>           Dominique 
>           
>           Le 06/06/2024 à 22:28, Frédéric Mathy a écrit : 
> > Bonsoir, 
> >             
> >             Les listes SYMPA sont souvent spammées par des messages qui
> >             ne sont pas identifiés comme SPAM par RSPAMD (merci Soji
> >             pour ton dernier mail !). 
> >             Chaque liste a la possibilité de bloquer les adresses ou
> >             domaines indésirables via un fichier blocklist.txt mais tous
> >             les propriétaires de listes ne font pas forcément cette
> >             démarche. 
> >             
> >             Pour mutualiser ces blocages, j'ai pensé compiler tous les
> >             blocklist.txt dans un seul : \\ 
> >             'find /home/sympa/list_data/ -name 'blocklist.txt' -exec cat
> >             {} + > compiled_blocklist.txt' 
> >             
> >             Puis, filtrer les doublons, bloquer les domaines via la
> >             syntaxe *@spammer-domain.com et placer ce nouveau fichier
> >             commun à toutes les listes dans
> >             /etc/sympa/search_filters/blocklist.txt. 
> >             
> >             Il est fréquent qu'un domaine attaque toutes les listes d'un
> >             serveur, cette solution pourrait peut-être limiter ces
> >             attaques.Se posera ensuite la question de la mise à jour de
> >             cette liste... 
> >             
> >             Est-ce une pratique correcte ou peut-on faire mieux ?
> >             Blocage global via postfix (smtpd_recipient_restrictions =
> >             check_sender_access hash:/etc/postfix/access) ou blacklist
> >             par RSPAMD... 
> >             
> >             Merci 
> >             
> >             Fred M 
> >             
> >             
> >           
>           
>