Postfix: ordre des v

Le
Julien Valroff
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 ?

Merci par avance pour vos commentaires/retours d'expérience.

@++
Julien

--
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 debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
mouss
Le #9662031
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
with a subject of "unsubscribe". Trouble? Contact
Julien Valroff
Le #9662011
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

--
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
with a subject of "unsubscribe". Trouble? Contact
mouss
Le #9662001
Julien Valroff wrote:
[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.






dans une config "normale", l'approche 1 est la plus commune (lancer le
GL à la fin).

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.




tu peux utiliser dnswl comme liste blanche. Pour cela, il faut la
telecharger avec rsync
http://www.dnswl.org/tech#rsync
et l'utiliser avec un
check_client_access cidr:/chemin/vers/postfix-dnswl-permit

comme ça, pas de risque de bloquer un "bon" client, et ça évite de
devoir gérer ça en interne. Par exemple:

$ grep -i debian
/usr/local/etc/postfix/maps/cidr/dnswl.org/postfix-dnswl-permit
217.196.43.134/32 permit_auth_destination low debian.org DNSWLId 1791
202.134.73.140/32 permit_auth_destination low debian.org.hk
DNSWLId 8772
202.134.73.139/32 permit_auth_destination low debian.org.hk
DNSWLId 8772
194.109.137.218/32 permit_auth_destination low debian.org DNSWLId 1791
192.25.206.59/32 permit_auth_destination low debian.org DNSWLId 1791
192.25.206.57/32 permit_auth_destination low debian.org DNSWLId 1791
192.25.206.33/32 permit_auth_destination low debian.org DNSWLId 1791
192.25.206.28/32 permit_auth_destination low debian.org DNSWLId 1791
192.25.206.16/32 permit_auth_destination low debian.org DNSWLId 1791
192.25.206.10/32 permit_auth_destination low debian.org DNSWLId 1791
146.82.138.6/32 permit_auth_destination low debian.org DNSWLId 1791
140.211.166.43/32 permit_auth_destination low debian.org DNSWLId 1791
87.106.4.56/32 permit_auth_destination low debian.org DNSWLId 1791
86.59.118.152/32 permit_auth_destination med debian.or.at DNSWLId
11329
86.59.21.34/32 permit_auth_destination low debian.or.at DNSWLId 6694
82.195.75.100/32 permit_auth_destination low debian.org DNSWLId 1791
80.68.80.176/32 permit_auth_destination none debian-administration.org
DNSWLId 3368
78.47.201.134/32 permit_auth_destination low debianforum.de
DNSWLId 11631
70.103.162.31/32 permit_auth_destination low debian.org DNSWLId 1791
70.103.162.29/32 permit_auth_destination low debian.org DNSWLId 1791


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,



ici, reject_non_fqdn_helo_hostname vire plus de 30% des transactions
(par transaction, je veux dire un RCPT TO. donc un client qui tente
d'envoyer à plusieurs destinataires sera compté plusieurs fois).

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).




tu parles de sorbs? il y a eu une "bataille" entre sorbs et orange. le
tort est partagé. Orange n'ont pas été très fins: ils ont demandé aux
hebergeurs de sorbs de virer sorbs...

zen.spamhaus.org a la réputation d'etre "safe" et suffit par rapport aux
autres.

--
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
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme