Thierry Boudet wrote: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.
Et si on a plusieurs MX pour un domaine, comment ça se passe ?
Une première précision : les MX indiquent les serveurs smtp *entrants*
(vers
lesquels on envoit les emails). Ca n'a aucune importance pour le
greylisting. Rien n'oblige à ce que ce soit les mêmes serveurs smtp qui
recoivent et qui emettent le courrier.
Néanmoins le problème que tu soulève se pose effectivement dans le cas de
ferme de serveurs, où un serveur peut ré-emettre le courrier qu'un autre
serveur n'a pu envoyer.
La solution consiste à whitelister ces serveurs (au fur et a mesure la
liste commence à être connue). Certains filtres de greylisting permettent
dans les listes de spécifier une notation CIDR, la plupart du temps ces
serveurs se partageant une plage d'adresse facile à écrire sous cette
forme.
Cette façon de raisonner est fausse (si j'ai bien compris tous les mots).
Eric
Thierry Boudet wrote:
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.
Et si on a plusieurs MX pour un domaine, comment ça se passe ?
Une première précision : les MX indiquent les serveurs smtp *entrants*
(vers
lesquels on envoit les emails). Ca n'a aucune importance pour le
greylisting. Rien n'oblige à ce que ce soit les mêmes serveurs smtp qui
recoivent et qui emettent le courrier.
Néanmoins le problème que tu soulève se pose effectivement dans le cas de
ferme de serveurs, où un serveur peut ré-emettre le courrier qu'un autre
serveur n'a pu envoyer.
La solution consiste à whitelister ces serveurs (au fur et a mesure la
liste commence à être connue). Certains filtres de greylisting permettent
dans les listes de spécifier une notation CIDR, la plupart du temps ces
serveurs se partageant une plage d'adresse facile à écrire sous cette
forme.
Cette façon de raisonner est fausse (si j'ai bien compris tous les mots).
Eric
Thierry Boudet wrote: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.
Et si on a plusieurs MX pour un domaine, comment ça se passe ?
Une première précision : les MX indiquent les serveurs smtp *entrants*
(vers
lesquels on envoit les emails). Ca n'a aucune importance pour le
greylisting. Rien n'oblige à ce que ce soit les mêmes serveurs smtp qui
recoivent et qui emettent le courrier.
Néanmoins le problème que tu soulève se pose effectivement dans le cas de
ferme de serveurs, où un serveur peut ré-emettre le courrier qu'un autre
serveur n'a pu envoyer.
La solution consiste à whitelister ces serveurs (au fur et a mesure la
liste commence à être connue). Certains filtres de greylisting permettent
dans les listes de spécifier une notation CIDR, la plupart du temps ces
serveurs se partageant une plage d'adresse facile à écrire sous cette
forme.
Cette façon de raisonner est fausse (si j'ai bien compris tous les mots).
Eric
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 :
Merci Erwan, j'avais les doigts fatigués.
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.
Oui, ou un compteur qui s'incrémente à chaque activation du triplet.
db
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 :
Merci Erwan, j'avais les doigts fatigués.
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.
Oui, ou un compteur qui s'incrémente à chaque activation du triplet.
db
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 :
Merci Erwan, j'avais les doigts fatigués.
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.
Oui, ou un compteur qui s'incrémente à chaque activation du triplet.
db
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.
ET tout cela remonte à une discussion d'il y a 2 ans sur la mailing-list de
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.
ET tout cela remonte à une discussion d'il y a 2 ans sur la mailing-list de
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.
ET tout cela remonte à une discussion d'il y a 2 ans sur la mailing-list de
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
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.
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.
tchelaviek writes: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.
Je suis un peu moins pessimiste. Je pense que le greylisting a de beaux
jours devant lui.
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.
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. 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/
En admettant que les spammers trouvent la parade au greylisting quelle
serait-elle ? En l'état actuel des protocoles il faudrait que les spammers
utilisent de vrais MTAs ce qui,quelque part, nous ramène à la case départ
ou bien de les installer sur les zombies. Je ne suis pas sûr que ce soit
actuellement viable.
Le greylisting combat le spam sur ce qui est son moteur : le fric.
Je suis peut être réveur... j'ai aussi de l'espoir avec des outils à venir
qui fonctionnent sur un modèle distribué.
En attendant, le problème c'est que ce sont les victimes du spam qui
supportent une grande partie du coût de ce fléau. J'ai récemment lu dans
comp.mail.sendmail quelqu'un qui expliquait recevoir environ 3 millions de
mails par jour pour en retenir quelques centaines de milliers. Cette
personne a décrit les systèmes pour tenir la charge: cluster de grosses
babasses quadri-processeurs, licence brightmail, etc, ouch...
tchelaviek <tchelaviek@mamousse.invalid> writes:
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.
Je suis un peu moins pessimiste. Je pense que le greylisting a de beaux
jours devant lui.
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.
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. 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/
En admettant que les spammers trouvent la parade au greylisting quelle
serait-elle ? En l'état actuel des protocoles il faudrait que les spammers
utilisent de vrais MTAs ce qui,quelque part, nous ramène à la case départ
ou bien de les installer sur les zombies. Je ne suis pas sûr que ce soit
actuellement viable.
Le greylisting combat le spam sur ce qui est son moteur : le fric.
Je suis peut être réveur... j'ai aussi de l'espoir avec des outils à venir
qui fonctionnent sur un modèle distribué.
En attendant, le problème c'est que ce sont les victimes du spam qui
supportent une grande partie du coût de ce fléau. J'ai récemment lu dans
comp.mail.sendmail quelqu'un qui expliquait recevoir environ 3 millions de
mails par jour pour en retenir quelques centaines de milliers. Cette
personne a décrit les systèmes pour tenir la charge: cluster de grosses
babasses quadri-processeurs, licence brightmail, etc, ouch...
tchelaviek writes: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.
Je suis un peu moins pessimiste. Je pense que le greylisting a de beaux
jours devant lui.
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.
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. 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/
En admettant que les spammers trouvent la parade au greylisting quelle
serait-elle ? En l'état actuel des protocoles il faudrait que les spammers
utilisent de vrais MTAs ce qui,quelque part, nous ramène à la case départ
ou bien de les installer sur les zombies. Je ne suis pas sûr que ce soit
actuellement viable.
Le greylisting combat le spam sur ce qui est son moteur : le fric.
Je suis peut être réveur... j'ai aussi de l'espoir avec des outils à venir
qui fonctionnent sur un modèle distribué.
En attendant, le problème c'est que ce sont les victimes du spam qui
supportent une grande partie du coût de ce fléau. J'ai récemment lu dans
comp.mail.sendmail quelqu'un qui expliquait recevoir environ 3 millions de
mails par jour pour en retenir quelques centaines de milliers. Cette
personne a décrit les systèmes pour tenir la charge: cluster de grosses
babasses quadri-processeurs, licence brightmail, etc, ouch...
Pourquoi la Chine ou la Corée (du sud) ? La quasi totalité du spam est
américaine !
Pourquoi la Chine ou la Corée (du sud) ? La quasi totalité du spam est
américaine !
Pourquoi la Chine ou la Corée (du sud) ? La quasi totalité du spam est
américaine !
pour recevoir le code 45x et le traiter encore faudrait-il que la machine
piratée soit raccordée directement au Net (et non au travers d'un
firewall).
pour recevoir le code 45x et le traiter encore faudrait-il que la machine
piratée soit raccordée directement au Net (et non au travers d'un
firewall).
pour recevoir le code 45x et le traiter encore faudrait-il que la machine
piratée soit raccordée directement au Net (et non au travers d'un
firewall).
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!
Lequel? On ne touche pas au courrier.
http://projects.puremagic.com/greylisting/
J'ai déjà donné http://greylisting.org/ et il doit me manquer un post
Pardon, c'est moi qui n'avais pas vu le tien.
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?
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 [snip]
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!
Lequel? On ne touche pas au courrier.
http://projects.puremagic.com/greylisting/
J'ai déjà donné http://greylisting.org/ et il doit me manquer un post
Pardon, c'est moi qui n'avais pas vu le tien.
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?
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 [snip]
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!
Lequel? On ne touche pas au courrier.
http://projects.puremagic.com/greylisting/
J'ai déjà donné http://greylisting.org/ et il doit me manquer un post
Pardon, c'est moi qui n'avais pas vu le tien.
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?
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 [snip]
Sauf que SPF casse le relayage des mails.
Sauf que SPF casse le relayage des mails.
Sauf que SPF casse le relayage des mails.
