On Fri, 2008-10-24 at 14:36 +0200, Splio - Benjamin BILLON wrote: > qmail (et je suppose qu'il y en a d'autres), quand il envoie ses mails, > prend en compte le deferred renvoyé par le serveur en face, mais comme > un sac : il va réessayer dans 5 ou 10 minutes, 1 heure après, etc.
Jusque la je ne vois pas le probleme. C'est bien le comportement auquel je m'attends apres un deffered. > , et > le serveur en face risque de lui répondre le même message à chaque fois, > pensant qu'il s'agit d'une nouvelle tentative pour un nouveau message. C'est bien le principe du greylisting. Le serveur ayant greylisté le qmail en question autorisera la tentative suivante. Je passe sur les details evidents d'implementation (autoriser des tranches d'IP pas des /32 seulement, utiliser des periodes de greylist raisonnables, etc....) > Il est simplet, qmail, on lui dit de revenir plus tard, il revient plus > tard, sans comprendre que ce n'est pas lui qui est visé par cette > mesure. Et des mails se perdent parce qu'après un certain temps, il arrête. Encore une fois je ne vois pas le probleme. Le greylisting fonctionne avec n'importe quel serveur distant a-peu-pres RFC compliant. On ne leur demande pas une IA sortie de l'X aux serveurs SMTP :-) > > Concernant le traffic shaping, je ne comprends pas non plus le > rapport ? > Le traffic shaping consiste à ralentir la connexion et les échanges > SMTP, en partant du principe (valide jusqu'à aujourd'hui) que les > spammeurs ne sont pas très patients. Ils ont des tonnes de bouses à > envoyer, et ils comptent bien les envoyer vite fait discretos. Avec > une > connexion SMTP qui dure longtemps, il va pas insister, il va se dire > que > le serveur en face est down (ou faire un timeout) et passer à autre > chose. Nos mails se sont croisés :-) Jérôme Martin | LongPhone Responsable Architecture Réseau 122, rue la Boetie | 75008 Paris Tel : +33 (0)1 56 26 28 44 Fax : +33 (0)1 56 26 28 45 Mail : [EMAIL PROTECTED] Web : www.longphone.com
<<attachment: stock_smiley-1.png>>
