Le 29 juil. 2010 à 16:14, Benjamin Billon a écrit : >> Le seul problème de cette solution est qu'il est très difficile d'avoir une >> interface utilisateur digne de ce nom, et c'est généralement là que les >> produits commerciaux gagnent, surtout que ceux qui achètent les produits >> sont rarement ceux qui les exploitent... > Ca c'est un problème pour l'admin.
Pas tout à fait : dans une PME de taille moyenne (50-500 personnes), l'admin peut très bien passer son temps à répondre à des questions genre pourquoi mon mail n'est pas arrivé ? pourquoi mon mail est marqué comme spam ? pourquoi mon mail n'est pas détecté comme spam ? En générale l'entreprise ne dédie que très rarement un poste à temps plein pour adresser ce genre de demande... Certains produits, comme MailInBlack (dont j'exècre le principe c'est très contre productif), reporte le problème à l'utilisateur lui-même, ce qui est une bonne idée probablement. L'admin ne passe normalement pas son temps devant l'interface utilisateur du moteur de filtrage, il peut donc se satisfaire d'une interface relativement pauvre. > Par principe, le greylisting est une hérésie qui mérite d'être bannie de tout > organisme digne de ce nom, repousser de 15 voire même de 5 minutes l'arrivée > d'un message attendu étant universellement contre-productif. Mouiais, à mon humble avis, les gens qui utilisent le mail comme un moyen d'acheminement temps réel n'ont pas tout compris au film, ce sont souvent les mêmes qui se pleignent de ne pas pouvoir envoyer leur dernier PowerPoint de 100Mo pas mail :-). Sur un moteur grey-listing et avec une bonne configuration du moteurs et de ses interaction, on peut très fortement diminuer cet inconvénient par divers moyens (construction de listes de white-listing automatique, retarder uniquement d'une minutes, informer les utilisateurs, réemission d'un message lorsqu'il est nécessaire de le recevoir immédiatement, ...). D'expérience, en entreprise les messages attendus en instantanés représentent moins de 0,1% des mails sollicités. > Les spammeurs savent depuis longtemps qu'il suffit, en cas de greylisting, > d'insister un peu plus longtemps que d'habitude, et dans la mesure où ce sont > les ressources cpu/réseau de machines infectées et non les leurs qui sont > ralenties/impactées par le procédé, rien ne les décourage de contourner cette > "solution". > Et dans l'idéal, c'est non du greylisting mais du traffic shaping qu'il > faudrait mettre en place, avec des latences plus ou moins prononcées en > fonction de la réputation de l'expéditeur. Bien évidement si le spammeur est un bon élève, alors il re-essaiera, mais alors généralement c'est plutôt un message type commercial avec possibilité de désinscription et serveur bien identifié comme valide. La volumétrie du spam est plutôt constituée de moteurs sur des machines compromises et qui utilisent des bases de données de spam avec des centaines de millions d'emails, dont probablement plus de 80% sont faux ou inactifs. Ces moteurs ont une durée de vie très limités sur internet (quelques dizaines d'heures au maximum) avant d'être blacklistées dans des RBLs ou arrêtés par le propriétaire de la liaison ou son ISP. De par leur nature et la nature de leur base d'emails, ces moteurs n'ont aucune velléité de gérer des spools pour les emails blockés par le grey-listing. C'est pourquoi, du moins dans notre expérience depuis plusieurs années, le grey-listing est la seule technologie qui a significativement fait diminuer le spam sans augmenter les faux positif. Quant à la mise en oeuvre de trafic shaping, c'est peut-être une idée à creuser, mais il me semble difficile de le faire au niveau du destinataire car le spam est imlportant mais généralement faible une fois divisé par le nombre de sources non ? Cordialement, -- Alain RICHARD <mailto:alain.rich...@equation.fr> EQUATION SA <http://www.equation.fr/> Tel : +33 477 79 48 00 Fax : +33 477 79 48 01 Applications client/serveur, ingénierie réseau et Linux
