Blacklist de spammers

db wrote:

Eric Razny wrote:

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

Beuh? j'avais essayé d'être lisible... qui a dit pour une fois? :-)

Whitelister ne fera que donner du crédit à un serveur de
déport qui va rebalancer

Ben non. Dans le cas d'une ferme de serveur tous les serveurs sont de "vrai"
MTA, qui doivent normalement passer un greylisting. Le seul problème ici
c'est que l'ip présentée va varier à chaque tentative [1](ou presque)
induisant un retard considérable si le nombre de serveurs est important (et
en supposant quand même le cas de figure le plus défavorable : on se prend
la suite complète ou presque des serveurs dans la tête).

Il me semble que ta façon de qualifier mon raisonnement vient d'une erreur
de perception sur ce qu'est le greylisting :

- le greylisting lutte de façon efficace contre le "fire&forget". C'est le
cas de la majeure partie des spammeurs à l'heure actuelle.
- le greylisting ne _bloque pas_, à terme, un email venant d'un MTA propre,
ie qui retente les emissions sur un code erreur 4xx (la plupart du temps sur
4 à 5 jours).

A partir du moment ou tu connais un "vrai" MTA "légitime" (genre wanadoo,
free etc) autant le whitelister car de toute façon il va finir par
passer[2]. C'est le même raisonnement qui est appliquée aux fermes de
serveur avec des ip différentes présentées en emission smtp.

La notation CIDR est juste une commodité pour éviter d'avoir à placer toutes
les adresses IP concernées quand un x.y.z.t/27 suffit par exemple.

à intervalle régulier (c'est un VRAI MTA) tous les mails non reçus
directement par le serveur << officiel >> et jouer ainsi le rôle de
porte-parole du spammeur.

Si le spammeur passe par un "vrai" MTA "abusif" [3] ou retente simplement
toute sa liste après un intervalle de temps donné le greylisting reste
néanmoins interressant dans le sens où quand le délai sera écoulé il y a
plus de chance que les RBL aient pris efficacement le relai.

Le greylisting ne peut fonctionner efficacement que si TOUS les
serveurs concernés le sont (greylistés). Voir mon mail à ce sujet.

Non, un MTA que tu connais être légitime peut être whitelisté, ça va limiter
le nombre d'enregistement dans ta base (en attente et auto-whitelisted) [4]

Eric

[1] c'est peut être la où il a a eu confusion : ici on reste sur les IP dans
groupe de MTA constitué en ferme. Ca n'a rien à voir avec des successions
d'IP utilisée par les spammeurs (MTAs relay, open proxies etc...)

[2] Je pars de l'hypothèse que tu dois accepter les courriers venant de ce
FAI. En principe tu as déjà du le whitelister pour éviter les gags de
certaines RBL.

[3] dans le sens où je peux me passer d'accepter les email de ce serveur (un
particulier qui à 4 pieds par exemple...)

[4] théoriquement différer un email en provenance d'un inconnu permet entre
temps de prendre d'autres mesures, mais je ne connais rien d'exploitable à
l'heure actuelle.

--
L'invulnérable :
Je ne pense pas etre piratable, infectable par un trojen oui!
Vu sur fcs un jour de mars 2004.

db wrote:

Encore un point important :
TOUS les serveurs assurant l'acheminement du courrier pour un domaine
donné (MX backup) doivent impérativement être
équipés de ce système de liste gris sinon c'est comme p***** dans un violon.

Je ne suis pas completement d'accord. Un MX backup qui renvoie vers le
MX principal lorsque celui ci revient à la vie (cas le plus courant)
permetra quand meme un filtrage sur le couple (source, dest), non ?

Erwan David wrote:

db <nospam@spam.int> écrivait :

Encore un point important :
TOUS les serveurs assurant l'acheminement du courrier pour un domaine
donné (MX backup) doivent impérativement être
équipés de ce système de liste gris sinon c'est comme p***** dans un
violon.

Même pas, mes secondaires n'en ont pas et je vois déjà la différence.

Oui bien sûr mais ce n'est pas 100%, << seulement >> 95%. Mais c'est déjà

bien pour une solution aussi simple.

Ceci fait que le nombre de serveurs concerné diffère d'autant la remise
effective du courrier. Il faudra en effet 2 ^ N - 1 retransmissions dans
le cas le plus défavorable afin que le courrier se retrouve dans la boîte
aux lettres du destinataire. N étant le nombre de serveurs.

Non, car après un 4xx on ne passe pas aux secondaires. Le passage aux
sececondaires c'est uniquement si on n'a pas eu la connexion TCP.

C'est bien ce que je voulais dire. Pour diverses raisons la connexion

directe peut ne pas avoir lieu (ne serait-ce que parce que la machine
principale est en rade [c'est bien pour cela qu'on place des secondaires
non ?], ou plus simplement parce que la machine principale n'accepte que
tant de connexions par seconde et refuse les autres).

db

--
email : usenet blas net

Cyril Guibourg wrote:

db <nospam@spam.int> writes:

Non, il est bien plus simple et moins onéreux de conserver un système
d'expédition sans capacité d'analyse mais expédiant le même message à
plusieurs heures d'intervalle !
Et là, le greylisting est mort.

Il a tout de même de beaux jours devant lui et le jour où les spammers
auront réussi à déployer j'espère qu'on aura réussi à contruire des RBL
dynamiques correlées avec des mécanismes de spam-trap distribués. En fait,
c'est déjà dans les cartons :)

On pourrait encore s'en sortir en n'acceptant non pas la seconde
proposition mais la 3ème ou la 4ème ce qui rallongerait d'autant le temps
d'arrivée du message légitime, la première fois.

Pour un MTA RFC compliant cela ne ferait "que" deux heures pour la 4ieme
Sauf s'il y a des MX seondaires. Avec un seul MX secondaire cela pourrait

