[sympa-fr] Re: Re: anti-spoofing mail & bonnes pratiques

[LALOT Dominique <adresse@cachée>]

Un truc simple, c'est de demander une authentification dans le scenario
ex: send.auth
title.fr Si non abonné, demande de confirmation

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

En gros, c'est du semi public. Si abonnés, c'est direct (peu de chance qu'un spammer connaisse les abonnés).
Si non abonnés (beaucoup de gens se trompent sur leur véritable email..), on demande confirmation. Sur le serveur de liste, on ne fait que du grey listing, car le spam se bloque bien plus facilement ainsi. Bien sûr, les listes ne sont pas sur le même serveur smtp que les utilisateurs.

Remarques:
Quelque chose qui fait soucis, c'est la visibilité des listes. Si tu ouvres trop (noconceal) ta liste est référençable avec son email par n'importe quel moteur de recherche.
J'ai du créer un scénario visibility assez ouvert mais pas trop qui s'applique bien sur wwsympa..
title.gettext intranet access pour U2 139.124.x.x

match([remote_addr],/139\.124\.\d+\.\d+$/)       smtp,md5,smime    -> do_it
match([sender],/[conf->host]$/)            smtp,md5,smime    -> do_it
is_subscriber([listname],[sender])         smtp,md5,smime    -> do_it
is_owner([listname],[sender])              smtp,md5,smime    -> do_it
is_editor([listname],[sender])             smtp,md5,smime    -> do_it
is_listmaster([sender])                    smtp,md5,smime    -> do_it


Dans la page help, on a aussi listmaster@robot ce qui me gêne pas mal aussi. Les protections sont plus sur les archives dirait on. Mais peut être y a-t-il des options que je ne connais pas.

adresse@cachée a écrit :

DUVAL Olivier wrote:

Bonjour,

 

            Peut-être hors de propos : pour parer au spoofing (usurpation) d’email, comment procédez-vous au niveau de SYMPA ou du MTA ?

            Pour les newsletters, j’ai mis l’auto-modération par les propriétaires des newsletters, mais en ce qui concerne les listes de diffusion, quelles techniques (simples ?) avez-vous appliquées au niveau de SYMPA (scénarios, … ?), ou au niveau du MTA ?

Bonjour

C'est une question d'importance. Plusieurs précautions sont à mettre en place. Parce que les principaux usurpateur d'email sont les spammeurs, la première est d'avoir un bon moteur anti-spam dans le MTA qui alimente le serveur de listes. Il est d'usage que ces moteurs antispam rejettent un certains nombre de spam et tague avec une entête spécifique  indiquant un score qui caractérise la probabilité que le message soit un spam pour les autres messages.

Les utilisateurs peuvent filtrer les messages selon le score. Sympa peut faire de même et en utilisant une règle systématique pour tout les scénario send on peut soit faire un reject, reject,quiet ou un request_auth selon le score. Ci dessous je donne un exemple qui se base sur le scoring fait par j-chkmail que nous utilisons. On pourra adapter à spamassasin ou a tout autre serveur de filtrage facilement  :

match([header->X-j-chkmail-Score],/j\-chkmail score \: xxxx/) smtp -> request_auth
match([header->X-Spam-Flag],/YES/)   smtp -> request_auth
equal([is_bcc],'1')     smtp -> request_auth

Ces règles figurent dans le fichier include.send.header placé dans el répertoire ~sympa/etc/scenari , elles sont donc incluses automatiquement au début de tout scénario send. (Le test is_bcc est aussi une assez bonne pour l'anti-spam)

Cette configuration présente un inconvéniant : le serveur sympa ainsi configuré fait des réponses automatique à des messages dont le From est usurpé. En conséquence, nous cuorrons le risque d'être blacklisté par certains service style spamhaus. Nous prenons ce risque en connnaissance de cause.

Une autre méthode pour lutter spécifiquement contre le spoofing (et non contre le spam) serait d'utiliser le même méchanisme pour tester la validité SPF et DKIM. cette fois, le test pourrait être fait à l'envers : "si le status DKIM est OK, ne pas demander d'authentification request_auth". Pour le moment, la méthode consiste à installer un milter dans le MTS qui valide les signatures dkim et ajoute une entête spécifique pour ces messages, puis à insérer dans les scénario des règles pour exempter du chamlenge email les messages dont la signature dkim est valide.

Les mêmes stratégies peuvent être appliquées aux autres services de Sympa en particulier l'abonnement.

Serge Aumont

-- 
Dominique LALOT
Ingenieur Systeme et Reseaux
http://annuaire.univmed.fr/showuser.php?uid=lalot