Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Saas

34 réponses
Avatar
Az Sam
que pensez vous de la solution choisie par la Croix Rouge ?

http://www.cio-online.com/actualites/lire-la-croix-rouge-francaise-lutte-contre-le-spam-avec-une-solution-externalisee-2797-page-2.html


Moi je me dis que desormais c'est l'utilisateur interne plutot que les admin
qui sont censes faire le tri, et donc qu'un utilisateur est moins fiable
qu'un admin (en principe ;-),
Si je comprends bien, 1 expediteur exterieur se voit demander une
"accreditation" lors du 1er envoi, mais ensuite, n'ets plus gêné par cette
double procedure (l'envoi + la confirmation apres coup).
Mais alors si la machine de cet utilisateur exterieur accredité sert de
relai de spam, la croix rouge n'en sera plus protégée ?

Cette accreditation est elle valable sur la machine usuelle de l'expediteur
ou sur toute machine y compris un webmail ? L'accreditaion se fait sur la
seule adresse mail de l'xpediteur ou d'autres infos sont verifiees ?

--
Cordialement,
Az Sam.

10 réponses

1 2 3 4
Avatar
Bruno Tréguier
Le 24/03/2010 à 20:48, Az Sam a écrit :
"Bruno Tréguier" a écrit dans
le message de news: hoa5uf$62f$
Le 23/03/2010 à 11:24, Pascal Hambourg a écrit :
http://www.cio-online.com/actualites/lire-la-croix-rouge-francaise-lutte-contre-le-spam-avec-une-solution-externalisee-2797-page-2.html


1) Ça génère de la pollution par rebond vers les adresses usurpées par
les spams.





il n'y a pas de meccanismes de controle de la coherence ? je demandais
justement sur quelles infos est effectuee l'accreditation, j'imaginais un
controle du chemin dans pris les en tetes ou je ne sais quoi



S'il existait un moyen d'accréditer des mails en se basant sur les
en-têtes (hors moyens utilisant de la crypto genre DKIM mais qui
nécessiteraient du coup l'installation d'une partie au moins du système
à chaque bout de la liaison), les spammeurs pourraient eux-mêmes les
insérer...


2) Il se passe quoi si la BAL de l'expéditeur est aussi équipée d'un
système du même type ?





rien j'imagine, les 2 demande de confirmation restes sans suite ?



Tout dépend de l'implémentation: au pire ça provoque une boucle, au
mieux le courriel initial reste en quarantaine en attendant indéfiniment
un déblocage.

Après il y a des gens qui vous disent: "ben oui, mais dans ce cas il n'y
a qu'à mettre un marqueur dans les en-têtes des mails de demande de
confirmation, de façon à ce que eux ne soient pas bloqués"... Sauf que
c'est une idée toute pourrie, pour au moins 2 raisons:

1) il faudrait dans ce cas qu'il existe une harmonisation de ces
marqueurs parmi les différents systèmes existants ;

2) même si on arrivait à résoudre le souci précédent, si la présence
d'un marqueur permet de bypasser le mécanisme de quarantaine, pourquoi
les spammeurs ne le mettraient-ils pas eux-mêmes ? On revient là à la
même problématique que celle de l'histoire du contrôle du chemin dans
les en-têtes.


3) il est nécessaire de "pré-whitelister" toutes les adresses de listes de
discussion/diffusion (et c'est du boulot !)



n'est ce pas l'utilisateur qui configure cela ? de sorte que s'il ne le fait
pas, il ne recoit plus ses listes de diff.



C'est bien l'un des problèmes... L'utilisateur, lui, n'a rien demandé,
et on va lui imposer de retrouver trace de toutes les listes auxquelles
il est abonné afin d'éviter qu'il se fasse virer pour taux de bounces
trop élevé ? Même si *en théorie* il devrait pouvoir le faire (je suis
sûr que vous avez gardé trace de tous vos abonnements, non ?), dans les
faits c'est un très bon moyen de se faire haïr. ;-)

Cordialement,

Bruno
Avatar
Stephane Catteau
Bruno Tréguier devait dire quelque chose comme ceci :


2) même si on arrivait à résoudre le souci précédent, si la présence
d'un marqueur permet de bypasser le mécanisme de quarantaine, pourquoi
les spammeurs ne le mettraient-ils pas eux-mêmes ? On revient là à la
même problématique que celle de l'histoire du contrôle du chemin dans
les en-têtes.