monter (cas le plus défavorable [*]) à 5 heures (0,5 x 3 x 2 + 4) (**).

[fu2 fcms]


<remarque mode="Grrrrr!">
Cela ne t'es pas destiné personellement. Je trouve regrettable que ce
thread s'éternise dans fcs alors qu'il hors charte et trouve sa place dans
fcms ou des discussions similaires ont eu lieu et se doivent d'y être.

Je suis entièrement d'accord avec toi mais, postant dans les deux, j'avais

oublié que nous étions dans fcs. Et cette discussion y a déjà eu lieu (dans
fcms).
On le bascule sur fcms ?

Alors la modérature ? Tous à la plage ?
C'est bien connu c'est au mois d'août que le législateur fait passer les

trucs qui ne passerait pas à d'autres périodes.
Un thread dans f.?.complots ?

db
[*] Bien moins probable que le cas le plus défavorable avec un seuil à 2.
(**) Et non à 4 ^ 4 comme je l'ai annoncé dans fcms. Qu'on veuille bien me
pardonner.

</pas taper>

--
email : usenet blas net

Eric Razny wrote:

db wrote:

Eric Razny wrote:

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

Beuh? j'avais essayé d'être lisible... qui a dit pour une fois? :-)

Whitelister ne fera que donner du crédit à un serveur de
déport qui va rebalancer

Ben non. Dans le cas d'une ferme de serveur tous les serveurs sont de
"vrai" MTA, qui doivent normalement passer un greylisting. Le seul
problème ici c'est que l'ip présentée va varier à chaque tentative [1](ou
presque) induisant un retard considérable si le nombre de serveurs est
important (et en supposant quand même le cas de figure le plus défavorable
: on se prend la suite complète ou presque des serveurs dans la tête).

Il me semble que ta façon de qualifier mon raisonnement vient d'une erreur
de perception sur ce qu'est le greylisting :

Je ne pense pas. En revanche mon erreur de perception (d'où ma modulation)

vient du fait que les MTA (que je nomme << concernés >>) sont, dans ton
hypothèse, greylistés par défaut car ils appartiennent à la fameuse ferme
(avec Massimo).

Ce que j'avais compris lorque tu parlais de MTA c'est qu'il s'agissait de
MTA desservant MON domaine pouvant être situés chez un fournisseur. Cela
n'enlève rien à mon affirmation que TOUS les MTA concernés (ceux desservant
mon domaine et donc
récipiendaires de mon MX à une priorité plus faible) doivent être
greylistés. Ca s'impose de soi-même.

Et je pense que c'est là que réside l'incompréhension majeure : les MTA <<
concernés >> sont justement ceux qui supportent le MX de mon domaine pas
n'importe que MTA << propre >>.
Je n'ai pas à Whitelister Wanadoo ou Free étant donné qu'ils ne supportent
pas mon domaine.

Dernière source d'incompréhension : le fait que le greylisting n'est qu'un
moyen parmi d'autres pour toi alors que dans ma réponse je ne l'évoquais
comme moyen unique sans sous-entendre qu'il y avait autre chose derrière
(RBL, ASK, et j'en passe).
Nous ne parlions donc pas de la même chose : de ton côté il s'agissait de
blacklister (ou greylister) éventuellement un MTA ou un réseau de MTA
soupçonnés en attendant que les RBL aient fait leur boulot et donc de les
blacklister automatiquement.
De mon côté, je ne blackliste rien, je greyliste uniquement les MTA pointant
mon domaine car si je ne le fait pas un tel MTA recevra forcément un jour
ou l'autre un message par débordement et, en tant que << vrai >> MTA, le
rebalancera à intervalle régulier au MTA principal.


Parenthèse sur les RBL : je ne les utilise plus depuis 2 ans pour la bonne
et simple raison que si elles sont promptes à réagir elles sont incorrectes
dans leur retour à la normalité quand ce ne sont pas des actions de grande
envergure.
Le résultat est que des clients se sont plaints que certains de leur
correspondants ne parvenaient pas à leur transmettre de courrier. Alors une
fois on explique que c'est pour le bien du client, que c'est la faute de
l'autre, 2 fois, 3 fois ... et on finit par passer pour des empêcheurs de
bosser en rond.
Même remarque pour les SBL. Même si je reconnais le travail formidable
réalisé par certaines (SpamHaus) il n'en va pas moins que ces listes sont
très sujettes aux attaques de DoS. Donc ...

C'est un peu HS mais bon si ça peut lancer le débat.

(...)

La notation CIDR est juste une commodité pour éviter d'avoir à placer
toutes les adresses IP concernées quand un x.y.z.t/27 suffit par exemple.

Maintenant que j'ai compris qu'il s'agissait de n'importe quel MTA, alors
OK.
(...)

db

--
email : usenet blas net

On Sat Jun 26 2004 at 13:21, Eric Razny wrote:

Tu es dans la confidence alors.

Non, je me prends des messages d'erreur sur certains domaines qui me
disent dans quelle liste je suis censé être.

Pour ma part je ne sais pas quels sont les listes utilisées par AOL
& Co.

mount /dev/brain /tmp

mais si ton FAI est effectivement un nid à spammeurs c'est à lui
qu'il faut s'en prendre

Proxad n'est pas un nid à spammeurs, ils sont plutôt réactifs.

inutile de me demander tout le mal que je pense d'AOL

Tu n'imagines pas à quel point je m'en tape.

--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/

On Sat Jun 26 2004 at 21:44, Eric Razny wrote:

ça veut dire que l'email est passé et la BP gachée.

Les spammeurs arrivent à me bouffer 0,1% de mes 5 Mb/s ?
Les réseaux sont sur-dimensionnés actuellement.

--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/