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"].
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
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]
