[XPost frif/fcms]
Bruno Treguier devait dire quelque chose comme ceci :


[Snip]
> 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
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.


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

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


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


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


> [...] à 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.


Fu2 fr.comp.mail.serveurs