Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.
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
Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
Le 30/07/10 11:29, Alain Richard a écrit : 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 :-). J'ai tenté (mais pas fini) de poser un bout de code qui dissocie les pièces jointes pour les acheminer vers un dépôt accessible en HTTP, et ce automatiquement à l'envoi du mail, par le relai SMTP local. Je n'ai pas trouvé de code tout fait et je n'ai pas eu le temps de finir le mien, vous savez si ça existe ? Dans l'idée : - Si la taille du mail dépasse 5Mo - Si des attachements dépassent 1ko (pour laisser les images des signatures et ces conneries là) - Les attachements de plus de 100ko sont détachés, hashés et envoyés sur un dl.free.fr-like interne, associé au mail-id - Le contenu du mail est altéré pour ajouter _en début de mail_ le lien de téléchargement - Le code coté httpd retourne par mail un accusé de téléchargement des pièces jointes à l'expéditeur Ca devrait être adaptable pour pas mal de cas d'utilisation, et le fait de hasher les fichiers et de les envoyer sur un canal distinct permet de dédupliquer et/ou compresser le contenu. Qu'en dites vous ? Ca vaudrait le coup de finir de développer ce merdier ? -- Jérôme Nicolle signature.asc Description: OpenPGP digital signature
[FRnOG] Re: Suggestion pour les attachements lourds
Le 30/07/2010 11:44, Jérôme Nicolle a écrit : Qu'en dites vous ? Ca vaudrait le coup de finir de développer ce merdier ? Le principe est sympa ! il faudrait l'intégrer dans les RFC du SMTP ;-) -- Christophe --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
Le 30 juil. 2010 à 11:44, Jérôme Nicolle a écrit : J'ai tenté (mais pas fini) de poser un bout de code qui dissocie les pièces jointes pour les acheminer vers un dépôt accessible en HTTP, et ce automatiquement à l'envoi du mail, par le relai SMTP local. Je n'ai pas trouvé de code tout fait et je n'ai pas eu le temps de finir le mien, vous savez si ça existe ? Dans l'idée : - Si la taille du mail dépasse 5Mo - Si des attachements dépassent 1ko (pour laisser les images des signatures et ces conneries là) - Les attachements de plus de 100ko sont détachés, hashés et envoyés sur un dl.free.fr-like interne, associé au mail-id - Le contenu du mail est altéré pour ajouter _en début de mail_ le lien de téléchargement - Le code coté httpd retourne par mail un accusé de téléchargement des pièces jointes à l'expéditeur Ca devrait être adaptable pour pas mal de cas d'utilisation, et le fait de hasher les fichiers et de les envoyer sur un canal distinct permet de dédupliquer et/ou compresser le contenu. Qu'en dites vous ? Ca vaudrait le coup de finir de développer ce merdier ? -- Jérôme Nicolle Personnellement je considère que le mail n'est PAS un serveur de fichiers. Je préfère donc essayer d'évangéliser les utilisateurs en limitant la taille sur le serveur SMTP pour qu'ils changent leur mauvaise habitude. Même si techniquement il doit effectivement être possible de finaliser ce dév, il me semble que cela poserait plusieurs problèmes : - encourager à la diffusion de messages lourds par email. - devenir dépendant d'un services externe qui ne garanti aucunement la confidentialité ni la sécurité des informations - les services genre dl.free.fr ont généralement une politique d'expiration des données non maitrisée par l'émetteur de l'email - les messages contenant des gros fichiers sont généralement échanger entre deux utilisateurs intranet, ce serait domage de les externaliser - c'est incompatible avec les technologies de signature électronique des messages Perso je ne pense pas que j'utiliserais une telle architecture, ou du moins pas si elle dépend d'un site web externe. 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
[FRnOG] Re: Suggestion pour les attachements lourds
Le 30/07/2010 11:55, Alain Richard a écrit : - les messages contenant des gros fichiers sont généralement échanger entre deux utilisateurs intranet, ce serait domage de les externaliser Ce point là au moins est facile à régler avec un petit bypass... -- Christophe --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
Bonjour, Le 30/07/10, Alain Richardalain.rich...@equation.fr a écrit : Personnellement je considère que le mail n'est PAS un serveur de fichiers. Je préfère donc essayer d'évangéliser les utilisateurs en limitant la taille sur le serveur SMTP pour qu'ils changent leur mauvaise habitude. Ça n'empêche pas de leur proposer un service interne de stockage/mise à disposition. Même si techniquement il doit effectivement être possible de finaliser ce dév, il me semble que cela poserait plusieurs problèmes : - encourager à la diffusion de messages lourds par email. - devenir dépendant d'un services externe qui ne garanti aucunement la confidentialité ni la sécurité des informations - les services genre dl.free.fr ont généralement une politique d'expiration des données non maitrisée par l'émetteur de l'email - les messages contenant des gros fichiers sont généralement échanger entre deux utilisateurs intranet, ce serait domage de les externaliser Si j'ai bien lu, l'idée est d'avoir un serveur _interne_ Ça m'aurait étonné que Jérôme aille mettre ça sur dl.free.fr ou autre service tiers. - c'est incompatible avec les technologies de signature électronique des messages Si on parle de GPG, les gens qui l'utilisent savent se servir des mails et n'envoient pas des pièces jointes de plusieurs Mo, en principe. Cordialement, Rémi Bouhl. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Suggestion pour les attachements lourds
- c'est incompatible avec les technologies de signature électronique des messages Si on parle de GPG, les gens qui l'utilisent savent se servir des mails et n'envoient pas des pièces jointes de plusieurs Mo, en principe. DKIM --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Suggestion pour les attachements lourds
Non en fait DKIM signera juste avant l'envoi, donc la pièce jointe aura déjà été enlevée. - c'est incompatible avec les technologies de signature électronique des messages Si on parle de GPG, les gens qui l'utilisent savent se servir des mails et n'envoient pas des pièces jointes de plusieurs Mo, en principe. DKIM --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
J'ai tenté (mais pas fini) de poser un bout de code qui dissocie les pièces jointes pour les acheminer vers un dépôt accessible en HTTP, et ce automatiquement à l'envoi du mail, par le relai SMTP local. http://inoa.net/qmail-outbox/ Aucune expérience sur la qualité du code ! Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Suggestion pour les attachements lourds
Le 30/07/10 12:03, Rémi Bouhl a écrit : Ça n'empêche pas de leur proposer un service interne de stockage/mise à disposition. Précisement. L'idée est aussi d'éviter la réplication des pièces jointes du message en x dizaines d'exemplaires dans les .pst de chaque destinataire. Mais l'essentiel est que l'usage de cette extension soit completement transparente pour les utilisateurs, c'est la clef pour éviter qu'ils n'usent et abusent de l'envoi de données lourdes par mail. Si j'ai bien lu, l'idée est d'avoir un serveur _interne_ Ça m'aurait étonné que Jérôme aille mettre ça sur dl.free.fr ou autre service tiers. Ca dit passer par un serveur interne si le SMTP relay est en interne, ce qui n'est pas le cas de tout le monde. Et ce pour au moins une bonne raison : on peut shapper et différer l'envoi du fichier de façon à ne pas figer la connexion (a)DSL du bureau de l'émetteur. Par contre, que le serveur interne envoie le fichier à un homologue externe (dédié ou mutu) dès qu'il y a plusieurs destinataires au message, ce serait une bonne idée, pour rapprocher le contenu de ses destinataires. - c'est incompatible avec les technologies de signature électronique des messages Non, le fichier peut très bien être remplacé par son hash dans le mail, et un plugin du logiciel de messagerie se chargerait de la récupération différée et de la validation de la pièce jointe. Si on parle de GPG, les gens qui l'utilisent savent se servir des mails et n'envoient pas des pièces jointes de plusieurs Mo, en principe. Oui, mais GPG est tellement minoritaire qu'il n'est pas à prendre en compte dans le cas de figure commun, malheureusement. Par contre, ça peut être un cheval de troie pour en répandre l'usage... -- Jérôme Nicolle signature.asc Description: OpenPGP digital signature
[FRnOG] Re: Suggestion pour les attachements lourds
Le 30/07/10 12:07, Thomas Mangin a écrit : J'ai tenté (mais pas fini) de poser un bout de code qui dissocie les pièces jointes pour les acheminer vers un dépôt accessible en HTTP, et ce automatiquement à l'envoi du mail, par le relai SMTP local. http://inoa.net/qmail-outbox/ Aucune expérience sur la qualité du code ! Thomas Merci Thomas ! Je ne le trouvais plus, mais c'est effectivement ce qui m'avait inspiré. Manque de bol, c'est qmail-only, et il y manque quelques fonctionnalités (acquittement du téléchargement, hash du fichier, déduplication du contenu...) Mais c'est une bonne base de travail. -- Jérôme Nicolle signature.asc Description: OpenPGP digital signature
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
2010/7/30 Jérôme Nicolle jer...@ceriz.fr: Le 30/07/10 11:29, Alain Richard a écrit : 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 :-). J'ai tenté (mais pas fini) de poser un bout de code qui dissocie les pièces jointes pour les acheminer vers un dépôt accessible en HTTP, et ce automatiquement à l'envoi du mail, par le relai SMTP local. Je n'ai pas trouvé de code tout fait et je n'ai pas eu le temps de finir le mien, vous savez si ça existe ? Dans l'idée : - Si la taille du mail dépasse 5Mo - Si des attachements dépassent 1ko (pour laisser les images des signatures et ces conneries là) - Les attachements de plus de 100ko sont détachés, hashés et envoyés sur un dl.free.fr-like interne, associé au mail-id - Le contenu du mail est altéré pour ajouter _en début de mail_ le lien de téléchargement - Le code coté httpd retourne par mail un accusé de téléchargement des pièces jointes à l'expéditeur Ca devrait être adaptable pour pas mal de cas d'utilisation, et le fait de hasher les fichiers et de les envoyer sur un canal distinct permet de dédupliquer et/ou compresser le contenu. Qu'en dites vous ? Ca vaudrait le coup de finir de développer ce merdier ? Bonjour, L'idée est intéressante ; elle l'est d'autant plus si on ajoute un système de détection des pièces jointes de masse et qu'on les repère par hash. Reste qu'il faudrait patcher le serveur imap (et quid du pop dans ce cas ?) pour supprimer la pièce jointe quand le mail est supprimé, sinon bonjour le stockage ad vitam (et supprimer la pièce après un délai n'est pas souhaitable car on en sait pas à l'avance l'attachement d'un user à un attachment :P Pour ce qui est de l'aspect technique de la solution, tu risques également d'être confontré à des problèmes avec les mails signés puisque tu altères le contenu en rajoutant le lien (je ne parle pas de clear signed GPG) Tant que ces deux points n'ont pas été résolus, il me parait cependant difficile d'implémenter une telle solution. Cordialement, Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Suggestion pour les attachements lourds
Le 30/07/10 12:12, Florian MAURY a écrit : Bonjour, L'idée est intéressante ; elle l'est d'autant plus si on ajoute un système de détection des pièces jointes de masse et qu'on les repère par hash. Reste qu'il faudrait patcher le serveur imap (et quid du pop dans ce cas ?) pour supprimer la pièce jointe quand le mail est supprimé, sinon bonjour le stockage ad vitam (et supprimer la pièce après un délai n'est pas souhaitable car on en sait pas à l'avance l'attachement d'un user à un attachment :P Je ne le vois pas comme ça : - Chaque destinataire reçoit une URL différente pour chauqe fichier ou lot de fichier - Le serveur HTTP garde la trace des téléchargements et supprime la PJ dès que tous les destinataires l'ont téléchargé, ou passé un certain timeout Agir au niveau du MDA serait problématique puisque l'une des motivation est de réduire la place prise par les mailboxes des destinataires (très problématique en cas de politique de sauvegarde centralisée des mails...) Pour ce qui est de l'aspect technique de la solution, tu risques également d'être confontré à des problèmes avec les mails signés puisque tu altères le contenu en rajoutant le lien (je ne parle pas de clear signed GPG) Dans ce cas précis, c'est au niveau MUA qu'il faut agir, via un plugin qui opère _avant_ la signature du message, et fais signé la pièce jointe à part. Tant que ces deux points n'ont pas été résolus, il me parait cependant difficile d'implémenter une telle solution. Tu as parfaitement raison, et c'est pour ça que je ne l'ai jamais fini :p Mais ça me tenterait bien de reprendre ce projet, pour le coup. -- Jérôme Nicolle signature.asc Description: OpenPGP digital signature
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
http://inoa.net/qmail-outbox/ Aucune expérience sur la qualité du code ! jamais réussit à le setup :) pourtant on a essayé beaucoup (et j'ai encore un personne sur le coup depuis pfiuuu 3 mois quand elle a le temps) Je suis tombe dans la soupe qmail tout petit donc pour moi ça n'a l'air pas trop dur mais il faut avoir les compétences C et sysadmin et bien connaitre qmail. Peut-etre un peu dur comme combinaison :( Thomas--- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Suggestion pour les attachements lourds
2010/7/30 Jérôme Nicolle jer...@ceriz.fr: - Chaque destinataire reçoit une URL différente pour chauqe fichier ou lot de fichier - Le serveur HTTP garde la trace des téléchargements et supprime la PJ dès que tous les destinataires l'ont téléchargé, ou passé un certain timeout Agir au niveau du MDA serait problématique puisque l'une des motivation est de réduire la place prise par les mailboxes des destinataires (très problématique en cas de politique de sauvegarde centralisée des mails...) Je comprends l'idée. J'avais bien percu le fonctionnement. Je parlais de purger le système à la suppression des mails (et qui la, demande un plugin/patch) et uniquement à ce moment là. Les users sont mal éduqués (quoique je fasse souvent pareil :/) et considèrent aussi le serveur de mail comme un serveur de fichier : si la pièce est dans un mail, tu retélécharges la pièce à chaque fois que tu en as besoin : les mails sont classés et les attachments avec. On ne peut donc pas supprimer un attachment du serveur de fichier dès le téléchargement par le user, et le timeout, comme expliqué dans mon précédent mail ne me parait pas envisageable. C'est une question d'opinion, après. Pour ce qui est de l'aspect technique de la solution, tu risques également d'être confontré à des problèmes avec les mails signés puisque tu altères le contenu en rajoutant le lien (je ne parle pas de clear signed GPG) Dans ce cas précis, c'est au niveau MUA qu'il faut agir, via un plugin qui opère _avant_ la signature du message, et fais signé la pièce jointe à part. Solution qui sera alors utilisable uniquement en interne, si cela se passe à l'expédition ; cela perd bcp de l'intérêt que j'y avais vu. A la première lecture de ta solution j'avais pensé qu'il s'agissait également de désengorger les serveurs mails des expéditeurs externes impolis. Tant que ces deux points n'ont pas été résolus, il me parait cependant difficile d'implémenter une telle solution. Tu as parfaitement raison, et c'est pour ça que je ne l'ai jamais fini :p Mais ça me tenterait bien de reprendre ce projet, pour le coup. C'est une bonne idée d'en parler en mailing list, alors, avant de s'y remettre :) Florian MAURY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.
On 07/29/10 20:09, Radu-Adrian Feurdean wrote: [...] Ou il y a quelques mois l'afaire Nerim + UCEProtect (la j'ai bien rigole). Étrangement, nous, on a beaucoup moins rigolé que vous... Qu'est-ce qui a bien pu provoquer votre hilarité ? Qu'un opérateur résolument engagé dans la lutte contre le spam se fasse blacklister tout son AS par un système totalement inepte dont les créateurs eux-mêmes déconseillent l'usage ? Ce filtrage a empêché bon nombre de nos clients disposant de leurs propres MTA sans histoires, sans réseaux infectés, de continuer à envoyer leurs mails en toute sérénité comme ils l'ont toujours fait. Nous en sommes à présent au point de surveiller l'ensemble de nos clients afin de les prévenir (et de nous prévenir) --voire même de les bloquer-- s'ils sont infectés ou indélicats. Que voulez-vous donc que nous fassions de plus ? Vous en connaissez beaucoup des opérateurs qui ont le cran de bloquer leurs clients en cas d'abus manifeste de spam ? Je parle de clients corporate, pas de pékins derrière une stupidbox quelconque, hein. Ce n'est même pas notre métier, à la base. Nous sommes opérateur IP, pas je ne sais quoi qui nous forcerait à surveiller l'activité de nos clients. Et maintenant, c'est quoi la prochaine étape ? Il va peut-être faloir arrêter dans l'escalade de la violence en inventant toute sortes de techniques stupides, totalement disproportionnées et surtout qui créent plus de problèmes qu'elles n'en résolvent. -- Antoine Versini - Nerim --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
Je suis tombe dans la soupe qmail tout petit donc pour moi ça n'a l'air pas trop dur mais il faut avoir les compétences C et sysadmin et bien connaitre qmail. Peut-etre un peu dur comme combinaison :( je peux t'assurer qu'on en trouve (pas facile :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.
On Fri, 30 Jul 2010 12:42:16 +0200, Antoine Versini antoine.vers...@corp.nerim.net said: On 07/29/10 20:09, Radu-Adrian Feurdean wrote: [...] Ou il y a quelques mois l'afaire Nerim + UCEProtect (la j'ai bien rigole). Étrangement, nous, on a beaucoup moins rigolé que vous... Qu'est-ce qui a bien pu provoquer votre hilarité ? Qu'un opérateur résolument engagé dans la lutte contre le spam se fasse blacklister tout son AS par un système totalement inepte dont les créateurs eux-mêmes déconseillent l'usage ? Et que nous, les spammeurs (selon toi :) parmi d'autres) on n'est pas encore arrive dans ce situation. C'est pas de vous (Nerim) que je me suis marre, mais de la situation en general : quelqu'un qui fait ses devoirs qui se trouve pris en otage, alors que vous pouvons continuer a envoyer nos sans probleme. D'ailleurs il me smeble que Gandi ils ont aussi eu des souci du genreil y a quelque temps, mais le plus marrant (.) c'est de voir ca en live. D'ailleurs c'est probablement parce-que nous, a cause de notre metier et notre reputation on est arrive a avoir plusieurs gens payes uniquement pour suivre ces genres de conneries et eviter au max qu'on arrive la. Alors que vous, comme vous faites vos devoirs d'ISP proprement vous n'etes pas cense arriver la. Et *quand* ca arrive quand-meme, ca vous prend par surprise et avec un impact tres serieux. Ce filtrage a empêché bon nombre de nos clients disposant de leurs propres MTA sans histoires, sans réseaux infectés, de continuer à envoyer leurs mails en toute sérénité comme ils l'ont toujours fait. Nous en sommes à présent au point de surveiller l'ensemble de nos clients afin de les prévenir (et de nous prévenir) --voire même de les bloquer-- s'ils sont infectés ou indélicats. Que voulez-vous donc que nous fassions de plus ? Vous en connaissez beaucoup des opérateurs qui ont le cran de bloquer leurs clients en cas d'abus manifeste de spam ? Je parle de clients corporate, pas de pékins derrière une stupidbox quelconque, hein. Ce n'est même pas notre métier, à la base. Nous sommes opérateur IP, pas je ne sais quoi qui nous forcerait à surveiller l'activité de nos clients. Je connais la situation et je la comprends bien; c'est en effet pas votre boulot. Je suis parfaitement d'accord. Par contre, ca dit beaucoup de la mentalite des combattants anti-spam. Ca me rappelle les gens crises/hysteriques, qui essayent a tout prix de causer un max de degats n'imorte ou, juste pour se faire entendre et pour imposer leurs idees. Dans d'autres conditions on appelle ca des terroristes. Autre connerie dans le genre : SpamCop qui envoie les plaintes aux upstreams. C'est vlable meme pour OVH (envoi a OVH, TATAGlobe et GBLX). Et maintenant, c'est quoi la prochaine étape ? Il va peut-être faloir arrêter dans l'escalade de la violence en inventant toute sortes de techniques stupides, totalement disproportionnées et surtout qui créent plus de problèmes qu'elles n'en résolvent. Ca fait quelque temps que je dis que la solution contre le spam ne peut plus s'attaquer aux moyens techniques sans causer (beaucoup) des victimes innocentes. CA passe par l'education des utilisateurs (ca c'est pas nouveau) et surtout par l'education des marketeurs; de leur permier annee d'etude. J'ai entendu N fois le coup du stagiaire ou nouveau embauche au marketing qui arrive avec une idee geniale du style: CD ZZZProspects a 30 EUR, relance sur les des-inscrits, relance sur des vieilles listes de 5 ans, ou d'autres conneries imaginatives qui generent des plaintes. Sans doute, si les operateurs de botnet ont la vie facile, c'est aussi en partie due a des marketeurs qui veulent envoyer leur KK a un max de monde a tout prix. Et puisqu'on est sur frNOG, l'email sur IPv6 a large echelle, j'attends vraiment de le voir un jour, mais j'ai peur que ca sera le dernier bastion de l'IPv4 avec probablement un jour un internet v4 qui va transporter a plus de 95% du SMTP (en cercle ferme en plus). -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Suggestion pour les attachements lourds (was:Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.)
Le Fri 30 Jul, vers 11:44, Jérôme Nicolle exprimait : Je n'ai pas trouvé de code tout fait et je n'ai pas eu le temps de finir le mien, vous savez si ça existe ? Ça existe déjà pour les listes de diffusion, dans un scénario SYMPA par exemple. Ça existe comme recette procmail. Il me semble me souvenir que ça existe aussi dans RT, mais pas que pour les pièces jointes volumineuses. -- « Si un dieu était si puissant qu'il ait créé le monde, mais qu'ensuite il ne fasse rien pour y corriger les problèmes, à quoi bon l'adorer ? Ne serait-il pas plus juste de le juger ? » - Richard M. Stallman --- Liste de diffusion du FRnOG http://www.frnog.org/