Alors on répondrait, "Il n'y a qu'à dire que seul un serveur peut le
mettre, et qu'il doit l'effacer si le message qu'il reçoit le
contient". Alors un petit malin prendrait les sources d'un serveur SMTP
libre/opensource, effacerait les petites lignes et le vendrait aux
spammeurs, qui se feraient une joie de l'acheter.
Alors il suffirait de filtrer ce serveur là", alors le serveur se
ferait passer pour un autre dans les en-têtes.
Alors... C'est un cercle sans fin, chaque parade aura sa
contre-parade, mais à chaque fois une portion des nuisibles sera
larguée, ce qui au fil du temps devrait donner quelques résultats ; du
moins si d'autres ne viennent pas prendre leur place entre temps.
Avatar
Az Sam
"Bruno Tréguier" a écrit dans
le message de news: hoe1s2$msf$


1) il faudrait dans ce cas qu'il existe une harmonisation de ces marqueurs
parmi les différents systèmes existants ;



Les RFC ont joué leur role : un relatif mais large consensus ont conduit a
ce que nos messages electroniques passent partout.
Les nouveaux admin seraient moins cooperatifs que dans les années 80/90 ?
;-p


2) même si on arrivait à résoudre le souci précédent, si la présence d'un
marqueur permet de bypasser le mécanisme de quarantaine, pourquoi les
spammeurs ne le mettraient-ils pas eux-mêmes ? On revient là à la même
problématique que celle de l'histoire du contrôle du chemin dans les
en-têtes.



C'est clair.
J'imaginais plutot une analyse du chemin parcouru. Comme le fait spamcop
pour retrouver les destinataires des abuse qu'il convient de spammer par nos
reproches.


Même si *en théorie* il devrait pouvoir le faire (je suis sûr que vous avez
gardé trace de tous vos abonnements, non ?),



moi oui, l'ennui c'est que je ne sais pas ou les garder pour ne pas nuire a
leur utilisation en cas de besoin :
- sur un papier : ca s'envole, c'est à la vue de tous
- sur le PC : ca craint si jamais.... c'ets tellement peu sûr ces machines
- dans un cahier : a peine mieux que le bout de papier, surtout que ca prend
feu et ca concentre mon intimité :-p
- chez un ami : ca va pas non ?! et puis quand j'en ai besoin c'est de suite
- a la banque : pire que l'ami, ils ne m'offrent meme pas un coup quand je
leur rend visite !


dans les faits c'est un très bon moyen de se faire haïr. ;-)



Pourtant un bon admin, est un admin qui prend le role du flic non ?
Le garde fous de tous ces "grands malades" qui lui pourissent le SI et qu'il
va te les contentionner a grand coup de PowerShell. ;-)


--
Cordialement,
Az Sam.
Avatar
Bruno Tréguier
Le 25/03/2010 à 7:14, Az Sam a écrit :
"Bruno Tréguier" a écrit dans
le message de news: hoe1s2$msf$

1) il faudrait dans ce cas qu'il existe une harmonisation de ces marqueurs
parmi les différents systèmes existants ;



Les RFC ont joué leur role : un relatif mais large consensus ont conduit a
ce que nos messages electroniques passent partout.
Les nouveaux admin seraient moins cooperatifs que dans les années 80/90 ?
;-p



Non non, c'est simplement que dans le lot (et particulièrement dans ce
domaine-là) il y a des produits commerciaux, qu'on vous vend comme des
produits miracles, avec des arguments aussi scientifiques que ceux qui
ont fait la réputation de la poudre de corne de rhinocéros comme
concurrent de la petite pilule bleue, c'est dire si c'est crédible. ;-)

