Re: Conseil lutte antispam
Daniel Caillibaud wrote:
> Ah, désolé, j'ai lu trop vite. Mais si c'est juste pour postfix <-> SA,
> pas besoin d'amavis (ni d'un autre intermédiare) pour ça...
>
sauf que amavisd-new n'est pas un simple intermediaire qui lance SA.
amavisd-new est un proxy qui peut faire du SA. en gros, avec
amavisd-new, tu évites le fork/exec de SA (ou de spamc) à chaque mail.
donc, reflechis encore à la question. personellement, je te conseille
d'utiliser amavisd-new.
de plus, amavid-new peut utiliser clamav (c'est par défaut) et tu gagnes
une étape dans ta config.
plus tard, tu pourras convigurer amavisd-new pour mettre des
"politiques" differentes selon le contexte.
>> Ce boulot est plutot pour Maildrop effectivement
>
on peut le faire avec amavisd-new + postfix, mais il faut vraiment le
vouloir (juste pour info, mais pas conseillé: on dit à amavisd-new de
rediriger les spams vers user+spam@domain, et on configure postfix pour
que les adresses user+spam@domain soient livrées dans
/chemin/vers/maildir/.Junk/ ça reste faisable si on gère les
utilisateurs sous *sql/ldap).
>>> Suivant les headers ajoutés par SA, postfix peut rejeter ou délivrer
>>> dans Maildir/new mais pas ailleurs.
Si le filtregae n'est pas fait pendant la connexion smtp (proxy_filter),
alors il ne faut pas rejecter le mail (c'est trop tard), sinon gare au
"backscatter" (envoi d'erreur à quelqu'un qui n'a jamais rien envoyé).
>>> => D'après vous, quelle serait la meilleur solution pour les envoyer
>>> par exemple vers Maildir/spam si score > X et Maildir/spam-probable
>>> si score > Y ?
>>>
>> Facile à faire avec maildrop
>>
ça peut se faire avec maildrop, procmail, sieve (pour les serveurs imap
qui supportent ça)... personellement, je prefere maildrop.
>> Jetes un oeil à ca:
>> http://www.free-4ever.net/index.php/Mail:Configuration_maildrop
>>
>> Ca te donnera une base de départ.
>
> Oui, je cherchais à éviter un truc supplémentaire, mais visiblement y'a
> pas le choix si on veut une distib conditionnelle.
>
il ne faut pas éviter les "trucs supplementaires". il vaut mieux avoir
des petits bouts qui font chacun une tache, et qui la font bien.
>>> Je pensais à un bête find + grep + mv en crontab dans les maildirs,
>>> mais y'a peut-être plus intelligent et pas trop gourmand (pas trop
>>> envie d'avoir amavis qui tourne juste pour ça).
>>>
>> Waouh.... ca parait effectivement un peu bourrin.... ;-)
>
> Oui, mais hyper light (2 lignes) ;-)
pas vraiment. il y a deux repertoires à gerer (new/ et cur/) et il y a
le problème des accès concurrents (le serveur imap peut faire quelque
chose avec le fichier).
> Bon, on peut ausi se faire son propre filtre en shell, mais dans ce cas
> autant utiliser maildrop.
par ailleurs, on peut compiler maildrop en virant toutes les options
(genre authlib...), histoire de l'utiliser "betement". faut regarder le
package maildrop-dovecot, je crois que c'est fait pour se passer de
courier authlib.
pour revenir à la lutte anti-spam, il y a aussi du controle d'accès dans
postfix (smtpd_*_restrictions). en rejetant les mails pendant la
transaction smtp,
- tu decharges tes filters (SA, ...)
- tu decharges ton système
- tu arrete des spams que le filtre n'arretera pas
- tu laisses une chance à l'expediteur de se rende compte du problème
(mettre dans un dossier Junk est amusant au début, mais quand il devient
trop plein, on ne le regarde pas assez pour récupérer des erreurs de
filtrage).
voici quelques tests à regarder (il faut les comprendre en lisant la doc
et se faire une idée soi-même. il n'y a pas de niveau de filtrage
universel):
- reject_invalid_helo_hostname (ne devrait poser aucun problème)
- reject_non_fqdn_helo_hostname (en théorie, il y a des serveurs,
principalement exchange, qui sont mal configurés. mais bon, s'ils sont
mal configurés, ils peuvent être bien "abusés" aussi...)
- reject_unknown_sender_domain (on cause pas avec des gens à qui on ne
peut pas causer)
- reject_rbl_client avec des listes choisies. la liste la plus
"conseillée" est zen.spamhaus.org. depuis un certain temps, la liste de
spamcops est devenue "utilisable". il y a aussi korea.services.net et la
dsbl, mais ils n'arretent pas beaucoup de spam.
- tu peux "proteger" contre les listes noires ci-dessus en utilisant la
liste blanche de chez dswl.org.
...
Reply to: