Je ne sais pas si je suis H.S. en publiant ce message sur fr.comp.securite.
Auriez-vous connaissance d'un site francophone proposant une blacklist permettant d'affiner les règlages de son logiciel antispam ?
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur, indépendant du logiciel de messagerie. liste grise.
db -- email : usenet blas net
Guillermito
On 25 Jun 2004 12:50:29 GMT, db wrote:
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur, indépendant du logiciel de messagerie.
liste grise.
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux fois que vous le citez, et j'avoue humblement que je n'en ai jamais entendu parler (quoique d'après le nom, je me fais une vague idée). Un ou deux pointeurs sur des pages techniques pourraient aussi faire l'affaire. Merci!
-- Guillermito http://www.guillermito2.net
On 25 Jun 2004 12:50:29 GMT, db wrote:
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur,
indépendant du logiciel de messagerie.
liste grise.
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux
fois que vous le citez, et j'avoue humblement que je n'en ai jamais
entendu parler (quoique d'après le nom, je me fais une vague idée). Un
ou deux pointeurs sur des pages techniques pourraient aussi faire
l'affaire. Merci!
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur, indépendant du logiciel de messagerie.
liste grise.
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux fois que vous le citez, et j'avoue humblement que je n'en ai jamais entendu parler (quoique d'après le nom, je me fais une vague idée). Un ou deux pointeurs sur des pages techniques pourraient aussi faire l'affaire. Merci!
-- Guillermito http://www.guillermito2.net
Xavier Roche
Guillermito wrote:
Vous pouvez expliquer le concept de ces "listes grises"?
D'après ce qu'en ai vu, cela consiste à ajouter sur le serveur de messagerie un plugin qui lors de l'arrivée d'un mail:
1. Canoniser le from, le to, et récupérer l'IP entrante : from, to, ip 2. Calculer un hash h=hash(from:to:ip) et récupérer la date t courante 3. Vérifie sur une DB si la clé h existe. Si oui, récupérer t' la date stockée correspondante, sinon stocker sur la DB (h, t) 4. Calculer t-t' et vérifier si il est supérieur à une durée arbitraire (exemple: 1 heure). Supérieur: accepter le mail. Inférieur: refuser remporairement (code SMTP 4XX) le mail
Les clés confirmées sont valides "un certain temps" (pour ne pas faire exploser la DB - du genre un mois) puis expirent si aucun trafic n'est enregistré sur le h correspondant
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait peur. Seul inconvénient: temps de réponse sur le premier échange important.
Note: On peut coupler le système à un système type SPF, et accepter par défaut les mails dont le from vient d'une adresse sur le même bloc que le MX du domaine, pour "accélérer " certains domaines et court circuiter le temps de réponse
Guillermito wrote:
Vous pouvez expliquer le concept de ces "listes grises"?
D'après ce qu'en ai vu, cela consiste à ajouter sur le serveur de
messagerie un plugin qui lors de l'arrivée d'un mail:
1. Canoniser le from, le to, et récupérer l'IP entrante : from, to, ip
2. Calculer un hash h=hash(from:to:ip) et récupérer la date t courante
3. Vérifie sur une DB si la clé h existe. Si oui, récupérer t' la date
stockée correspondante, sinon stocker sur la DB (h, t)
4. Calculer t-t' et vérifier si il est supérieur à une durée arbitraire
(exemple: 1 heure). Supérieur: accepter le mail. Inférieur: refuser
remporairement (code SMTP 4XX) le mail
Les clés confirmées sont valides "un certain temps" (pour ne pas faire
exploser la DB - du genre un mois) puis expirent si aucun trafic n'est
enregistré sur le h correspondant
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait
peur. Seul inconvénient: temps de réponse sur le premier échange important.
Note: On peut coupler le système à un système type SPF, et accepter par
défaut les mails dont le from vient d'une adresse sur le même bloc que
le MX du domaine, pour "accélérer " certains domaines et court circuiter
le temps de réponse
Vous pouvez expliquer le concept de ces "listes grises"?
D'après ce qu'en ai vu, cela consiste à ajouter sur le serveur de messagerie un plugin qui lors de l'arrivée d'un mail:
1. Canoniser le from, le to, et récupérer l'IP entrante : from, to, ip 2. Calculer un hash h=hash(from:to:ip) et récupérer la date t courante 3. Vérifie sur une DB si la clé h existe. Si oui, récupérer t' la date stockée correspondante, sinon stocker sur la DB (h, t) 4. Calculer t-t' et vérifier si il est supérieur à une durée arbitraire (exemple: 1 heure). Supérieur: accepter le mail. Inférieur: refuser remporairement (code SMTP 4XX) le mail
Les clés confirmées sont valides "un certain temps" (pour ne pas faire exploser la DB - du genre un mois) puis expirent si aucun trafic n'est enregistré sur le h correspondant
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait peur. Seul inconvénient: temps de réponse sur le premier échange important.
Note: On peut coupler le système à un système type SPF, et accepter par défaut les mails dont le from vient d'une adresse sur le même bloc que le MX du domaine, pour "accélérer " certains domaines et court circuiter le temps de réponse
Eric Razny
Guillermito wrote:
liste grise.
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux fois que vous le citez, et j'avoue humblement que je n'en ai jamais entendu parler (quoique d'après le nom, je me fais une vague idée). Un ou deux pointeurs sur des pages techniques pourraient aussi faire l'affaire. Merci!
http://greylisting.org/
Et, pour l'instant, ça marche du feu de dieu :) Couplé à un DNSBL "souple" et mon spamassassin est (presque) en manque de victimes :)
Eric.
Guillermito wrote:
liste grise.
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux
fois que vous le citez, et j'avoue humblement que je n'en ai jamais
entendu parler (quoique d'après le nom, je me fais une vague idée). Un
ou deux pointeurs sur des pages techniques pourraient aussi faire
l'affaire. Merci!
http://greylisting.org/
Et, pour l'instant, ça marche du feu de dieu :)
Couplé à un DNSBL "souple" et mon spamassassin est (presque) en manque de
victimes :)
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux fois que vous le citez, et j'avoue humblement que je n'en ai jamais entendu parler (quoique d'après le nom, je me fais une vague idée). Un ou deux pointeurs sur des pages techniques pourraient aussi faire l'affaire. Merci!
http://greylisting.org/
Et, pour l'instant, ça marche du feu de dieu :) Couplé à un DNSBL "souple" et mon spamassassin est (presque) en manque de victimes :)
Eric.
Alain Montfranc
Erwan David wrote:
Guillermito écrivait :
On 25 Jun 2004 12:50:29 GMT, db wrote:
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur, indépendant du logiciel de messagerie.
liste grise.
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux fois que vous le citez, et j'avoue humblement que je n'en ai jamais entendu parler (quoique d'après le nom, je me fais une vague idée). Un ou deux pointeurs sur des pages techniques pourraient aussi faire l'affaire. Merci!
le principe est simple : pour cahque mail on considère le triplet (from,to,ip émettrice).
Si ce triplet est connu, on laisse passer le message. S'il est inconnu on envoie une erreur temporaire (4xx) et au bout de quelques minutes on le met dans la base des triplets connus.
SI on a affaire à un vrai serveur SMTP, celui-ci réessaye au bout de quelques temps et le message passe. Si c'est un proxy ouvert (troyen, apache avec mod_proxy ouvert, etc) il n'y a pas de gestion de liste d'attente, donc le spam n'est pas présenté une seconde fois. Bien sûr il y a aussi un système de nettoyage des triplets qui n'ont pas été présentés depuis trop longtemps.
Ca me plait bien ca ;-)
Un nom pour installer sur un nunux/sendmail qui fait deja tourner MailScanner+SpamAssassin (a moins que ce ne soit inclus dedans mais j'ai pasvu)
Merci !
Erwan David wrote:
Guillermito <guillermito@pipo.com> écrivait :
On 25 Jun 2004 12:50:29 GMT, db wrote:
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur,
indépendant du logiciel de messagerie.
liste grise.
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux
fois que vous le citez, et j'avoue humblement que je n'en ai jamais
entendu parler (quoique d'après le nom, je me fais une vague idée). Un
ou deux pointeurs sur des pages techniques pourraient aussi faire
l'affaire. Merci!
le principe est simple :
pour cahque mail on considère le triplet (from,to,ip émettrice).
Si ce triplet est connu, on laisse passer le message. S'il est inconnu
on envoie une erreur temporaire (4xx) et au bout de quelques minutes
on le met dans la base des triplets connus.
SI on a affaire à un vrai serveur SMTP, celui-ci réessaye au bout de
quelques temps et le message passe. Si c'est un proxy ouvert (troyen,
apache avec mod_proxy ouvert, etc) il n'y a pas de gestion de liste
d'attente, donc le spam n'est pas présenté une seconde fois.
Bien sûr il y a aussi un système de nettoyage des triplets qui n'ont
pas été présentés depuis trop longtemps.
Ca me plait bien ca ;-)
Un nom pour installer sur un nunux/sendmail qui fait deja tourner
MailScanner+SpamAssassin (a moins que ce ne soit inclus dedans mais j'ai
pasvu)
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur, indépendant du logiciel de messagerie.
liste grise.
Vous pouvez expliquer le concept de ces "listes grises"? Ca fait deux fois que vous le citez, et j'avoue humblement que je n'en ai jamais entendu parler (quoique d'après le nom, je me fais une vague idée). Un ou deux pointeurs sur des pages techniques pourraient aussi faire l'affaire. Merci!
le principe est simple : pour cahque mail on considère le triplet (from,to,ip émettrice).
Si ce triplet est connu, on laisse passer le message. S'il est inconnu on envoie une erreur temporaire (4xx) et au bout de quelques minutes on le met dans la base des triplets connus.
SI on a affaire à un vrai serveur SMTP, celui-ci réessaye au bout de quelques temps et le message passe. Si c'est un proxy ouvert (troyen, apache avec mod_proxy ouvert, etc) il n'y a pas de gestion de liste d'attente, donc le spam n'est pas présenté une seconde fois. Bien sûr il y a aussi un système de nettoyage des triplets qui n'ont pas été présentés depuis trop longtemps.
Ca me plait bien ca ;-)
Un nom pour installer sur un nunux/sendmail qui fait deja tourner MailScanner+SpamAssassin (a moins que ce ne soit inclus dedans mais j'ai pasvu)
Merci !
tchelaviek
Salut, Xavier Roche. Tu as écrit:
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait peur. Seul inconvénient: temps de réponse sur le premier échange important.
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres filtres derrière et que les programmes de spamming s'adapteront très facilement si tout le monde se met à faire ça, a terme, non seulement le courriel légitime risque toujours d'être perdu, mais en plus, en retard.
C'est d'une banalité navrante, ce que je viens d'écrire... :(
Le mieux, c'est encore de trouver son truc, comme LW, et de le garder pour soi. ;)
-- tchelaviek
Salut, Xavier Roche. Tu as écrit:
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait
peur. Seul inconvénient: temps de réponse sur le premier échange
important.
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres
filtres derrière et que les programmes de spamming s'adapteront très
facilement si tout le monde se met à faire ça, a terme, non seulement le
courriel légitime risque toujours d'être perdu, mais en plus, en retard.
C'est d'une banalité navrante, ce que je viens d'écrire... :(
Le mieux, c'est encore de trouver son truc, comme LW, et de le garder
pour soi. ;)
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait peur. Seul inconvénient: temps de réponse sur le premier échange important.
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres filtres derrière et que les programmes de spamming s'adapteront très facilement si tout le monde se met à faire ça, a terme, non seulement le courriel légitime risque toujours d'être perdu, mais en plus, en retard.
C'est d'une banalité navrante, ce que je viens d'écrire... :(
Le mieux, c'est encore de trouver son truc, comme LW, et de le garder pour soi. ;)
-- tchelaviek
Xavier Roche
tchelaviek wrote:
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres filtres derrière et que les programmes de spamming s'adapteront très facilement si tout le monde se met à faire ça, a terme, non seulement le courriel légitime risque toujours d'être perdu, mais en plus, en retard.
Non. Il faudrait pour cela un système très solide, avec gestion d'une queue d'envoi. Cela laisse le temps de couper la source du spam ; càd en général - un serveur en relais ouvert - une machine trojannée - un dialup temporaire ..
tchelaviek wrote:
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres
filtres derrière et que les programmes de spamming s'adapteront très
facilement si tout le monde se met à faire ça, a terme, non seulement le
courriel légitime risque toujours d'être perdu, mais en plus, en retard.
Non. Il faudrait pour cela un système très solide, avec gestion d'une
queue d'envoi. Cela laisse le temps de couper la source du spam ; càd
en général
- un serveur en relais ouvert
- une machine trojannée
- un dialup temporaire
..
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres filtres derrière et que les programmes de spamming s'adapteront très facilement si tout le monde se met à faire ça, a terme, non seulement le courriel légitime risque toujours d'être perdu, mais en plus, en retard.
Non. Il faudrait pour cela un système très solide, avec gestion d'une queue d'envoi. Cela laisse le temps de couper la source du spam ; càd en général - un serveur en relais ouvert - une machine trojannée - un dialup temporaire ..
Eric Razny
tchelaviek wrote:
Salut, Xavier Roche. Tu as écrit:
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait peur. Seul inconvénient: temps de réponse sur le premier échange important.
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres filtres derrière et que les programmes de spamming s'adapteront très facilement si tout le monde se met à faire ça, a terme, non seulement le courriel légitime risque toujours d'être perdu, mais en plus, en retard.
Oui mais non :) D'abord l'immense majorité des courriers légitimes semblent être des échanges entres personnes qui se connaissent. Dans ces cas seul le _premier_ email est retardé[1].
Ensuite un autre effet du délai est (hypothèse optimiste?) que les RBLs [2] seront mises à jour durant ce délai. Amha le greylisting prend toute sa puissance en le combinant aux autres techniques. Pour l'instant je ne me sers même pas de ça, mon délai est d'à peine 5mn!!!
Enfin des filtres plus classiques (genre spamassassin) finissent le boulot pour ce qui a réussi à passer (et à bouffer de la BP :( ).
Accessoirement même si cette solution devaient finalement être contournée dans un futur même proche je ne vois pas de raison de se passer de quelque chose de très efficace[3] dans l'immédiat.
Les vrais faiblesses de ce système sont , je trouve :
-quand on se retrouve devant un tas de serveurs qui se repassent le bébé et affichent une ip différente à chaque tentative. -les ressources à mettre en place pour gérer les triplets si on a beaucoup de comptes derriere[4]
Eric
PS : ça peut rester ici pour cause de DOS mais ça devrait plutôt continuer sur fr.comp.mail.serveurs (où ceci avait déjà été discuté d'ailleurs), non?
[1] Chez moi j'ai mis la disparition des triplets auto-whitelistés à 45 jours, comme ça même les emails mensuels (inscription à des certaines newsletters par exemple) passent sans délai.
[2] ne pas utiliser les plus aggressives si on ne veut pas (trop) risquer de perdre du traffic légitime, penser à whitelister les FAI les plus utilisés par les correspondants des utilisateurs.
[3] Pour éviter la casse il y a même des listes de MTA pourraves qui ne retentent pas une connexions.
[4] Pour le spamming on peut quand même virer les triplets qui ne correspondent pas à un email valide, mais ça bouffe de la ressource. -- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
tchelaviek wrote:
Salut, Xavier Roche. Tu as écrit:
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait
peur. Seul inconvénient: temps de réponse sur le premier échange
important.
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres
filtres derrière et que les programmes de spamming s'adapteront très
facilement si tout le monde se met à faire ça, a terme, non seulement
le courriel légitime risque toujours d'être perdu, mais en plus, en
retard.
Oui mais non :)
D'abord l'immense majorité des courriers légitimes semblent être des
échanges entres personnes qui se connaissent. Dans ces cas seul le _premier_
email est retardé[1].
Ensuite un autre effet du délai est (hypothèse optimiste?) que les RBLs [2]
seront mises à jour durant ce délai. Amha le greylisting prend toute sa
puissance en le combinant aux autres techniques. Pour l'instant je ne me
sers même pas de ça, mon délai est d'à peine 5mn!!!
Enfin des filtres plus classiques (genre spamassassin) finissent le boulot
pour ce qui a réussi à passer (et à bouffer de la BP :( ).
Accessoirement même si cette solution devaient finalement être contournée
dans un futur même proche je ne vois pas de raison de se passer de quelque
chose de très efficace[3] dans l'immédiat.
Les vrais faiblesses de ce système sont , je trouve :
-quand on se retrouve devant un tas de serveurs qui se repassent le bébé et
affichent une ip différente à chaque tentative.
-les ressources à mettre en place pour gérer les triplets si on a beaucoup
de comptes derriere[4]
Eric
PS : ça peut rester ici pour cause de DOS mais ça devrait plutôt continuer
sur fr.comp.mail.serveurs (où ceci avait déjà été discuté d'ailleurs), non?
[1] Chez moi j'ai mis la disparition des triplets auto-whitelistés à 45
jours, comme ça même les emails mensuels (inscription à des certaines
newsletters par exemple) passent sans délai.
[2] ne pas utiliser les plus aggressives si on ne veut pas (trop) risquer de
perdre du traffic légitime, penser à whitelister les FAI les plus utilisés
par les correspondants des utilisateurs.
[3] Pour éviter la casse il y a même des listes de MTA pourraves qui ne
retentent pas une connexions.
[4] Pour le spamming on peut quand même virer les triplets qui ne
correspondent pas à un email valide, mais ça bouffe de la ressource.
--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.
C'est en tout casce que j'en ai compris. Et ca marche que ca en fait peur. Seul inconvénient: temps de réponse sur le premier échange important.
J'en vois un autre. Comme ça ne dispense pas d'appliquer les autres filtres derrière et que les programmes de spamming s'adapteront très facilement si tout le monde se met à faire ça, a terme, non seulement le courriel légitime risque toujours d'être perdu, mais en plus, en retard.
Oui mais non :) D'abord l'immense majorité des courriers légitimes semblent être des échanges entres personnes qui se connaissent. Dans ces cas seul le _premier_ email est retardé[1].
Ensuite un autre effet du délai est (hypothèse optimiste?) que les RBLs [2] seront mises à jour durant ce délai. Amha le greylisting prend toute sa puissance en le combinant aux autres techniques. Pour l'instant je ne me sers même pas de ça, mon délai est d'à peine 5mn!!!
Enfin des filtres plus classiques (genre spamassassin) finissent le boulot pour ce qui a réussi à passer (et à bouffer de la BP :( ).
Accessoirement même si cette solution devaient finalement être contournée dans un futur même proche je ne vois pas de raison de se passer de quelque chose de très efficace[3] dans l'immédiat.
Les vrais faiblesses de ce système sont , je trouve :
-quand on se retrouve devant un tas de serveurs qui se repassent le bébé et affichent une ip différente à chaque tentative. -les ressources à mettre en place pour gérer les triplets si on a beaucoup de comptes derriere[4]
Eric
PS : ça peut rester ici pour cause de DOS mais ça devrait plutôt continuer sur fr.comp.mail.serveurs (où ceci avait déjà été discuté d'ailleurs), non?
[1] Chez moi j'ai mis la disparition des triplets auto-whitelistés à 45 jours, comme ça même les emails mensuels (inscription à des certaines newsletters par exemple) passent sans délai.
[2] ne pas utiliser les plus aggressives si on ne veut pas (trop) risquer de perdre du traffic légitime, penser à whitelister les FAI les plus utilisés par les correspondants des utilisateurs.
[3] Pour éviter la casse il y a même des listes de MTA pourraves qui ne retentent pas une connexions.
[4] Pour le spamming on peut quand même virer les triplets qui ne correspondent pas à un email valide, mais ça bouffe de la ressource. -- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
tchelaviek
Xavier Roche a écrit:
Il faudrait pour cela un système très solide, avec gestion d'une queue d'envoi.
'sont pas capables de faire des systèmes solides, alors ? :o)
Cela laisse le temps de couper la source du spam
Dans ton exemple d'une heure, ça va pas être évident. Tu confirmes par là la nécessité de non-régression par rapport aux filtres existants. :>
-- tchelaviek
Xavier Roche a écrit:
Il faudrait pour cela un système très solide, avec gestion d'une
queue d'envoi.
'sont pas capables de faire des systèmes solides, alors ? :o)
Cela laisse le temps de couper la source du spam
Dans ton exemple d'une heure, ça va pas être évident. Tu confirmes par
là la nécessité de non-régression par rapport aux filtres existants. :>
Il faudrait pour cela un système très solide, avec gestion d'une queue d'envoi.
'sont pas capables de faire des systèmes solides, alors ? :o)
Cela laisse le temps de couper la source du spam
Dans ton exemple d'une heure, ça va pas être évident. Tu confirmes par là la nécessité de non-régression par rapport aux filtres existants. :>
-- tchelaviek
tchelaviek
Salut, Cyril Guibourg. Tu as écrit:
Je suis un peu moins pessimiste. Je pense que le greylisting a de beaux jours devant lui.
Ah, nonnon. C'est pas du pessimisme. C'est juste le triste constat de devoir céder encore un peu de terrain (délai+surcharge des queues+tentatives réitérées) pour cette merveilleuse solution qui n'en est pas vraiment une. :-/
Le greylisting est efficace envers tout ce qui n'est pas un vrai MTA, ce dont font partie les milliers (millions ?) de zombies d'où émane la grande majorité du spam qui circule de nos jours.
Ben ouais, de nos jours. Tout est là. Pour pondérer, il semble que ce soit au mieux un palliatif de fortune, mais on va pas se précipiter pour présenter ça comme une solution miracle, s'pas ? ;)
Comment en est-on arrivé là ? Par l'usage des RBL et certaines blacklists qui ont fini par avoir un impact sur les ISP les plus "spammer friendly" de sorte que leur "clients" devinrent trop encombrants pour le business.
Il ne restait plus qu'a exploiter l'immense server farm que représentent toutes ces babasses trouables à souhait, les worms et autres virus les transformant en zombies ont rapidement fait leur apparition.
Ah, ça m'a l'air plus intéressant de bosser de ce côté là. C'est un peu plus pérenne, comme solution. Surtout lorsqu'il s'agit d'un serveur de ton voisinage immédiat.
Ce sont ces machines que le greylisting combat, pas les MTAs qui remettent du courrier en principe légitime.
Voir le résultat: http://www.phys.ualberta.ca/~jmack/grey/
'verrai ça plus tard. Merci. 'vais m'coucher. [yawn]
-- tchelaviek
Salut, Cyril Guibourg. Tu as écrit:
Je suis un peu moins pessimiste. Je pense que le greylisting a de beaux
jours devant lui.
Ah, nonnon. C'est pas du pessimisme. C'est juste le triste constat de
devoir céder encore un peu de terrain (délai+surcharge des
queues+tentatives réitérées) pour cette merveilleuse solution qui n'en
est pas vraiment une. :-/
Le greylisting est efficace envers tout ce qui n'est pas un vrai MTA,
ce dont font partie les milliers (millions ?) de zombies d'où émane la
grande majorité du spam qui circule de nos jours.
Ben ouais, de nos jours. Tout est là. Pour pondérer, il semble que ce
soit au mieux un palliatif de fortune, mais on va pas se précipiter pour
présenter ça comme une solution miracle, s'pas ? ;)
Comment en est-on arrivé là ? Par l'usage des RBL et certaines blacklists
qui ont fini par avoir un impact sur les ISP les plus "spammer friendly" de
sorte que leur "clients" devinrent trop encombrants pour le business.
Il ne restait plus qu'a exploiter l'immense server farm que représentent
toutes ces babasses trouables à souhait, les worms et autres virus les
transformant en zombies ont rapidement fait leur apparition.
Ah, ça m'a l'air plus intéressant de bosser de ce côté là. C'est un peu
plus pérenne, comme solution. Surtout lorsqu'il s'agit d'un serveur de
ton voisinage immédiat.
Ce sont
ces machines que le greylisting combat, pas les MTAs qui remettent du
courrier en principe légitime.
Voir le résultat: http://www.phys.ualberta.ca/~jmack/grey/
'verrai ça plus tard. Merci. 'vais m'coucher.
[yawn]
Je suis un peu moins pessimiste. Je pense que le greylisting a de beaux jours devant lui.
Ah, nonnon. C'est pas du pessimisme. C'est juste le triste constat de devoir céder encore un peu de terrain (délai+surcharge des queues+tentatives réitérées) pour cette merveilleuse solution qui n'en est pas vraiment une. :-/
Le greylisting est efficace envers tout ce qui n'est pas un vrai MTA, ce dont font partie les milliers (millions ?) de zombies d'où émane la grande majorité du spam qui circule de nos jours.
Ben ouais, de nos jours. Tout est là. Pour pondérer, il semble que ce soit au mieux un palliatif de fortune, mais on va pas se précipiter pour présenter ça comme une solution miracle, s'pas ? ;)
Comment en est-on arrivé là ? Par l'usage des RBL et certaines blacklists qui ont fini par avoir un impact sur les ISP les plus "spammer friendly" de sorte que leur "clients" devinrent trop encombrants pour le business.
Il ne restait plus qu'a exploiter l'immense server farm que représentent toutes ces babasses trouables à souhait, les worms et autres virus les transformant en zombies ont rapidement fait leur apparition.
Ah, ça m'a l'air plus intéressant de bosser de ce côté là. C'est un peu plus pérenne, comme solution. Surtout lorsqu'il s'agit d'un serveur de ton voisinage immédiat.
Ce sont ces machines que le greylisting combat, pas les MTAs qui remettent du courrier en principe légitime.
Voir le résultat: http://www.phys.ualberta.ca/~jmack/grey/
'verrai ça plus tard. Merci. 'vais m'coucher. [yawn]
