Comments on: Statistiques de greylisting http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/ Si le titre de l'article ne te fait pas mal au crâne, ce blog est pour toi :) Tue, 07 Sep 2010 21:32:32 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: Zoph http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/comment-page-1/#comment-1097 Zoph Wed, 21 Jan 2009 08:26:44 +0000 http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/#comment-1097 Merci pour votre réponse ! Merci pour votre réponse !

]]> By: michauko http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/comment-page-1/#comment-1096 michauko Mon, 19 Jan 2009 15:40:29 +0000 http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/#comment-1096 mailgraph mailgraph

]]> By: Zoph http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/comment-page-1/#comment-1095 Zoph Mon, 19 Jan 2009 15:17:17 +0000 http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/#comment-1095 Bonjour, Ces graphs sont produits avec quel outil ? Merci d'avance, Bonjour,

Ces graphs sont produits avec quel outil ?

Merci d’avance,

]]> By: michauko http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/comment-page-1/#comment-443 michauko Thu, 06 Mar 2008 17:38:21 +0000 http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/#comment-443 Mmmmm, certes, tu dois avoir raison. Je ne sais pas pourquoi je me suis mis dans la tête qu'une fois l'envoi effectué, la connexion était fermée. Mais en effet, la réponse du destinataire fait parti du dialogue lors de l'envoi... J'ai aussi lu qu'il était bon de virer sa base de serveurs whitelistés par postgrey, de temps en temps. Si ton greylisting date un peu, peut-être que ça lui filera un coup de jeune. Tiens moi au courant. Attention : RAZ => léger délai pour tes utilisateurs pendant quelques jours. Mon autre installation de greylisting - qui a + d'un an - n'est pas assez grosse (~10 users) pour y voir quelque chose. Pour le MX inexistant, tu verrais l'impact par une baisse du nombre de spams en entrée de ton vrai MX, si le programme du spammeur est assez con pour ne pas tenter un autre MX (et si le "chemin retour" est possible ;). merci pour le post Mmmmm, certes, tu dois avoir raison. Je ne sais pas pourquoi je me suis mis dans la tête qu’une fois l’envoi effectué, la connexion était fermée. Mais en effet, la réponse du destinataire fait parti du dialogue lors de l’envoi…

J’ai aussi lu qu’il était bon de virer sa base de serveurs whitelistés par postgrey, de temps en temps. Si ton greylisting date un peu, peut-être que ça lui filera un coup de jeune. Tiens moi au courant. Attention : RAZ => léger délai pour tes utilisateurs pendant quelques jours.

Mon autre installation de greylisting – qui a + d’un an – n’est pas assez grosse (~10 users) pour y voir quelque chose.

Pour le MX inexistant, tu verrais l’impact par une baisse du nombre de spams en entrée de ton vrai MX, si le programme du spammeur est assez con pour ne pas tenter un autre MX (et si le “chemin retour” est possible ;) .

merci pour le post

]]> By: thetoon http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/comment-page-1/#comment-435 thetoon Thu, 06 Mar 2008 08:16:02 +0000 http://michauko.org/blog/2008/03/05/statistiques-de-greylisting/#comment-435 Juste pour information : pas besoin de "chemin retour" pour indiquer à l'émetteur qu'il y a une erreur temporaire (le coeur du greylisting). C'est transmis par la connexion SMTP initiale. Donc le spammeur potentiel recevra _toujours_ la "demande standard de renvoi de mail". Et vu l'évolution de mes statistiques de greylisting depuis quelques années, ils commençent à avoir pigé le truc. Mais le fait de greylister les 5 premiers envois au lieu d'un seul doit limiter la casse (et en tous cas faire perdre 5 fois plus de temps aux spammeurs). Pour la partie logicielle, je suis en général plus adepte de postfix-policyd, qui offre l'avantage de pouvoir faire piège-à-miel (ou honeypot : une ou plusieurs adresses fictives et improbables qui ajoutent automatiquement tout émetteur dans une liste noire), régulateur de flux (pour gérer une QoS rudimentaire), etc. Pour le fait d'avoir un MX inexistant, c'est probablement efficace, mais il n'y a guère de moyen de s'en assurer : par définition, les tentatives d'envoi sur ce MX ne seront jamais comptabilisées. Juste pour information : pas besoin de “chemin retour” pour indiquer à l’émetteur qu’il y a une erreur temporaire (le coeur du greylisting). C’est transmis par la connexion SMTP initiale. Donc le spammeur potentiel recevra _toujours_ la “demande standard de renvoi de mail”. Et vu l’évolution de mes statistiques de greylisting depuis quelques années, ils commençent à avoir pigé le truc. Mais le fait de greylister les 5 premiers envois au lieu d’un seul doit limiter la casse (et en tous cas faire perdre 5 fois plus de temps aux spammeurs).

Pour la partie logicielle, je suis en général plus adepte de postfix-policyd, qui offre l’avantage de pouvoir faire piège-à-miel (ou honeypot : une ou plusieurs adresses fictives et improbables qui ajoutent automatiquement tout émetteur dans une liste noire), régulateur de flux (pour gérer une QoS rudimentaire), etc.

Pour le fait d’avoir un MX inexistant, c’est probablement efficace, mais il n’y a guère de moyen de s’en assurer : par définition, les tentatives d’envoi sur ce MX ne seront jamais comptabilisées.

]]>