Re: Postfix: ordre des vérifications (greylisting, RBL)?
Le mercredi 04 juin 2008 à 19:15 +0200, mouss a écrit :
> Julien Valroff wrote:
> > Bonjour,
> >
> > J'utilise depuis peu le greylisting sous Debian Etch, avec Postfix (et
> > donc Postgrey).
> >
> > En parallèle, j'utilise également des RBL qui se sont montrées efficaces
> > jusque maintenant.
> >
> > Tout fonctionne correctement, mais je me pose la question de l'ordre
> > dans les quel les contrôles doivent être effectués : greylisting avant
> > RBL ou l'inverse ?
> >
> > J'ai pour le moment laissé les RBL faire leur travail, en me disant
> > qu'il vaut mieux rejeter le plus tôt possible plutôt que d'attendre,
> > mais l'accès aux RBL n'est-il pas plus consommateur en ressources qu'un
> > rejet temporaire de la part de postgrey ?
> >
>
>
> Il y a deux écoles:
>
> 1- on fait le greylisting à la fin. l'idée est qu'il n'y a pas de raison
> de polluer la base de greylisting avec des entrées qui ne serviront
> jamais puisque le client se fera jeter par d'autres tests.
>
> 2- on fait le greylisting et si une transaction est "greylistée", on
> s'arrête et on ne fait pas les tests suivants. pour cela, il faut que le
> serveur de GL renvoie "defer" et non "defer_if_permit" (en général,
> c'est cette dernière action qui est renvoyée). L'idée ici est d'éviter
> de faire des requêtes couteuses si le client ne réessaye pas.
>
> si tu ne reçois pas trop de mail, les deux approches se valent plus ou
> moins. si tu reçois beaucoup de mails, la 2 est mieux car sinon il
> faudra payer un "feed" de spamhaus (et comme zen.spamhaus.org est la
> mailleure liste, ...).
C'est un petit serveur avec seulement 3 ou 4 utilisateurs réguliers, je
suis de loin celui qui reçoit le plus de mail, donc mon approche est la
bonne.
> Si tu veux "juger", il faut savoir que
> - il y a des "ratware" qui réessayent (probablement à l'aveugle dans la
> majorité des cas)
> - il y a des clients "légitimes" qui réessayent même quand il se font
> jeter (avec un 5xx).
>
> Pendant que j'y suis, il faut savoir que le greylisting "aveugle" n'est
> pas très désirable. quand il y a une discussion entre N personnes, celui
> qui greyliste l'un des message ne le recevra pas de suite, et verra des
> fils de discussion où il a l'impression d'avoir raté quelques messages
> (qui arriveront plus tard)... et de toute façon, ce n'est pas gentil de
> faire travailer des serveurs "honnêtes". Par contre, on peut faire du
> greylisting selectif: greylister si quelque chose est louche (un helo
> pas super top, un reverse dns "générique", ... etc). Et idéalement, il
> faut whitelister (du greylisting seulement) tout client qui a déjà passé
> l'épreuve (si on sait qu'il réessaye, pas la peine de le retester). [on
> peut aussi ne whitelister (du greylisting toujours, pas des autres
> vérifications) que les clients qui ont envoyé au moins un message
> "innocent"].
postgrey a comme configuration par défaut de whitelister automatiquement
tous les serveurs ayant passé cette barrière avec succès 5 fois
(configurable bien entendu), en plus d'une whitelist maintenue
manuellement par les développeurs (listant les plus gros serveurs ayant
des problèmes avec le greylisting ou ceux qui sont bien connus de tous).
Le paquet Debian a par ailleurs ajouté les serveurs debian.org ("and
related") sur lesquels tournent de vrai serveurs smtp.
J'ai de mon coté ajouté certains serveurs de mailing-lists afin d'éviter
le problème dont tu parles plus haut.
Pour moi, les résultats ne sont pas vraiment probants, les RBL sont de
loin la technique me permettant d'éliminer le plus de spam, mais comme
je n'ai pas leur contrôle, je n'ai pas vraiment confiance (certaines des
plus connues ont déjà blacklisté les serveurs Debian ou ceux d'Orange
notamment).
Merci pour ta réponse
Julien
Reply to: