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, ...).
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"].