Re: comment filtrer le spam (sur un exim4, serveur virtuel, domaine personnels)
On Sun, 14 Nov 2010 08:17:48 +0100
Alain Rpnpif <rpnpif@free.fr> wrote:
>
> Spamassassin n'est pas un MTA, c'est le rôle d'Exim ou équivalent
> d'envoyer les messages vers Free.fr. Je dis ça mais je connais mal
> Exim, utilisant Postfix à la place.
J'ai finalement conservé exim4.
>
> Donc d'après moi, il faudrait : messages (fetchmail ?) -> exim ->
> spamassassin -> exim -> smtp.Free.fr. On peut aussi y associer procmail
> pour la redirection vers Free.fr.
Non, pas fetchmail pour moi, car je suis en train de configurer le
serveur SMTP mail.starynkevitch.net mentionné en MX dans le DNS du
domaine starynkevitch.net. Il reçoit donc tous les méls vers
@starynkevitch.net en protocole SMTP. Au sens de dpkg-reconfigure
exim4-config ce serveur est un full internet SMTP server, pas un
internet SMTP server with smarthost.
Pour illustrer mon propos, je vais prendre l'exemple fictif d'une boite
linustruc@starynkevitch.net qui n'existe évidemment pas pour de vrai.
J'avai cherché plusieurs paquets, et j'avais trouvé dspam mais je n'ai
pas réussi à le faire fonctionner (le paquet dspam existe -ainsi que
dspam-webfrontend etc..), mais il est configuré de manière incompatible
avec la configuration d'exim, et malgré la lecture de plusieurs sites,
notamment
http://blog.edseek.com/archives/2007/02/08/configuring-exim4-for-dspam-on-debian-or-ubuntu/
je ne suis pas arrivé à le faire fonctionner correctement. En plus
c'est sur le serveur gérant réellement mon mél (et celui de ma
famille), et donc les mauvaises configuations risquaient de faire
perdre des messages.
Sur le papier, dspam avec dspam-webfrontend répond quasi idéalement à
mes besoins: il filtre, comme spamoracle, le contenu des messages par
des algorithmes bayésiens réputés efficaces. Il intervient dans des
règles de transport et de routage au sens d'exim.
Ces règles d'exim et le programme dspam combinés sont censés se
comporter comme suit:
1. En plus du comportement habituel (rejet de relai ouvert SMTP, et des
adresses de mél inexistantes...) d'exim4 tel que configuré sous Debian,
tout message vers une adresse @starynkevitch.net est d'abord traité par
dspam qui y ajout des entêtes spécifiques du genre de
X-DSPAM-Result: User; result="Spam"; probability=1.0000;
confidence=0.80
(D'ailleurs spamoracle ajoute aussi le résultat du filtrage dans un
entête spécifique). Un message filtré comme spam serait étiquetté par
un entête indiquant Spam.
2. Les messages étiquettés non spam sont transportés (au sens Exim)
sans délai vers leurs destinataires (dans mon cas, forwardés vers les
comptes @gmail ou @free ... de mes enfants, par exemple fictif
linustruc@gmail...)
3. Les messages analysés et étiquettés comme spam sont mis en
quarantaine: si j'ai bien compris, ils sont mises dans une queue
spéciale d'exim4.
4. le paquet dpsam-webfrontend fournit des scripts CGI codés en Perl
(pour un serveur Web comme Apache, Lighttpd, ou même Ocsigen) et on
peut donc consulter [au moins le titre et expéditeur de chaque message
en quarantaine] la queue des spams en quarantaine, et "libérer"
certains qui sont alors redirigés vers linustruc@ ... ou en supprimer
d'autres de la queue.
5. En l'absence d'action via un CGI, un message réputé SPAM est
supprimé au bout d'un certain délai configurable (je crois 24 ou 48h)
de la queue de quarantaine.
6. L'utilisateur peut aussi, soit dans un CGI fourni par
dspam-webfrontend, soit en réexpediant depuis son MUA local (comme
sylpheed ou evolution) un message mal classé comme Spam ou Ham (= bon)
vers linustruc-good@starynkevitch.net ou
linustruc-spam@starynkevitch.net. Les coefficients bayésiens de dspam
sont ainsi légèrement modifiés par "machine learning" et on peut
espérer améliorer le comportement du filtrage. Il me semble que l'accès
à ces boites linustruc-good@ et linustruc-spam@ est limité à certains
expéditeurs (mais je n'ai pas compris comment, je crois que c'est une
configuration exim4 de plus).
>
> Renvoyer les spams à leur expéditeur n'est pas une bonne idée et est
> habituellement déconseillé. Certains spammeurs n'attendent que ça. Moi
> je les envoie dans une boîte perso afin d'y détecter les faux positifs
> (quelques unités par moi) avant mise à la poubelle. Le destinataire
> peut aussi les filtrer vers un répertoire spécial en se basant sur
> les en-têtes.
>
> Quel rapport entre le filtre antispam et le serveur web/php ?
Web oui, PHP non. En effet, dspam a une interface web, comme expliquée
ci dessus, qui permet d'intérroger la queue des messages en
quarantaine, qui permet aussi d'afficher des statistiques, d'ajouter
des adresses méls dans des listes blanches (d'expéditeurs à accepter
sans filtrage, etc.), de faire apprendre dspam en redirigeant un mél
vers linustruc-good@ localement, de supprimer un message de la queue de
quarantaine, etc. D'ailleurs, des filtres antispam propriétaires et
windowsiens fonctionnent sur le même principe: à mon boulot, ma boite
@cea.fr a une interface webmail microsoftienne, et on peut libérer les
spams de leur queue via le web
Dspam aurait été très bien pour moi, mais je n'ai pas réussi à le
configurer (et j'ai même failli casser ma config exim4).
J'ai finalement adopté une autre solution, plus légère mais assez
efficace. Le greylisting comme indiqué en
http://www.debian-administration.org/articles/167 en ajoutant le paquet
greylistd de Debian
Le principe est le suivant: lors de la première interaction SMTP (entre
un serveur de mail emetteur ou intermediaire et le mien
mail.starynkevitch.net) exim4 avec laide de greylistd répond par un
rejet temporaire à la première interaction SMTP et greylistd mémorise
l'adresse mél émettrice et son serveur SMTP. Pour les services SMTP
convenablement configurés ca demande de recommencer l'interaction plus
tard (par exemple 10 minutes plus tard). Et à la deuxième interaction
(mentionnant le même expéditeur mél et provenant du même serveur SMTP),
effectuée quelques minutes plus tard, le paquet greylistd a mémorisé et
détécté que c'est les mêmes expéditeur et serveur et exim4 traite le
message correctement.
C'est efficace pour le spam, car la plupart des spams sont émis par des
machines zombies organisées en spambot (souvent des machines
windowsiennes infectés) qu'on peut, parait-il, acheter par dizaines de
milliers dans des marchés noirs à Moscou (ou ailleurs). Ces machines
spammeuses ne respectent pas les règles SMTP et n'implémentent pas le
réenvoi postérieur d'un message temporairement rejeté.
Si un messag émis par un serveur SMTP convenablement configuré n'arrive
pas, son émetteur est sensé être prévenu.
En pratique cette solution exim4 + greylistd est très efficace. Je
recois encore quelques spams (ceux émis par des SMTPs bien configurés,
pas par des spambots achetés dans les caves de Moscou ou d'ailleurs)
mais le taux est supportable. Sans greylistd je recevais quelques spams
par minutes, avec greylistd je recois moins d'un spam par heure.
Le léger inconvenient d'exim4 + greylistd, c'est que le premier message
d'un échange par mél est retardé de dix minutes ou un quart d'heure en
pratique (mais pas les messages suivants), mais c'est tout à fait
supportable.
C'est quand même dommage que je n'ai pas réussi à configurer dspam. Les
docs et exemples ne sont pas à jour par rapport à la config exim4, et
j'ai eu des gros problèmes de permission (car dspam tourne sous
l'utilisateur dspam, pas sous celui d'exim).
Cordialement.
PS. je parle bien de configurer un serveur mail mentionné par MX dans
le DNS, pas une machine personnelle qui recoit le mél en fetchmail!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
Reply to: