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 [EMAIL PROTECTED], et on configure postfix pour que les adresses [EMAIL PROTECTED] 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. ... -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
