Tant qu'on y est à taper sur les spammeurs et cyberchieurs, je propose de ne pas oublier les antivirus qui me bombardent d'alertes pour les messages que je n'ai pas envoyés.
C'est ce qui est bien avec les filtres bayesiens : même ces emails-là sont reconnus comme du spam et automatiquement filtrés.
-- schtroumpf schtroumpf
On 26 Jun 2004 10:06:14 GMT, Michel Arboi <arboi@alussinan.org>:
Tant qu'on y est à taper sur les spammeurs et cyberchieurs, je propose
de ne pas oublier les antivirus qui me bombardent d'alertes pour les
messages que je n'ai pas envoyés.
C'est ce qui est bien avec les filtres bayesiens : même ces emails-là
sont reconnus comme du spam et automatiquement filtrés.
Tant qu'on y est à taper sur les spammeurs et cyberchieurs, je propose de ne pas oublier les antivirus qui me bombardent d'alertes pour les messages que je n'ai pas envoyés.
C'est ce qui est bien avec les filtres bayesiens : même ces emails-là sont reconnus comme du spam et automatiquement filtrés.
-- schtroumpf schtroumpf
Eric Razny
tchelaviek wrote:
Dans ces cas seul le _premier_ email est retardé[1].
C'est bête, ça. Pour un premier contact...
Il ne faut pas abuser non plus. A moins de compter le delai en dizaines d'heures ce n'est pas, généralement une gêne. De plus tu peux très bien whitelister une adresse de réception (ton adresse email) spéciale pour les cas particulier (exceptionnellement envoyez votre email à...).
Enfin en période de forte charge virale on voit de temps à autre des FAI mettre bien plus qu'une heure pour délivrer un email!
Et j'te raconte même pas la tchoutchouka sur le plan législatif.
Lequel? On ne touche pas au courrier. Maintenant si tu veux que La Poste (snail mail) se prenne un procès pour chaque courrier qui n'arrive pas à jour+1, ça risque de ne pas être triste!
J'sais même pas si les instances légiférantes ont abordé le délai d'acheminement. Mais là, tu tapes en plein dedans. Youpi.
Ben non. Aucun problème (regarde accessoirement ce qu'indiquent tous les prestataires concernant les défaillance du réseau)
Mais je ne relève pas de non-conformité flagrante avec la RFC 821.
Au contraire de l'application brutale d'un système type SPF qui ne respecte pas les RFC, le greylisting ne fait qu'utiliser de façon (amha) astucieuse[1] les fonctionnalités de gestion de problème temporaire (erreur 4xx).
Le problème est que certains connards on pondu des MTA qui ne respectent pas les RFCs et ne retentent pas les envois (d'où l'utilité des whitelists)
Pour l'instant je ne me sers même pas de ça, mon délai est d'à peine 5mn!!!
Pour l'instant, 5mn. Demain, ben, je serais content d'avoir tord.
Même deux heures (largement suffisant pour que les RBLs réagissent) ne posent pas de problème (voir au dessus pour les emails urgentissimes)
Alors que 100% de la métropole sera bientôt couverte en haut débit,
Vient dire ça aux gens de mon village de 3500 habitants le long d'une route nationale qui n'ont que le RTC! Pour revenir complètement en charte la généralisation de l'adsl sans protections des bécanes derrière augurent effectivement du pire (ce qui me surprend d'ailleurs c'est que ce pire n'ait pas déjà eu lieu)!
Tu relèves ta boîte à spam tous les combien, toi, déjà ? Toutes les semaines, c'est ça ?
Tous les jours! Avec plusieurs adresses publiques (news, emails poubelle fournis en enregistrement, newsletters) je ne dépasse pas 10 ou 20 mails vérolés par jours en cas de période de -grosse- pointe (généralement _beaucoup_ moins). Pourquoi crois-tu que je sois si content du greylisting? Je l'ai d'ailleurs mis en place pour un client qui ne pouvais plus travailler vu le nombre de spam/viruses qu'il se prennait (Bien entendu je lui aussi expliqué qu'il fallait qu'il arrête de faire l'andouille dans la diffusion de ses adresses pro).
Grâce à Cyril, on a au moins l'URL que Guillermito a réclamée : http://projects.puremagic.com/greylisting/
J'ai déjà donné http://greylisting.org/ et il doit me manquer un post car j'ai vu Cyril donner : http://www.phys.ualberta.ca/~jmack/grey/ (qui devrait d'ailleurs en convaincre plus d'un d'au moins tenter la manoeuvre)
C'est récent: "During the initial testing of Greylisting in mid-2003"
Depuis quand une idée ne devrait pas être utilisée parce qu'elle est récente? Dans ce domaine si tu attends 5 ans pour la mettre en oeuvre elle aura déjà été contournée et sera obsolète.
Oki. Mais chhtt, faut pas l'dire pour qu'ça dure!
Je ne crois pas. La seule solution pour les spammeurs et d'utiliser de vrai MTA et les RBLs vont prendre le relay pendant la période d'attente. Mon soucis est surtout de voir de moins en moins de RBL clean (ie qui fonctionnent encore et qui ne bloquent pas tout et n'importe quoi). Enfin je suis personnellement opposé au chacun dans son coin avec sa bonne idée. Je suis un andouille d'idéaliste qui pense qu'on peut avancer plus vite en faisant circuler l'info :) C'est aussi pour ça que je suis contre l'établissement d'une caste (sic) qui aurait seule le droit d'utiliser des outils de sécurité (déjà discuté, assez violement, ici même).
-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] Ah, ouais, j'avais oublié, ça. Une table indexée de plus sur le
serveur. Re-youpi.
Un simple whitelisting, il ne faut pas pousser (et ce n'est pas si fréquent, il faut quand même un "gros" en face ; quand il n'y a que deux ou trois serveurs on va vite retrouver une ip connue -délai un peu plus long c'est tout- et les listes de ces serveurs circulent vite).
Enfin il n'y a pas 36 solutions : soit on pleure sur le fait que l'on est dans un mode cruel qui ne respecte pas toutes les règles qui évitent du boulot au GADD (gentil admin du dimanche) soit on s'adapte. C'est d'ailleurs le cas pour le reste de la sécurité informatique. Pour ma part j'ai choisi : vive l'évolution! :)
Eric
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
tchelaviek wrote:
Dans ces cas seul le
_premier_ email est retardé[1].
C'est bête, ça. Pour un premier contact...
Il ne faut pas abuser non plus. A moins de compter le delai en dizaines
d'heures ce n'est pas, généralement une gêne.
De plus tu peux très bien whitelister une adresse de réception (ton adresse
email) spéciale pour les cas particulier (exceptionnellement envoyez votre
email à...).
Enfin en période de forte charge virale on voit de temps à autre des FAI
mettre bien plus qu'une heure pour délivrer un email!
Et j'te raconte même pas la
tchoutchouka sur le plan législatif.
Lequel? On ne touche pas au courrier. Maintenant si tu veux que La Poste
(snail mail) se prenne un procès pour chaque courrier qui n'arrive pas à
jour+1, ça risque de ne pas être triste!
J'sais même pas si les instances
légiférantes ont abordé le délai d'acheminement. Mais là, tu tapes en
plein dedans. Youpi.
Ben non. Aucun problème (regarde accessoirement ce qu'indiquent tous les
prestataires concernant les défaillance du réseau)
Mais je ne relève pas de non-conformité flagrante avec la RFC 821.
Au contraire de l'application brutale d'un système type SPF qui ne respecte
pas les RFC, le greylisting ne fait qu'utiliser de façon (amha)
astucieuse[1] les fonctionnalités de gestion de problème temporaire (erreur
4xx).
Le problème est que certains connards on pondu des MTA qui ne respectent pas
les RFCs et ne retentent pas les envois (d'où l'utilité des whitelists)
Pour l'instant je ne me sers même pas de ça,
mon délai est d'à peine 5mn!!!
Pour l'instant, 5mn. Demain, ben, je serais content d'avoir tord.
Même deux heures (largement suffisant pour que les RBLs réagissent) ne
posent pas de problème (voir au dessus pour les emails urgentissimes)
Alors que 100% de la métropole sera bientôt couverte en haut débit,
Vient dire ça aux gens de mon village de 3500 habitants le long d'une route
nationale qui n'ont que le RTC!
Pour revenir complètement en charte la généralisation de l'adsl sans
protections des bécanes derrière augurent effectivement du pire (ce qui me
surprend d'ailleurs c'est que ce pire n'ait pas déjà eu lieu)!
Tu relèves ta boîte à spam tous les combien, toi, déjà ? Toutes les
semaines, c'est ça ?
Tous les jours! Avec plusieurs adresses publiques (news, emails poubelle
fournis en enregistrement, newsletters) je ne dépasse pas 10 ou 20 mails
vérolés par jours en cas de période de -grosse- pointe (généralement
_beaucoup_ moins). Pourquoi crois-tu que je sois si content du greylisting?
Je l'ai d'ailleurs mis en place pour un client qui ne pouvais plus
travailler vu le nombre de spam/viruses qu'il se prennait (Bien entendu je
lui aussi expliqué qu'il fallait qu'il arrête de faire l'andouille dans la
diffusion de ses adresses pro).
Grâce à Cyril, on a au moins l'URL que Guillermito a réclamée :
http://projects.puremagic.com/greylisting/
J'ai déjà donné http://greylisting.org/ et il doit me manquer un post car
j'ai vu Cyril donner :
http://www.phys.ualberta.ca/~jmack/grey/ (qui devrait d'ailleurs en
convaincre plus d'un d'au moins tenter la manoeuvre)
C'est récent:
"During the initial testing of Greylisting in mid-2003"
Depuis quand une idée ne devrait pas être utilisée parce qu'elle est
récente?
Dans ce domaine si tu attends 5 ans pour la mettre en oeuvre elle aura déjà
été contournée et sera obsolète.
Oki. Mais chhtt, faut pas l'dire pour qu'ça dure!
Je ne crois pas. La seule solution pour les spammeurs et d'utiliser de vrai
MTA et les RBLs vont prendre le relay pendant la période d'attente. Mon
soucis est surtout de voir de moins en moins de RBL clean (ie qui
fonctionnent encore et qui ne bloquent pas tout et n'importe quoi). Enfin je
suis personnellement opposé au chacun dans son coin avec sa bonne idée. Je
suis un andouille d'idéaliste qui pense qu'on peut avancer plus vite en
faisant circuler l'info :) C'est aussi pour ça que je suis contre
l'établissement d'une caste (sic) qui aurait seule le droit d'utiliser des
outils de sécurité (déjà discuté, assez violement, ici même).
-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]
Ah, ouais, j'avais oublié, ça. Une table indexée de plus sur le
serveur. Re-youpi.
Un simple whitelisting, il ne faut pas pousser (et ce n'est pas si fréquent,
il faut quand même un "gros" en face ; quand il n'y a que deux ou trois
serveurs on va vite retrouver une ip connue -délai un peu plus long c'est
tout- et les listes de ces serveurs circulent vite).
Enfin il n'y a pas 36 solutions : soit on pleure sur le fait que l'on est
dans un mode cruel qui ne respecte pas toutes les règles qui évitent du
boulot au GADD (gentil admin du dimanche) soit on s'adapte. C'est d'ailleurs
le cas pour le reste de la sécurité informatique. Pour ma part j'ai choisi :
vive l'évolution! :)
Eric
--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.
Dans ces cas seul le _premier_ email est retardé[1].
C'est bête, ça. Pour un premier contact...
Il ne faut pas abuser non plus. A moins de compter le delai en dizaines d'heures ce n'est pas, généralement une gêne. De plus tu peux très bien whitelister une adresse de réception (ton adresse email) spéciale pour les cas particulier (exceptionnellement envoyez votre email à...).
Enfin en période de forte charge virale on voit de temps à autre des FAI mettre bien plus qu'une heure pour délivrer un email!
Et j'te raconte même pas la tchoutchouka sur le plan législatif.
Lequel? On ne touche pas au courrier. Maintenant si tu veux que La Poste (snail mail) se prenne un procès pour chaque courrier qui n'arrive pas à jour+1, ça risque de ne pas être triste!
J'sais même pas si les instances légiférantes ont abordé le délai d'acheminement. Mais là, tu tapes en plein dedans. Youpi.
Ben non. Aucun problème (regarde accessoirement ce qu'indiquent tous les prestataires concernant les défaillance du réseau)
Mais je ne relève pas de non-conformité flagrante avec la RFC 821.
Au contraire de l'application brutale d'un système type SPF qui ne respecte pas les RFC, le greylisting ne fait qu'utiliser de façon (amha) astucieuse[1] les fonctionnalités de gestion de problème temporaire (erreur 4xx).
Le problème est que certains connards on pondu des MTA qui ne respectent pas les RFCs et ne retentent pas les envois (d'où l'utilité des whitelists)
Pour l'instant je ne me sers même pas de ça, mon délai est d'à peine 5mn!!!
Pour l'instant, 5mn. Demain, ben, je serais content d'avoir tord.
Même deux heures (largement suffisant pour que les RBLs réagissent) ne posent pas de problème (voir au dessus pour les emails urgentissimes)
Alors que 100% de la métropole sera bientôt couverte en haut débit,
Vient dire ça aux gens de mon village de 3500 habitants le long d'une route nationale qui n'ont que le RTC! Pour revenir complètement en charte la généralisation de l'adsl sans protections des bécanes derrière augurent effectivement du pire (ce qui me surprend d'ailleurs c'est que ce pire n'ait pas déjà eu lieu)!
Tu relèves ta boîte à spam tous les combien, toi, déjà ? Toutes les semaines, c'est ça ?
Tous les jours! Avec plusieurs adresses publiques (news, emails poubelle fournis en enregistrement, newsletters) je ne dépasse pas 10 ou 20 mails vérolés par jours en cas de période de -grosse- pointe (généralement _beaucoup_ moins). Pourquoi crois-tu que je sois si content du greylisting? Je l'ai d'ailleurs mis en place pour un client qui ne pouvais plus travailler vu le nombre de spam/viruses qu'il se prennait (Bien entendu je lui aussi expliqué qu'il fallait qu'il arrête de faire l'andouille dans la diffusion de ses adresses pro).
Grâce à Cyril, on a au moins l'URL que Guillermito a réclamée : http://projects.puremagic.com/greylisting/
J'ai déjà donné http://greylisting.org/ et il doit me manquer un post car j'ai vu Cyril donner : http://www.phys.ualberta.ca/~jmack/grey/ (qui devrait d'ailleurs en convaincre plus d'un d'au moins tenter la manoeuvre)
C'est récent: "During the initial testing of Greylisting in mid-2003"
Depuis quand une idée ne devrait pas être utilisée parce qu'elle est récente? Dans ce domaine si tu attends 5 ans pour la mettre en oeuvre elle aura déjà été contournée et sera obsolète.
Oki. Mais chhtt, faut pas l'dire pour qu'ça dure!
Je ne crois pas. La seule solution pour les spammeurs et d'utiliser de vrai MTA et les RBLs vont prendre le relay pendant la période d'attente. Mon soucis est surtout de voir de moins en moins de RBL clean (ie qui fonctionnent encore et qui ne bloquent pas tout et n'importe quoi). Enfin je suis personnellement opposé au chacun dans son coin avec sa bonne idée. Je suis un andouille d'idéaliste qui pense qu'on peut avancer plus vite en faisant circuler l'info :) C'est aussi pour ça que je suis contre l'établissement d'une caste (sic) qui aurait seule le droit d'utiliser des outils de sécurité (déjà discuté, assez violement, ici même).
-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] Ah, ouais, j'avais oublié, ça. Une table indexée de plus sur le
serveur. Re-youpi.
Un simple whitelisting, il ne faut pas pousser (et ce n'est pas si fréquent, il faut quand même un "gros" en face ; quand il n'y a que deux ou trois serveurs on va vite retrouver une ip connue -délai un peu plus long c'est tout- et les listes de ces serveurs circulent vite).
Enfin il n'y a pas 36 solutions : soit on pleure sur le fait que l'on est dans un mode cruel qui ne respecte pas toutes les règles qui évitent du boulot au GADD (gentil admin du dimanche) soit on s'adapte. C'est d'ailleurs le cas pour le reste de la sécurité informatique. Pour ma part j'ai choisi : vive l'évolution! :)
Eric
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Xavier Roche
Michel Arboi wrote:
Ça existe en Chine, par exemple.
Pas grave. On peut blacklister plus large dans ce coin là.
Tolérables pour de gros domaines très spammés, mais navrant dans les autres cas, quand les spammeurs se seront adaptés.
Non. Les seuls cas restants seront les plages "bulletproof" qu'il suffira alors de nullrouter. Quand une partie de la Chine et la Corée seront débranchés, il y aura peut être une réaction (ou pas, mais de toute manière on ne les verra plus). Quoi qu'il en soit les blacklist classiques (RBL) seront le coup de grâce.
Michel Arboi wrote:
Ça existe en Chine, par exemple.
Pas grave. On peut blacklister plus large dans ce coin là.
Tolérables pour de gros domaines très spammés, mais navrant dans les
autres cas, quand les spammeurs se seront adaptés.
Non. Les seuls cas restants seront les plages "bulletproof" qu'il
suffira alors de nullrouter. Quand une partie de la Chine et la Corée
seront débranchés, il y aura peut être une réaction (ou pas, mais de
toute manière on ne les verra plus). Quoi qu'il en soit les blacklist
classiques (RBL) seront le coup de grâce.
Pas grave. On peut blacklister plus large dans ce coin là.
Tolérables pour de gros domaines très spammés, mais navrant dans les autres cas, quand les spammeurs se seront adaptés.
Non. Les seuls cas restants seront les plages "bulletproof" qu'il suffira alors de nullrouter. Quand une partie de la Chine et la Corée seront débranchés, il y aura peut être une réaction (ou pas, mais de toute manière on ne les verra plus). Quoi qu'il en soit les blacklist classiques (RBL) seront le coup de grâce.
Xavier Roche
Eric Razny wrote:
listes de spécifier une notation CIDR, la plupart du temps ces serveurs se partageant une plage d'adresse facile à écrire sous cette forme.
On peut aussi assigner le triplet (from, to, IP/24) pour tous les mails entrants. Ou encore (from, to, suffixe-du-reverse-dns) (si pas de reverse, revenir à IP/24)
Eric Razny wrote:
listes de spécifier une notation CIDR, la plupart du temps ces serveurs se
partageant une plage d'adresse facile à écrire sous cette forme.
On peut aussi assigner le triplet (from, to, IP/24) pour tous les mails
entrants. Ou encore (from, to, suffixe-du-reverse-dns) (si pas de reverse,
revenir à IP/24)
listes de spécifier une notation CIDR, la plupart du temps ces serveurs se partageant une plage d'adresse facile à écrire sous cette forme.
On peut aussi assigner le triplet (from, to, IP/24) pour tous les mails entrants. Ou encore (from, to, suffixe-du-reverse-dns) (si pas de reverse, revenir à IP/24)
Eric Razny
Fabien LE LEZ wrote:
C'est ce qui est bien avec les filtres bayesiens : même ces emails-là sont reconnus comme du spam et automatiquement filtrés.
Le mieux c'est quand même ne pas arriver jusqu'à cette étape, quand c'est facile à mettre en oeuvre : ça veut dire que l'email est passé et la BP gachée.
Eric
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Fabien LE LEZ wrote:
C'est ce qui est bien avec les filtres bayesiens : même ces emails-là
sont reconnus comme du spam et automatiquement filtrés.
Le mieux c'est quand même ne pas arriver jusqu'à cette étape, quand c'est
facile à mettre en oeuvre : ça veut dire que l'email est passé et la BP
gachée.
Eric
--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.
C'est ce qui est bien avec les filtres bayesiens : même ces emails-là sont reconnus comme du spam et automatiquement filtrés.
Le mieux c'est quand même ne pas arriver jusqu'à cette étape, quand c'est facile à mettre en oeuvre : ça veut dire que l'email est passé et la BP gachée.
Eric
-- L'invulnérable : Je ne pense pas etre piratable, infectable par un trojen oui! Vu sur fcs un jour de mars 2004.
Benjamin Pineau
Le 25 Jun 2004 18:09:08 GMT, tchelaviek écrivais:
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.
Mais comme le fait remarquer Evan Harris « The possible methods of adaptation may make Greylisting by itself less effective, but the ways of getting around it will only make other spamblocking methods more effective » et ça c'est rigolo.
Le problème des pools de mtas (quand les mtas qui se présentent succesivement pour le même message rejetté peuvent varier) me semble en revanche un bon candidat au titre de second inconvénient ;)
Le 25 Jun 2004 18:09:08 GMT,
tchelaviek <tchelaviek@mamousse.invalid> écrivais:
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.
Mais comme le fait remarquer Evan Harris
« The possible methods of adaptation may make Greylisting by itself less
effective, but the ways of getting around it will only make other
spamblocking methods more effective » et ça c'est rigolo.
Le problème des pools de mtas (quand les mtas qui se présentent
succesivement pour le même message rejetté peuvent varier) me semble en
revanche un bon candidat au titre de second inconvénient ;)
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.
Mais comme le fait remarquer Evan Harris « The possible methods of adaptation may make Greylisting by itself less effective, but the ways of getting around it will only make other spamblocking methods more effective » et ça c'est rigolo.
Le problème des pools de mtas (quand les mtas qui se présentent succesivement pour le même message rejetté peuvent varier) me semble en revanche un bon candidat au titre de second inconvénient ;)
Benjamin Pineau
Le 25 Jun 2004 18:07:43 GMT, Alain Montfranc écrivais:
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)
Je ne pense pas que ça soit possible avec spamassassin, étant donné que le filtrage doit être fait avant que le MTA accépte de délivrer le message (peut-être avec un spamass bien intégré via milter ? à voir). Sinon http://hcpnet.free.fr/milter-greylist/ marche très bien, et avec un spamass en complément, le résultat est assez bon.
Le 25 Jun 2004 18:07:43 GMT,
Alain Montfranc <alain-news@montfranc.com> écrivais:
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)
Je ne pense pas que ça soit possible avec spamassassin, étant donné que
le filtrage doit être fait avant que le MTA accépte de délivrer le
message (peut-être avec un spamass bien intégré via milter ? à voir).
Sinon http://hcpnet.free.fr/milter-greylist/ marche très bien, et avec
un spamass en complément, le résultat est assez bon.
Le 25 Jun 2004 18:07:43 GMT, Alain Montfranc écrivais:
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)
Je ne pense pas que ça soit possible avec spamassassin, étant donné que le filtrage doit être fait avant que le MTA accépte de délivrer le message (peut-être avec un spamass bien intégré via milter ? à voir). Sinon http://hcpnet.free.fr/milter-greylist/ marche très bien, et avec un spamass en complément, le résultat est assez bon.
Benjamin Pineau
Le 25 Jun 2004 11:33:16 GMT, Rico.101 écrivais:
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur, indépendant du logiciel de messagerie.
Tout dépend de ce que tu appelle « tri sur le serveur ». Si tu administre toi même le serveur en question, les greylists sont très bien (cf le reste du fil), mais inutilisables le cas échéant. Si tu entend par là: ne pas rapatrier les fichiers sur le serveur pop3/imap (donc un filtre basé sur le tamisage des headers avec des regexps ) ... c'est une autre affaire (et amha un tel outil ne permetra pas un filtrage vraiment efficace à lui seul: le complémenter d'un soft filtrant sur le contenu complet du message comme spamassassin et/ou bogofilter).
Le 25 Jun 2004 11:33:16 GMT,
Rico.101 <rico_depeche_stop_le_s.p.a.m@yahoo.fr> écrivais:
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur,
indépendant du logiciel de messagerie.
Tout dépend de ce que tu appelle « tri sur le serveur ». Si tu administre
toi même le serveur en question, les greylists sont très bien (cf le
reste du fil), mais inutilisables le cas échéant. Si tu entend par là:
ne pas rapatrier les fichiers sur le serveur pop3/imap (donc un filtre
basé sur le tamisage des headers avec des regexps ) ... c'est une
autre affaire (et amha un tel outil ne permetra pas un filtrage vraiment
efficace à lui seul: le complémenter d'un soft filtrant sur le contenu
complet du message comme spamassassin et/ou bogofilter).
Quel logiciel utilisez-vous pour faire un tri préalable sur le serveur, indépendant du logiciel de messagerie.
Tout dépend de ce que tu appelle « tri sur le serveur ». Si tu administre toi même le serveur en question, les greylists sont très bien (cf le reste du fil), mais inutilisables le cas échéant. Si tu entend par là: ne pas rapatrier les fichiers sur le serveur pop3/imap (donc un filtre basé sur le tamisage des headers avec des regexps ) ... c'est une autre affaire (et amha un tel outil ne permetra pas un filtrage vraiment efficace à lui seul: le complémenter d'un soft filtrant sur le contenu complet du message comme spamassassin et/ou bogofilter).
Benjamin Pineau
Le 26 Jun 2004 01:47:48 GMT, tchelaviek écrivais:
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 ? ;)
Si un grand nombre d'admins mettent un fitrage par greylist en place au point que les spammers veuillent contourner ce procédé, le coût d'envoi des spams augmentera considérablement (puisque les spammers devront conserver les messages en queue et reitérer les tentatives) et augmenter l'efficacité des autres méthodes (surtout les rbls).
Pas une solution miracle, mais un effort collectif donc.
Dans le même esprit on peut utiliser le spamd d'OpenBSD (porté sur FreeBSD aussi et peut être ailleur ?) qui en plus du greylising sait faire du « tarpetting » sur les mta blacklistés. Au lieu de rejetter le mail immédiatement, il fait lamentablement trainer la session afin de coûter le plus cher possible au spammer.
Si les gros mta étaient équipés de ce genre de choses, les admins de relais ouverts réagiraient bien plus vite, et les softs de spams tentant de contourner les greylists en gérant eux mêmes leurs queues et en causant directement aux mta de destination seraient inutilisables (au boût de quelques miliers de connexions ouvertes simultanément et avec des miliers de messages bloqués en queue ...).
Le tout est de faire en sorte que l'envoi de spam coûte suffisament cher aux admins indigents pour qu'ils reconfigurent leurs mtas, aux spammers pour que cette pratique ne soit plus suffisament rentable.
Le 26 Jun 2004 01:47:48 GMT,
tchelaviek <tchelaviek@mamousse.invalid> écrivais:
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 ? ;)
Si un grand nombre d'admins mettent un fitrage par greylist en place au
point que les spammers veuillent contourner ce procédé, le coût d'envoi
des spams augmentera considérablement (puisque les spammers devront
conserver les messages en queue et reitérer les tentatives) et augmenter
l'efficacité des autres méthodes (surtout les rbls).
Pas une solution miracle, mais un effort collectif donc.
Dans le même esprit on peut utiliser le spamd d'OpenBSD (porté sur
FreeBSD aussi et peut être ailleur ?) qui en plus du greylising sait faire
du « tarpetting » sur les mta blacklistés.
Au lieu de rejetter le mail immédiatement, il fait lamentablement trainer
la session afin de coûter le plus cher possible au spammer.
Si les gros mta étaient équipés de ce genre de choses, les admins de relais
ouverts réagiraient bien plus vite, et les softs de spams tentant de
contourner les greylists en gérant eux mêmes leurs queues et en causant
directement aux mta de destination seraient inutilisables (au boût de
quelques miliers de connexions ouvertes simultanément et avec des
miliers de messages bloqués en queue ...).
Le tout est de faire en sorte que l'envoi de spam coûte suffisament cher
aux admins indigents pour qu'ils reconfigurent leurs mtas, aux spammers
pour que cette pratique ne soit plus suffisament rentable.
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 ? ;)
Si un grand nombre d'admins mettent un fitrage par greylist en place au point que les spammers veuillent contourner ce procédé, le coût d'envoi des spams augmentera considérablement (puisque les spammers devront conserver les messages en queue et reitérer les tentatives) et augmenter l'efficacité des autres méthodes (surtout les rbls).
Pas une solution miracle, mais un effort collectif donc.
Dans le même esprit on peut utiliser le spamd d'OpenBSD (porté sur FreeBSD aussi et peut être ailleur ?) qui en plus du greylising sait faire du « tarpetting » sur les mta blacklistés. Au lieu de rejetter le mail immédiatement, il fait lamentablement trainer la session afin de coûter le plus cher possible au spammer.
Si les gros mta étaient équipés de ce genre de choses, les admins de relais ouverts réagiraient bien plus vite, et les softs de spams tentant de contourner les greylists en gérant eux mêmes leurs queues et en causant directement aux mta de destination seraient inutilisables (au boût de quelques miliers de connexions ouvertes simultanément et avec des miliers de messages bloqués en queue ...).
Le tout est de faire en sorte que l'envoi de spam coûte suffisament cher aux admins indigents pour qu'ils reconfigurent leurs mtas, aux spammers pour que cette pratique ne soit plus suffisament rentable.
JustMe
Benjamin Pineau wrote:
Le 25 Jun 2004 18:07:43 GMT, Alain Montfranc écrivais:
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)
Je ne pense pas que ça soit possible avec spamassassin, étant donné que le filtrage doit être fait avant que le MTA accépte de délivrer le message (peut-être avec un spamass bien intégré via milter ? à voir). Sinon http://hcpnet.free.fr/milter-greylist/ marche très bien, et avec un spamass en complément, le résultat est assez bon.
Ca y est, ca marche : j'ai installé milter-greylist de E. Dreyfus
tip top
(faut juste lancer milter-greylist avant sendmail ce qui n'est pas clair dans la doc)
Benjamin Pineau wrote:
Le 25 Jun 2004 18:07:43 GMT,
Alain Montfranc <alain-news@montfranc.com> écrivais:
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)
Je ne pense pas que ça soit possible avec spamassassin, étant donné que
le filtrage doit être fait avant que le MTA accépte de délivrer le
message (peut-être avec un spamass bien intégré via milter ? à voir).
Sinon http://hcpnet.free.fr/milter-greylist/ marche très bien, et avec
un spamass en complément, le résultat est assez bon.
Ca y est, ca marche : j'ai installé milter-greylist de E. Dreyfus
tip top
(faut juste lancer milter-greylist avant sendmail ce qui n'est pas clair
dans la doc)
Le 25 Jun 2004 18:07:43 GMT, Alain Montfranc écrivais:
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)
Je ne pense pas que ça soit possible avec spamassassin, étant donné que le filtrage doit être fait avant que le MTA accépte de délivrer le message (peut-être avec un spamass bien intégré via milter ? à voir). Sinon http://hcpnet.free.fr/milter-greylist/ marche très bien, et avec un spamass en complément, le résultat est assez bon.
Ca y est, ca marche : j'ai installé milter-greylist de E. Dreyfus
tip top
(faut juste lancer milter-greylist avant sendmail ce qui n'est pas clair dans la doc)
