Re: Conseil lutte antispam
Merci mouss pour toutes ces rmqs.
mouss a écrit :
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.
Justement, j'ai pas envie d'un proxy qui tourne en permanence pour 3 comptes mails.
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.
J'ai pas clamav et j'en veux pas.
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é).
Je ne veux pas le rejeter mais le délivrer ailleurs que dans new
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 suis bien d'accord. C'est juste que amavis me paraissait (et me parait toujours) un très (trop) gros machin pour mes
besoins.
Vu qu'il y a déjà courier pour auth & pop(s) & imap(s), je vais juste rajouter courier-maildrop et ça ira.
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).
Oui bien sûr, l'un n'empêche pas l'autre.
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.
Ajouter aussi un petit filtre pour virer tous les mails avec un *.pif, et éventuellement d'autres extensions (sur
certaines boites j'en ai un paquet par jour), cf par exemple le 2e post de
http://forum.hardware.fr/hfr/OSAlternatifs/Logiciels-2/postfix-interdire-jointes-sujet_27904_1.htm (un peu violent sur
la liste de PJ, à adapter).
--
Daniel
Reply to: