Manou a écrit :

>> S'il s'agit de distribution en aveugle, je suis d'accord, mais au niveau
>> de la collecte d'adresses valides (puisque je suis à peu près sûr qu'une
>> telle étape a été menée en préalable à la vague de spam que je subis
>> actuellement), l'utilisation de relais ouverts ne peut pas se faire de
>> façon aussi simple.
>
>
> Parce que tu crois vraiment que les spammeurs perdent leur temps à
> collecter les adresses avant de faire une attaque par dictionnaire ? Tu

Pas les spammeurs, d'autres personnes qui "travaillent" dans le même
"business" et qui revendent des listes d'adresses...

> prends un relais ouvert qui accepte cent destinataires ou plus par
> messages, et tu spammes milles adresses par minutes. Inutile de se
> fatiguer à perdre une minute de plus pour vérifier au préalable que les
> adresses sont valides. D'autant plus qu'une telle vérification oblige à
> fournir son adresse IP, à moins d'utiliser un proxy SOCKS comme relais.

Ce ne sont pas les mêmes qui font ces deux phases. Je pense que vous
vous trompez quand vous pensez qu'il est inutile de collecter des
listes d'adresses valides au préalable.


>> Le but étant de collecter des adresses valides, et
>> donc le résultat de commandes SMTP, il faut soit le faire en direct,
>> soit avoir pris le contrôle d'une machine qui le fera, mais c'est un peu
>> plus compliqué que de simplement balancer ses mails au travers d'un
>> relais ouvert.
>
>
> Dix[1] lignes de Perl le font toutes seules pendant que tu dors, et le
> lendemain matin tu te retrouves avec une dizaine de milliers d'adresses
> valides prêtent à être traitées par dix[1] autres lignes de Perl qui se
> feront un plaisir d'envoyer les mails pendant que tu prends ton café.

Je ne parlais pas de la difficulté de scripter un petit truc qui fait
l'attaque par dico, je parlais de la difficulté qu'il y avait à se
cacher derrière un relais ouvert pour cette phase.

> [1]
> "Dix" étant une façon de parler évidement, quoi que...

Je pense effectivement que c'est quasiment un maximum. :-)


>> Je n'ai pas le même avis là-dessus, mais bon, ce n'est même pas la peine
>> de polémiquer, c'est quasi-religieux, comme opinion. Je pense qu'il faut
>> continuer à enquiquiner les spammeurs si ça ne coûte pas grand-chose.
>
>
> Et emerder les spammés en ralentissant le traitement de leurs mails et
> en augmentant le coût de leur abonnement parce qu'il faut rajouter un ou
> deux MX pour tenir la charge. Nan, je ne pense pas...

1) les spammés ne voient rien de tout cela: vous pensez vraiment que
quelqu'un se rendra compte d'un retard de transmission de quelques
secondes ou quelques dizaines de secondes ?
2) ce retard n'entraîne aucune charge complémentaire. Tout au plus
un nombre de connexions simultanées plus important. Si cela permet
en revanche de diminuer le nombre de machines dédiées à l'analyse
des messages pour savoir s'il s'agit de spam ou non, vous pensez
vraiment que vous perdez au change ?

>> La charge sur les serveurs de Free n'est pas plus importante avec
>> ce système de temporisation ou de limitation du nombre de "RCPT TO:"
>> que sans.
>
>
> Admettons que l'on ait une temporisation d'une seconde, compte-tenu du
> temps nécessaire pour envoyer-traiter-répondre_à un /RCPT TO/, cela fait
> un slot occupé cinq fois plus longtemps qu'il n'aurait dû l'être.
> Lorsque les MX gèrent plus de quatre millions d'adresses, ça se ressent
> très vite, surtout qu'une seconde n'est pas une gène en soit pour le bot
> qui procèdera à la manoeuvre, pas plus que dix ou trente d'ailleurs.

Et quand ces messages en arrivent à la phase à laquelle on les analyse,
le problème est le même ou presque: une analyse de message de spam
prend, par rapport au reste du processus, plus de 90% du temps et des
ressources. Si vous arrivez à limiter le nombre de messages qui arrivent
à cette phase, peut-être gagnez-vous un peu en efficacité ?


>> Et vous aurez beau dire que les spammeurs ont le temps, ce qui
>> est vrai, quand la collecte d'une adresse valide prend 1/10 de seconde,
>> c'est quand-même beaucoup plus "spammer-friendly" que si ça en prend
>> 10 ou 20. Encore une fois, là, je me place au niveau de la collecte des
>> adresses valides, et non au niveau de l'envoi des mails. Ce sont 2
>> choses bien différentes.
>
>
> Tu te mets surtout à la place d'un être humain, alors que c'est un robot
> qui fera le travail. Qu'importe s'il lui faut une heure ou une journée,
> et la bande passante n'est pas un problème, la procédure n'occupera même
> pas 1 kbps.

Nous parlons en listes de milliers d'adresses. Pour arriver à constituer
une telle liste, un facteur d'accélération de 100 n'est pas négligeable,
même pour un robot. Vous me prenez vraiment pour une andouille, on
dirait. :-)


>> [...] à part sa mise en place, l'analyse anti-spam
>> des messages est un processus consommateur de ressources, et qui coûte
>> plus d'argent à Free. Moins on reçoit de spam parce qu'on a fait en
>> sorte de mieux protéger les adresses de ses abonnés, moins on a à mettre
>> en place de machines puissantes pour traiter ces messages...
>
>
> Ce n'est pas parce que l'on recevra un spam en moins par jour que les
> adresses seront plus protégées. Déjà qu'il reste encore à démontrer que
> ce spam n'arrivera vraiment pas, ce qui est loin d'être garantie.

C'est ce que vous pensez. Et donc les gens qui ont pondu le kit
"j-chkmail" et les développeurs de sendmail qui ont pensé à l'option
"BadRcptThrottle" sont tous des nazes, et vous tout seul vous avez
raison. :-)

S'il n'y a pas eu constitution de liste au préalable, comment
expliquez-vous la manière dont mes 4 adresses (dont, je le rappelle,
1 n'avait jamais été utilisée, 1 autre me servait uniquement en
réception et n'était connue que d'un système automatique sur un
serveur (et en aucun cas d'autres personnes) ont été spammées
en quelques dizaines de minutes ?

Cordialement,

Bruno