Accéder au contenu.
Menu Sympa

fr - Re: [fr@sympa] Blocklist

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: Frédéric Mathy <adresse@cachée>
  • To: Liste Sympa <adresse@cachée>
  • Subject: Re: [fr@sympa] Blocklist
  • Date: Wed, 26 Jun 2024 13:20:47 +0200

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






Archives gérées par MHonArc 2.6.19+.

Haut de le page