Subject: Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa
List archive
Renvoi de demande d'authentification aux spammers et conséquences
- From: Brouard Nicolas <address@concealed>
- To: address@concealed
- Subject: Renvoi de demande d'authentification aux spammers et conséquences
- Date: Tue, 20 Jan 2004 14:15:12 +0100
Bonjour à tous,
J'ai beaucoup de mal à traiter les spams, comme vous tous sans doute !
Evidemment nous avons spamassasin et à plusieurs niveaux mais cela ne
suffit pas car je ne sais pas trop comment implémenter une mesure qui ne
soit pas trop pénalisante pour les abonnés ainsi que pour les
modérateurs de listes.
Quand je dis que spamassassin est implémenté à plusieurs niveaux, je
veux dire qu'il l'est (A) au niveau individuel (avec un ~/.promailrc) et
ajoute un entête X-Spam-Flag: YES parmi les entêtes des courriers jugés
comme étant un spam, ainsi que (B) (et depuis peu) au niveau collectif
avec une autre règle et un autre mode de fonctionnement : spamassassin
modifie alors l'objet du message (subject) en y ajoutant le texte :
"[SPAM-SCORE=" si le score dépasse un certain seuil.
Je ne sais pas très bien ou en est la réflexion de l'équipe de
spamassassin sur la préférence accordée à l'une ou l'autre de ces deux
approches (entête ajoutée ou objet modifié) mais la conséquence de
l'approche collective (objet) est que je ne sais pas faire la règle
correspondante à celle de l'entête ajouté qui est décrite ci-après. En
effet, on trouve bien dans la documentation de sympa
à l'URL
http://www.sympa.org/doc/html/node16.html#SECTION001670000000000000000
ou dans la FAQ
www.sympa.org/fom-serve/cache/214.html ou encore dans
http://www.open-organizations.org/view/Socialtools/StandardSympa
une manière de créer un fichier de nom etc/scenari/include.send.header
qui contient
match([header->X-Spam-Flag],/yes/) smtp -> request_auth
avec éventuellement auparavant la ligne
is_subscriber(blacklist,[sender]) smtp,md5,smime -> reject
(1) Je ne l'ai d'ailleurs pas encore essayée car les SPAMS sont
dorénavant filtrés en amont avec une encart ajouté dans l'objet.
Existe-t-il l'équivalent de "header" pour l'objet d'un message dans les
règles de sypa ? Peut-on écrire quelque chose du genre :
match([subject], /^\[SPAM-SCORE=/) smtp -> request_auth
(2) J'utilisais depuis peu une règle moins fine et plus contraignante
qui obligeait tous les non abonnés à une liste à confirmer leur envoi
avant même que leur message soit soumis aux modérateurs. L'expérience
montre que comme les adresses des spammers sont soit usurpées soit
inventées, cette méthode, comme celle préconisée plus haut, crée
néanmoins des dégats colatéraux puisque les propriétaires de la liste
reçoivent systématiquement un message de retour comme quoi l'adresse du
spammer est inconnue. Dans le cas d'une usurpation ce serait encore pire
pour la personne dont l'identité aurait été usurpée par l'envoyeur du
spam mais nous n'avons pas de telles usurpations pour le moment.
La règle que j'employais en test était la suivante :
# cat send.privateoreditorkeyauth
title.us Private, authentication and moderation for non subscribers
title.fr Privée, authentification puis modération pour les non abonnés
is_subscriber([listname],[sender]) smtp,smime,md5 -> do_it
is_editor([listname],[sender]) smtp,smime,md5 -> do_it
true() smtp -> request_auth
true() md5,smime -> editorkey
En effet la très grande majorité de nos listes sont non modérées pour
les inscrits mais modérées pour les personnes extérieures à la liste.
Ainsi dans tous les cas évoqués ici l'ordre "request_auth" a pour
conséquence que les modérateurs ou propriétaires seront contraints de
filtrer les messages d'authentification retournés en erreur après
l'envoi d'un spam. C'est un travail fastidieux même si on peut y arriver
au niveau individuel en créant par exemple un filtre double sur
l'expéditeur "address@concealed" et sur le destinataire
"address@concealed" car il y a toujours un risque de ne plus
voir une adresse erronnée d'une vraie personne.
Ainsi, j'ai deux questions (1) comment faire une règle sur l'objet d'un
message et non un entête (2) Il y a-t-il d'autres solutions et en tout
cas une solution qui puisse filtrer au niveau collectif les messages
retournés en erreur des spammers ?
Tout commentaire est le bienvenu.
Nicolas Brouard
address@concealed
Institut national d'études démographiques
Paris
- Renvoi de demande d'authentification aux spammers et conséquences, Brouard Nicolas, 01/20/2004
Archive powered by MHonArc 2.6.19+.