Dans le monde des gens qui vendent ça, être compatible est un danger
avant tout, car si jamais leur solution n'était pas aussi efficace
qu'ils le prétendent, ils seraient faciles à remplacer (par une solution
open-source, par exemple). Ils se contentent donc la plupart du temps du
minimum syndical histoire de ne pas être complètement hors-course (pour
les appliances anti-spam, ça veut dire que ça cause ESMTP, guère plus).


2) même si on arrivait à résoudre le souci précédent, si la présence d'un
marqueur permet de bypasser le mécanisme de quarantaine, pourquoi les
spammeurs ne le mettraient-ils pas eux-mêmes ? On revient là à la même
problématique que celle de l'histoire du contrôle du chemin dans les
en-têtes.



C'est clair.
J'imaginais plutot une analyse du chemin parcouru. Comme le fait spamcop
pour retrouver les destinataires des abuse qu'il convient de spammer par nos
reproches.



Mouais. AMHA l'attitude saine à ce niveau est de ne faire confiance
qu'aux en-têtes générés sur des serveurs de confiance (donc en règle
générale uniquement ceux qui sont sous votre contrôle). Certaines
sources de spam sont connues pour rajouter des en-têtes "Received:"
totalement bidons, dans le simple but de brouiller les pistes...


dans les faits c'est un très bon moyen de se faire haïr. ;-)



Pourtant un bon admin, est un admin qui prend le role du flic non ?



Oui, ça fait partie du jeu. Vous êtes en train de me dire qu'il est
normal de haïr les flics ? ;-) Venez voir mes utilisateurs: j'ai la
prétention et la faiblesse de croire que même si je suis parfois obligé
de jouer les bouledogues ou de leur expliquer pourquoi je ne donnerai
pas suite à certaines de leurs demandes, ils arrivent à comprendre que
c'est pour leur bien. Si vous expliquez les choses, en règle générale ça
se passe bien. Si vous imposez sans vous justifier, là, en revanche...


Le garde fous de tous ces "grands malades" qui lui pourissent le SI et qu'il
va te les contentionner a grand coup de PowerShell. ;-)



:-)

Cordialement,

Bruno
Avatar
Stéphane CARPENTIER
Az Sam wrote:

la demande d'accreditation se fait pour chaque adresse mail interne ?
L'accreditation pour envoyer a 1 personne, ne vaudrait pas pour ecrire
ensuite a son collegue de bureau ?



Pour la croix rouge, je n'en sais rien.

Mais je travaille avec une société qui a mis en place un procédé dans ce
genre là. La société a externalisé la gestion de ses mails à une
entreprise allemande pour se protéger des virus. À chaque fois que
j'envoie un mail à une nouvelle personne dans cette boîte (c'est très
rare, donc je n'ai pas gueulé trop longtemps), je me prend un bounce de
merde rédigé par des imbéciles.

La seule expérience que j'ai de ce procédé est que ça a été mis en place
par des cons incapables qui n'ont aucune notion de sécurité.
Avatar
Az Sam
"Stéphane CARPENTIER" a écrit dans le
message de news: 4bab5bd6$0$24279$


je me prend un bounce de
merde rédigé par des imbéciles.



la securite (plutôt la tranquilité) aurait un coût ?


La seule expérience que j'ai de ce procédé est que ça a été mis en place
par des cons incapables qui n'ont aucune notion de sécurité.



heu... bien.
Donc, c'est comment pour faire bien pour vous ?


--
Cordialement,
Az Sam.
Avatar
Jean-Marc Desperrier
Bruno Tréguier wrote:
2) Il se passe quoi si la BAL de l'expéditeur est aussi équipée d'un
système du même type ?





rien j'imagine, les 2 demande de confirmation restes sans suite ?



Tout dépend de l'implémentation: au pire ça provoque une boucle, au
mieux le courriel initial reste en quarantaine en attendant indéfiniment
un déblocage.



