Re: [FRnOG] Antispam : vaderetro, ironport, proofpoint... vos avis.

2010-07-30 Par sujet Alain Richard

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

2010-07-30 Par sujet Jérôme Nicolle
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

2010-07-30 Par sujet Christophe Baegert

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

2010-07-30 Par sujet Alain Richard

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

2010-07-30 Par sujet Christophe Baegert

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

2010-07-30 Par sujet Rémi Bouhl
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

2010-07-30 Par sujet Benjamin Billon



- 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

2010-07-30 Par sujet Benjamin Billon


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

2010-07-30 Par sujet Thomas Mangin
 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

2010-07-30 Par sujet Jérôme Nicolle
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

2010-07-30 Par sujet Jérôme Nicolle
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-07-30 Par sujet Florian MAURY
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

2010-07-30 Par sujet Jérôme Nicolle
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.)

2010-07-30 Par sujet Thomas Mangin
 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-07-30 Par sujet Florian MAURY
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.

2010-07-30 Par sujet Antoine Versini

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

2010-07-30 Par sujet Yann-Guirec Manac'h
 
 
 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.

2010-07-30 Par sujet Radu-Adrian Feurdean

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

2010-07-30 Par sujet Stephane Kanschine
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/