Archives par étiquette : spam

Et vous, comment vous bloquez le spam « propre » ?

16 réponses

spamContre le spam, j’utilise tout l’arsenal de greylisting, quelques listes RBL, les outils tels spamassassin agrémenté de filtre plus avancés (je regrette feu l’outil SARE qu’il ne faut plus utiliser maintenant).
Côté RBL, je ne trouve pas mon bonheur complet, soit trop violent dans le blocage, soit pas assez.

Bilan, ceux que j’appelle les spammeurs propres continuent de me polluer (pas beaucoup, mais un peu quand même), surtout sur des adresses visibles que j’héberge et qu’on peut retrouver par exemple sur les pages jaunes. C’est bien du spam puisque le destinataire n’a rien demandé.

Ces spammeurs sont « propres » en ce sens où ce sont des sociétés bien définies Continuer la lecture →

spamassassin : rulesemporium est mort

2 réponses

Hop,
Je n’avais pas vu le truc avant qu’une mise à jour spamassassin me remonte une alerte, mais le site RulesEmporium a fermé. Plus d’activité, soit. Mais d’avoir supprimé le contenu, c’est dommage je trouve.
Bon bref, toujours est-il que j’ai de nouveau un petit bout de l’outil de détection des textes « cachés » dans les images (spam viagra & co) qui ne fonctionne plus.
D’ici à trouver quelque chose d’autre, je laisse en plan et je supprime simplement les quelques règles de détection impactées. Continuer la lecture →

Séquence de greylisting

9 réponses

Je suis en train de préparer une doc de mise en place sauce Debian de la fameuse chaîne complète de traitement de mails : postfix + postgrey + amavisd-new + spamassassin + RulesEmporium + clamav. (j’en oublie ? :))
D’ici que la doc soit prête dans sa globalité, j’en profite pour zoomer sur le greylisting (qui en gros, me divise en général par 10 les spams entrants sur un serveur donnée qui ne faisait pas de greylisting). Continuer la lecture →

spamassassin : RulesDuJour vs sa-update

1 réponse

Si vous utilis[i]ez « RulesDuJour » pour mettre à jour les règles spamassassin de « Rules Emporium »…. quoi ? comment ça qu’est-ce que je raconte ? Lisez le chapitre qui va bien dans ma doc !! Vous n’utilisez pas les règles SARE ? mais vous le triez comment votre spam ?! 😉
Bon, je reprends.

Depuis quelques semaines (mois ?), le programme RulesDuJour végétait. Il n’y a eu aucune communication sur le sujet à part 2/3 infos éparses dans des mailing-lists. J’ai pris le temps de chercher et poser les questions.
Maintenant, je peux affirmer que RulesDuJour n’est plus supporté (mais fonctionne encore à peu près) et un type du projet spamassassin a monté un serveur permettant de mettre à jour les règles SARE depuis l’outil normal de mise à jour de spamassassin, à savoir sa-update.

Le principe pour configurer sa-update afin qu’il aille chercher vos règles SARE est le suivant :
1) Vous supprimez votre « RulesDuJour » quotidien de votre crontab.
2) Gardez quelque part la liste des règles que vous utilisez (noms des fichiers).
3) Supprimez les règles type /etc/spamassassin/7*cf et le répertoire où vous stockiez RulesDuJour.
4) Ensuite, créez un fichier /etc/spamassassin/channels.txt contenant :

updates.spamassassin.org
70_sare_adult.cf.sare.sa-update.dostech.net
70_sare_bayes_poison_nxm.cf.sare.sa-update.dostech.net
70_sare_evilnum0.cf.sare.sa-update.dostech.net
70_sare_evilnum1.cf.sare.sa-update.dostech.net
autre.regle.de.SARE.cf.sare.sa-update.dostech.net
...

et vos autres règles type blabla.cf en suffixant par .sare.sa-update.dostech.net. Vous comprenez le principe ? le serveur dostech s’attend à recevoir des demandes « au format sa-update » et grâce à des noms de machines bidons indiquant en fait le nom du fichier correspondant à la règle que vous cherchez, sa-update trouve son bonheur.
Ne pas oublier la 1ère ligne des updates « normaux » de spamassassin.

Ensuite, vous planifiez une fois par jour le job suivant :

sa-update --allowplugins --channelfile /etc/spamassassin/channels.txt --nogpg /usr/local/bin/sa-compile && /etc/init.d/spamassassin reload

Notez qu’il y a déjà dans votre /etc/cron.daily un update spamassassin. Faut-il le modifier ? bof, c’est de la conf standard, c’est un coup à ce que ça saute au prochain update/upgrade.
La deuxième partie de la commande (&& /etc/init.d/spamassassin reload) n’est utile que si votre spamassassin tourne en tant que « daemon ».

Les nouvelles règles téléchargées iront s’installer dans /var/lib/spamassassin/3.002003.

Astuce of ze day pour générer sans peine (et sans faute de frappe) le fichier channels.txt. En considérant que vos règles SARE actuelles sont dans /etc/spamassassin et se nomment toutes 7*cf, tapez donc ça :

cat updates.spamassassin.org > /etc/spamassassin/channels.txt
for i in 7*cf
do
echo $i.sare.sa-update.dostech.net >> /etc/spamassassin/channels.txt
done

Voilà. Forcez le premier lancement à la main et contrôlez le contenu du répertoire /var/lib/spamassassin/3.002003 et la présence du daemon spamassassin (si vous l’utilisez en « daemon »).

La « doc » qui fait foi est ici : http://daryl.dostech.ca/sa-update/sare/sare-sa-update-howto.txt

Statistiques de greylisting

5 réponses

Pour ceux qui ne connaissent pas, le « Greylisting » est un mécanisme utile et extrêmement simple à mettre en oeuvre pour réduire significativement le nombre de spams en entrée des serveurs de mails, sans même avoir besoin de les analyser. En gros, vous pouvez diviser par 10 vos mails entrants et le boulot de votre spamassassin, du coup.
Magique ? non, logique.
Je vous propose dans cet article un résultat chiffré sur une installation comptant un backup MX, un frontal (qui encaisse les tentatives d’abus etc + analyse virus) relayant enfin à un serveur final (backend) faisant tourner un bon gros spamassassin/SARE des familles avant la distribution du courrier. Le tout pour desservir 150 utilisateurs et/ou boîtes mails environ (sans compter des vieux comptent qui n’existent plus et que les spammeurs doivent avoir encore « en tête »).
La mise en place du greylisting pour postfix est détaillée dans ma doc, il ne manque qu’une indication : démarrer le service postgrey après installation 🙂 Continuer la lecture →

Spamassassin : se créer une règle de détection spécifique

6 réponses

Malgré des règles assez sympathiques (voyez ma doc Debian (encore ? oui oui) pour les mettre en place), il arrive que certains spams ne soient pas reconnus. Si vous avez envie d’écrire une règle hyper compliquée ou simplement une petite règle car vous avez détecté qu’un serveur relai bien moisi était à l’origine de cela, voici une mini-introduction pour le faire. Continuer la lecture →

spamassassin 3.2 et ImageInfo

Laisser un commentaire

Récemment, je suis passé d’un spamassassin 3.1 (issu d’une stable) à une version 3.2 (mixé depuis une testing). J’avais déjà installé le plug-in « ImageInfo » pour la détection des images « spammeuses » dans les mails. L’upgrade en spamassassin 3.2 a posé problème. Il y a un peu de littérature sur le sujet. Je consigne ici les symptomes de ce problème et la sa résolution Continuer la lecture →