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 ?
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 ?
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 ?
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"].
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"].
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"].
[snip]
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.
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).
[snip]
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.
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).
[snip]
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.
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).