La solution est d'inclure dans la demande de confirmation l'id du
message l'ayant déclenché (avec des id non-prédictibles, et soit une
mémoire des id émis, soit une règle pour les vérifier à partir d'un secret).

Mais il reste que ça ne marche que si on standardise.
Avatar
Stéphane CARPENTIER
Az Sam wrote:
"Stéphane CARPENTIER" a écrit dans le
message de news: 4bab5bd6$0$24279$


je me prend un bounce de
merde rédigé par des imbéciles.



la securite (plutôt la tranquilité) aurait un coût ?


La seule expérience que j'ai de ce procédé est que ça a été mis en place
par des cons incapables qui n'ont aucune notion de sécurité.



heu... bien.
Donc, c'est comment pour faire bien pour vous ?



Envoyer un mail indiquant que le mail n'a pas été reçu alors qu'il est
reçu n'est pas sérieux.

Envoyer un mail vantant la sécurité en html avec des liens vers les
images (donc, les images ne sont pas incluses dans le message) n'est
pas sérieux.

Répondre par un mail avec une adresse email qui n'a rien à voir avec la
société à laquelle le mail a été envoyé, dont l'IP qui a envoyé le
bounce n'a aucun rapport avec la société qui a envoyé le mail n'est pas
sérieux.

Demander de cliquer sur sur un lien qui pointe sur un truc totalement
inconnu pour que les mails puissent être reçus n'est pas sérieux.

Quand toutes les conditions précédentes sont réunies, j'ai du mal à
considérer la société extérieure comme ayant la moindre notion en
sécurité informatique.

Si encore, j'avais reçu un mail en texte brut qui émanait du poste
auquel j'avais envoyé le message, un lien qui pointe vers un site de la
société me demandant de cliquer pour être enregistré pourrait être
envisagé.
Avatar
Bruno Tréguier
Bonsoir Jean-Marc,

Le 25/03/2010 à 17:03, Jean-Marc Desperrier a écrit :
La solution est d'inclure dans la demande de confirmation l'id du
message l'ayant déclenché (avec des id non-prédictibles, et soit une
mémoire des id émis, soit une règle pour les vérifier à partir d'un
secret).

Mais il reste que ça ne marche que si on standardise.



Oui, effectivement... Ca ressemble d'ailleurs pas mal, dans le principe,
à la protection réalisée au niveau des connexions TCP par les SYN
cookies, cette affaire. ;-)

Cordialement,

Bruno
Avatar
Az Sam
"Stéphane CARPENTIER" a écrit dans le
message de news: 4baba5d6$0$25553


Envoyer un mail indiquant que le mail n'a pas été reçu alors qu'il est
reçu n'est pas sérieux.

Envoyer un mail vantant la sécurité en html avec des liens vers les
images (donc, les images ne sont pas incluses dans le message) n'est
pas sérieux.

Répondre par un mail avec une adresse email qui n'a rien à voir avec la
société à laquelle le mail a été envoyé, dont l'IP qui a envoyé le
bounce n'a aucun rapport avec la société qui a envoyé le mail n'est pas
sérieux.

Demander de cliquer sur sur un lien qui pointe sur un truc totalement
inconnu pour que les mails puissent être reçus n'est pas sérieux.

Quand toutes les conditions précédentes sont réunies, j'ai du mal à
considérer la société extérieure comme ayant la moindre notion en
sécurité informatique.

Si encore, j'avais reçu un mail en texte brut qui émanait du poste
auquel j'avais envoyé le message, un lien qui pointe vers un site de la
société me demandant de cliquer pour être enregistré pourrait être
envisagé.



C'est le constat d'un echange avec une adresse croix rouge ?
Effectivement ca semble plus qu'enquiquinant là. :-/




a part :
Leur page formulaire de contact me renvoit une erreur de certificat avec
IE8.
idem avec Opera.
Heureusement avec Chrome et FF, pas de soucis, la page n'a pas d'incoherence
(ni de certicat d'ailleurs comme ca c'est plus simple )
--
Cordialement,
Az Sam.
1 2 3 4