Lire les messages en TEXTE devient de plus en plus impossible,
tellement les gens utilisent le HTML et ne se servent que de couleurs
ou de police pour séparer le texte cité de leur réponse.
C'est un gros problème de communication car chacun a sa manière de
faire, éventuellement des manières oposées, mais c'est un autre sujet.
Je prévois donc de prioriser la lecture en HTML, afin de voir s'il y a
des fioritures et s'il n'y en a pas je passe en TEXTE pour lire car
c'est bien plus confortable.
Mais pour répondre on se plaint de temps en temps de ma manière de
répondre. Je crois avoir compris que les gens sont tellement habitués
aux couleurs, gras et italique, que du simple texte avec un chevron
devant chaque ligne n'est pas clair. Je ne le comprends pas, mais je
prends acte.
Alors j'envisage aussi de répondre en HTML, au moins sur les listes où
tout le monde fait ça, mais je voudrais garder les chevrons, et qu'ils
soient automatiques.
J'utilise Becky (XP), qui utilise le truc de IE pour le HTML.
Est-ce que c'est possible ? Et avec un autre courrielleur ?
Est-ce que ce risque existe avec un courrielleur de base (OE par exemple)
Non, dans les conditions que je répète inlassablement.
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui bloque les images et autres contenus externes
par exemple. Et ce n'est pas rien puisqu'une IP est associée à une adresse mél, adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug. L'association d'une adresse IP et d'une adresse email n'a aucun intérêt pour les malfaisants. Le webbug permet seulement aux spammeurs de confirmer la validité d'une adresse. Il y a quelques temps, j'ai dépouillé des centaines de spams (j'ai offert en pâture aux spammeurs des adresses email créées uniquement dans cette optique) à la recherche de ce fameux webbug. Je n'en ai trouvé aucun. Evidemment, ça ne signifie pas que ça n'existe pas mais qu'a minima c'est rare. Ce n'est pas étonnant d'ailleurs car les spammeurs peuvent inonder le réseau de milliards de spams [*]. Faire dans la finesse n'est pas leur priorité, ils privilégient l'efficacité et donc la force brute.
[*] Plus de 95% du trafic de mails est constitué de spams. La très grande majorité est interceptée par les serveurs des fournisseurs de service de messagerie qui devraient, sans cela, disposer d'infrastructure énormément plus importantes. Ce qui arrive dans nos boîtes, c'est deux fois par rapport à ce qui circule.
Si on ne clique pas sur un lien, bien sûr.
Il n'y aucun risque à cliquer sur un lien.
C'est le même risque que ci-dessus. Je parle de liens personnalisés, qui identifient l'adresse mél, présents dans un spam sur 2.
Certes (bien que l'estiamation d'un spam sur deux est très largement exagéré) mais le risque d'infection du système est nul.
-- Cordialement,
Luc Burnouf http://www.faqoe.com/
siger a écrit...
Luc a écrit :
siger a écrit...
Est-ce que ce risque existe avec un courrielleur de base (OE par
exemple)
Non, dans les conditions que je répète inlassablement.
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui bloque les
images et autres contenus externes
par exemple.
Et ce n'est pas rien puisqu'une IP est associée à une adresse mél,
adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug.
L'association d'une adresse IP et d'une adresse email n'a aucun intérêt pour
les malfaisants.
Le webbug permet seulement aux spammeurs de confirmer la validité d'une
adresse.
Il y a quelques temps, j'ai dépouillé des centaines de spams (j'ai offert en
pâture aux spammeurs des adresses email créées uniquement dans cette
optique) à la recherche de ce fameux webbug. Je n'en ai trouvé aucun.
Evidemment, ça ne signifie pas que ça n'existe pas mais qu'a minima c'est
rare. Ce n'est pas étonnant d'ailleurs car les spammeurs peuvent inonder le
réseau de milliards de spams [*]. Faire dans la finesse n'est pas leur
priorité, ils privilégient l'efficacité et donc la force brute.
[*] Plus de 95% du trafic de mails est constitué de spams. La très grande
majorité est interceptée par les serveurs des fournisseurs de service de
messagerie qui devraient, sans cela, disposer d'infrastructure énormément
plus importantes. Ce qui arrive dans nos boîtes, c'est deux fois par rapport
à ce qui circule.
Si on ne clique pas sur un lien, bien sûr.
Il n'y aucun risque à cliquer sur un lien.
C'est le même risque que ci-dessus. Je parle de liens personnalisés,
qui identifient l'adresse mél, présents dans un spam sur 2.
Certes (bien que l'estiamation d'un spam sur deux est très largement
exagéré) mais le risque d'infection du système est nul.
Est-ce que ce risque existe avec un courrielleur de base (OE par exemple)
Non, dans les conditions que je répète inlassablement.
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui bloque les images et autres contenus externes
par exemple. Et ce n'est pas rien puisqu'une IP est associée à une adresse mél, adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug. L'association d'une adresse IP et d'une adresse email n'a aucun intérêt pour les malfaisants. Le webbug permet seulement aux spammeurs de confirmer la validité d'une adresse. Il y a quelques temps, j'ai dépouillé des centaines de spams (j'ai offert en pâture aux spammeurs des adresses email créées uniquement dans cette optique) à la recherche de ce fameux webbug. Je n'en ai trouvé aucun. Evidemment, ça ne signifie pas que ça n'existe pas mais qu'a minima c'est rare. Ce n'est pas étonnant d'ailleurs car les spammeurs peuvent inonder le réseau de milliards de spams [*]. Faire dans la finesse n'est pas leur priorité, ils privilégient l'efficacité et donc la force brute.
[*] Plus de 95% du trafic de mails est constitué de spams. La très grande majorité est interceptée par les serveurs des fournisseurs de service de messagerie qui devraient, sans cela, disposer d'infrastructure énormément plus importantes. Ce qui arrive dans nos boîtes, c'est deux fois par rapport à ce qui circule.
Si on ne clique pas sur un lien, bien sûr.
Il n'y aucun risque à cliquer sur un lien.
C'est le même risque que ci-dessus. Je parle de liens personnalisés, qui identifient l'adresse mél, présents dans un spam sur 2.
Certes (bien que l'estiamation d'un spam sur deux est très largement exagéré) mais le risque d'infection du système est nul.
-- Cordialement,
Luc Burnouf http://www.faqoe.com/
Luc
siger a écrit...
Luc a écrit :
siger a écrit...
Est-ce que ce risque existe avec un courrielleur de base (OE par exemple)
Non, dans les conditions que je répète inlassablement.
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui bloque les images et autres contenus externes
par exemple. Et ce n'est pas rien puisqu'une IP est associée à une adresse mél, adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug. L'association d'une adresse IP et d'une adresse email n'a aucun intérêt pour les malfaisants. Le webbug permet seulement aux spammeurs de confirmer la validité d'une adresse. Il y a quelques temps, j'ai dépouillé des centaines de spams (j'ai offert en pâture aux spammeurs des adresses email créées uniquement dans cette optique) à la recherche de ce fameux webbug. Je n'en ai trouvé aucun. Evidemment, ça ne signifie pas que ça n'existe pas mais qu'a minima c'est rare. Ce n'est pas étonnant d'ailleurs car les spammeurs peuvent inonder le réseau de milliards de spams [*]. Faire dans la finesse n'est pas leur priorité, ils privilégient l'efficacité et donc la force brute.
[*] Plus de 95% du trafic de mails est constitué de spams. La très grande majorité est interceptée par les serveurs des fournisseurs de service de messagerie qui devraient, sans cela, disposer d'infrastructure énormément plus importantes. Ce qui arrive dans nos boîtes, c'est deux fois rien par rapport à ce qui circule.
Si on ne clique pas sur un lien, bien sûr.
Il n'y aucun risque à cliquer sur un lien.
C'est le même risque que ci-dessus. Je parle de liens personnalisés, qui identifient l'adresse mél, présents dans un spam sur 2.
Certes (bien que l'estiamation d'un spam sur deux est très largement exagéré) mais le risque d'infection du système est nul.
-- Cordialement,
Luc Burnouf http://www.faqoe.com/
siger a écrit...
Luc a écrit :
siger a écrit...
Est-ce que ce risque existe avec un courrielleur de base (OE par
exemple)
Non, dans les conditions que je répète inlassablement.
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui bloque les
images et autres contenus externes
par exemple.
Et ce n'est pas rien puisqu'une IP est associée à une adresse mél,
adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug.
L'association d'une adresse IP et d'une adresse email n'a aucun intérêt pour
les malfaisants.
Le webbug permet seulement aux spammeurs de confirmer la validité d'une
adresse.
Il y a quelques temps, j'ai dépouillé des centaines de spams (j'ai offert en
pâture aux spammeurs des adresses email créées uniquement dans cette
optique) à la recherche de ce fameux webbug. Je n'en ai trouvé aucun.
Evidemment, ça ne signifie pas que ça n'existe pas mais qu'a minima c'est
rare. Ce n'est pas étonnant d'ailleurs car les spammeurs peuvent inonder le
réseau de milliards de spams [*]. Faire dans la finesse n'est pas leur
priorité, ils privilégient l'efficacité et donc la force brute.
[*] Plus de 95% du trafic de mails est constitué de spams. La très grande
majorité est interceptée par les serveurs des fournisseurs de service de
messagerie qui devraient, sans cela, disposer d'infrastructure énormément
plus importantes. Ce qui arrive dans nos boîtes, c'est deux fois rien par
rapport à ce qui circule.
Si on ne clique pas sur un lien, bien sûr.
Il n'y aucun risque à cliquer sur un lien.
C'est le même risque que ci-dessus. Je parle de liens personnalisés,
qui identifient l'adresse mél, présents dans un spam sur 2.
Certes (bien que l'estiamation d'un spam sur deux est très largement
exagéré) mais le risque d'infection du système est nul.
Est-ce que ce risque existe avec un courrielleur de base (OE par exemple)
Non, dans les conditions que je répète inlassablement.
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui bloque les images et autres contenus externes
par exemple. Et ce n'est pas rien puisqu'une IP est associée à une adresse mél, adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug. L'association d'une adresse IP et d'une adresse email n'a aucun intérêt pour les malfaisants. Le webbug permet seulement aux spammeurs de confirmer la validité d'une adresse. Il y a quelques temps, j'ai dépouillé des centaines de spams (j'ai offert en pâture aux spammeurs des adresses email créées uniquement dans cette optique) à la recherche de ce fameux webbug. Je n'en ai trouvé aucun. Evidemment, ça ne signifie pas que ça n'existe pas mais qu'a minima c'est rare. Ce n'est pas étonnant d'ailleurs car les spammeurs peuvent inonder le réseau de milliards de spams [*]. Faire dans la finesse n'est pas leur priorité, ils privilégient l'efficacité et donc la force brute.
[*] Plus de 95% du trafic de mails est constitué de spams. La très grande majorité est interceptée par les serveurs des fournisseurs de service de messagerie qui devraient, sans cela, disposer d'infrastructure énormément plus importantes. Ce qui arrive dans nos boîtes, c'est deux fois rien par rapport à ce qui circule.
Si on ne clique pas sur un lien, bien sûr.
Il n'y aucun risque à cliquer sur un lien.
C'est le même risque que ci-dessus. Je parle de liens personnalisés, qui identifient l'adresse mél, présents dans un spam sur 2.
Certes (bien que l'estiamation d'un spam sur deux est très largement exagéré) mais le risque d'infection du système est nul.
-- Cordialement,
Luc Burnouf http://www.faqoe.com/
siger
Luc a écrit :
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui bloque les images et autres contenus externes
Oui, c'est ce que j'ai appelé "connecté au web".
par exemple. Et ce n'est pas rien puisqu'une IP est associée à une adresse mél, adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug.
Oui.
L'association d'une adresse IP et d'une adresse email n'a aucun intérêt pour les malfaisants.
Je n'en suis pas persuadé. Par exemple Google a des tas d'IP reliées à des recherches. Google-docs a des tas d'adresses mél reliées à des IP. Je me demande bien pourquoi il ne feraient pas le lien.
-- siger
Luc a écrit :
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui
bloque les images et autres contenus externes
Oui, c'est ce que j'ai appelé "connecté au web".
par exemple.
Et ce n'est pas rien puisqu'une IP est associée à une adresse
mél, adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug.
Oui.
L'association d'une adresse IP et d'une adresse email n'a aucun
intérêt pour les malfaisants.
Je n'en suis pas persuadé. Par exemple Google a des tas d'IP reliées à
des recherches. Google-docs a des tas d'adresses mél reliées à des IP.
Je me demande bien pourquoi il ne feraient pas le lien.
qui est paramétré pour ne pas se connecter au web ?
Connecté ou non, ça ne change rien.
Si OE se connecte sur le port 80, il charge les images,
À condition que l'utilisateur soit allé décocher le paramètre qui bloque les images et autres contenus externes
Oui, c'est ce que j'ai appelé "connecté au web".
par exemple. Et ce n'est pas rien puisqu'une IP est associée à une adresse mél, adresse mél qui est mise dans la case des adresses valides.
Tu parles là du Webbug.
Oui.
L'association d'une adresse IP et d'une adresse email n'a aucun intérêt pour les malfaisants.
Je n'en suis pas persuadé. Par exemple Google a des tas d'IP reliées à des recherches. Google-docs a des tas d'adresses mél reliées à des IP. Je me demande bien pourquoi il ne feraient pas le lien.
-- siger
Patrick Texier
Le 14 Nov 2010 18:26:24 GMT, siger a écrit :
>> Mais pour répondre on se plaint de temps en temps de ma manière >> de répondre. Je crois avoir compris que les gens sont tellement >> habitués aux couleurs, gras et italique, que du simple texte avec >> un chevron devant chaque ligne n'est pas clair. Je ne le >> comprends pas, mais je prends acte.
> Joli troll.
Non, c'est la vérité.
OK.
Mon interprétation est évidamment discutable.
Oui. Je ne vois pas l'intéret de s'adapter aux neuneus. S'ils ne m'envoient pas des messages lisibles, je ne les lis pas. -- Patrick Texier
vim:syntax=mail:ai:ts=4:et:twr
Le 14 Nov 2010 18:26:24 GMT, siger a écrit :
>> Mais pour répondre on se plaint de temps en temps de ma manière
>> de répondre. Je crois avoir compris que les gens sont tellement
>> habitués aux couleurs, gras et italique, que du simple texte avec
>> un chevron devant chaque ligne n'est pas clair. Je ne le
>> comprends pas, mais je prends acte.
> Joli troll.
Non, c'est la vérité.
OK.
Mon interprétation est évidamment discutable.
Oui. Je ne vois pas l'intéret de s'adapter aux neuneus. S'ils ne
m'envoient pas des messages lisibles, je ne les lis pas.
--
Patrick Texier
>> Mais pour répondre on se plaint de temps en temps de ma manière >> de répondre. Je crois avoir compris que les gens sont tellement >> habitués aux couleurs, gras et italique, que du simple texte avec >> un chevron devant chaque ligne n'est pas clair. Je ne le >> comprends pas, mais je prends acte.
> Joli troll.
Non, c'est la vérité.
OK.
Mon interprétation est évidamment discutable.
Oui. Je ne vois pas l'intéret de s'adapter aux neuneus. S'ils ne m'envoient pas des messages lisibles, je ne les lis pas. -- Patrick Texier
vim:syntax=mail:ai:ts=4:et:twr
rm
Salut, Le dimanche 14 novembre 2010 à 23:36, docanski a écrit :
Alors que les eleveurs et agriculteurs empoisonnent toujours la Bretagne, rm ecrit ce qui suit en ce 14/11/2010 22:08 :
Luc demande qu'on lui trouve un site ou du code à utiliser dans un mail pour infecter un système Windows à jour, c'est à dire forcer le téléchargement puis l'exécution d'un programme (malicieux de préférence, et destructeur si possible pour les plus pervers) sans aucune action de l'utilisateur (autre que d'accéder à une url ou afficher un mail reçu). Je pense qu'il va attendre longtemps :)
Et pour cause, tu le sais toi-même. Mais pas pour les raisons qu'il s'obstine à affirmer. Sans aller jusqu'à forcer un téléchargement (quoique un script s'installe très bien tout seul comme un grand dans le cache d'un système et c'est bien une manière de téléchargement !), un script peut parfaitement déclencher une action lors de l'ouverture d'un port de communication avec l'extérieur ou, tout simplement, se contenter d'infecter son hôte.
Tu aurais un exemple de ce genre de script malicieux concrètement adaptable dans un mail en HTML affiché dans Live Mail, Opera ou Becky! ? Si Javascript peut permettre d'infecter un hôte, il serait plus facile d'en parsemer le Web que d'envoyer ça par mail, non ?
On ne peut pas, bien sûr, être sûr qu'aucune vulnérabilité viendra toucher n'importe quel moteur de rendu/script très répandu (Trident, Gecko...), mais les correctifs sont maintenant diffusés tellement rapidement
Mais c'est là que le bât blesse : le correctif arrive toujours *après* l'attaque !
Je ne pense pas, non... enfin de nos jours... Le correctif arrive parfois après divulgation de la faille, mais pas souvent après une exploitation d'icelle. Au siècle dernier, c'est sûr qu'IE restait vulnérable quelques semaines, voire plus, alors même que des exploitations plus ou moins régulières faisaient "rage" ;) Ce temps là est résolu et, jusqu'à preuve du contraire, quasiment plus personne ne se fait méchamment plomber en surfant ou en lisant ses mails (souvent la même chose, vue la recrudescence des webmails). Tu saurais me lister des dizaines de sites (ou même deux ou trois) ayant exploité massivement des failles des moteurs de rendus de Firefox, d'IE ou d'Opera ces dernières années ? Dans le cas contraire, expliquer qu'on prend plus de risques en lisant des mails en html qu'en surfant sur n'importe quel site web parait dérisoire et particulièrement FUDesque.
Encore faut-il, en plus, que l'utilisateur l'installe dès sa sortie.
C'est, sur la plupart des navigateurs actuels, proposé ou même fait automatiquement. Mais même en surfant ou jouant avec des mail en achteumeuleuh, avec un IE6, un Opera 4 ou un Firefox 1.5 on ne doit pas choper grand chose aujourd'hui...
@+ -- rm
Salut,
Le dimanche 14 novembre 2010 à 23:36, docanski a écrit :
Alors que les eleveurs et agriculteurs empoisonnent toujours la
Bretagne, rm ecrit ce qui suit en ce 14/11/2010 22:08 :
Luc demande qu'on lui trouve un site ou du code à utiliser dans un mail
pour infecter un système Windows à jour, c'est à dire forcer le
téléchargement puis l'exécution d'un programme (malicieux de préférence, et
destructeur si possible pour les plus pervers) sans aucune action de
l'utilisateur (autre que d'accéder à une url ou afficher un mail reçu). Je
pense qu'il va attendre longtemps :)
Et pour cause, tu le sais toi-même.
Mais pas pour les raisons qu'il s'obstine à affirmer.
Sans aller jusqu'à forcer un téléchargement (quoique un script
s'installe très bien tout seul comme un grand dans le cache d'un système
et c'est bien une manière de téléchargement !), un script peut
parfaitement déclencher une action lors de l'ouverture d'un port de
communication avec l'extérieur ou, tout simplement, se contenter
d'infecter son hôte.
Tu aurais un exemple de ce genre de script malicieux concrètement adaptable
dans un mail en HTML affiché dans Live Mail, Opera ou Becky! ?
Si Javascript peut permettre d'infecter un hôte, il serait plus facile d'en
parsemer le Web que d'envoyer ça par mail, non ?
On ne peut pas, bien sûr, être sûr qu'aucune vulnérabilité viendra toucher
n'importe quel moteur de rendu/script très répandu (Trident, Gecko...),
mais les correctifs sont maintenant diffusés tellement rapidement
Mais c'est là que le bât blesse : le correctif arrive toujours *après*
l'attaque !
Je ne pense pas, non... enfin de nos jours... Le correctif arrive parfois
après divulgation de la faille, mais pas souvent après une exploitation
d'icelle.
Au siècle dernier, c'est sûr qu'IE restait vulnérable quelques semaines,
voire plus, alors même que des exploitations plus ou moins régulières
faisaient "rage" ;)
Ce temps là est résolu et, jusqu'à preuve du contraire, quasiment plus
personne ne se fait méchamment plomber en surfant ou en lisant ses mails
(souvent la même chose, vue la recrudescence des webmails).
Tu saurais me lister des dizaines de sites (ou même deux ou trois) ayant
exploité massivement des failles des moteurs de rendus de Firefox, d'IE ou
d'Opera ces dernières années ?
Dans le cas contraire, expliquer qu'on prend plus de risques en lisant des
mails en html qu'en surfant sur n'importe quel site web parait dérisoire et
particulièrement FUDesque.
Encore faut-il, en plus, que l'utilisateur l'installe dès sa sortie.
C'est, sur la plupart des navigateurs actuels, proposé ou même fait
automatiquement.
Mais même en surfant ou jouant avec des mail en achteumeuleuh, avec un IE6,
un Opera 4 ou un Firefox 1.5 on ne doit pas choper grand chose
aujourd'hui...
Salut, Le dimanche 14 novembre 2010 à 23:36, docanski a écrit :
Alors que les eleveurs et agriculteurs empoisonnent toujours la Bretagne, rm ecrit ce qui suit en ce 14/11/2010 22:08 :
Luc demande qu'on lui trouve un site ou du code à utiliser dans un mail pour infecter un système Windows à jour, c'est à dire forcer le téléchargement puis l'exécution d'un programme (malicieux de préférence, et destructeur si possible pour les plus pervers) sans aucune action de l'utilisateur (autre que d'accéder à une url ou afficher un mail reçu). Je pense qu'il va attendre longtemps :)
Et pour cause, tu le sais toi-même. Mais pas pour les raisons qu'il s'obstine à affirmer. Sans aller jusqu'à forcer un téléchargement (quoique un script s'installe très bien tout seul comme un grand dans le cache d'un système et c'est bien une manière de téléchargement !), un script peut parfaitement déclencher une action lors de l'ouverture d'un port de communication avec l'extérieur ou, tout simplement, se contenter d'infecter son hôte.
Tu aurais un exemple de ce genre de script malicieux concrètement adaptable dans un mail en HTML affiché dans Live Mail, Opera ou Becky! ? Si Javascript peut permettre d'infecter un hôte, il serait plus facile d'en parsemer le Web que d'envoyer ça par mail, non ?
On ne peut pas, bien sûr, être sûr qu'aucune vulnérabilité viendra toucher n'importe quel moteur de rendu/script très répandu (Trident, Gecko...), mais les correctifs sont maintenant diffusés tellement rapidement
Mais c'est là que le bât blesse : le correctif arrive toujours *après* l'attaque !
Je ne pense pas, non... enfin de nos jours... Le correctif arrive parfois après divulgation de la faille, mais pas souvent après une exploitation d'icelle. Au siècle dernier, c'est sûr qu'IE restait vulnérable quelques semaines, voire plus, alors même que des exploitations plus ou moins régulières faisaient "rage" ;) Ce temps là est résolu et, jusqu'à preuve du contraire, quasiment plus personne ne se fait méchamment plomber en surfant ou en lisant ses mails (souvent la même chose, vue la recrudescence des webmails). Tu saurais me lister des dizaines de sites (ou même deux ou trois) ayant exploité massivement des failles des moteurs de rendus de Firefox, d'IE ou d'Opera ces dernières années ? Dans le cas contraire, expliquer qu'on prend plus de risques en lisant des mails en html qu'en surfant sur n'importe quel site web parait dérisoire et particulièrement FUDesque.
Encore faut-il, en plus, que l'utilisateur l'installe dès sa sortie.
C'est, sur la plupart des navigateurs actuels, proposé ou même fait automatiquement. Mais même en surfant ou jouant avec des mail en achteumeuleuh, avec un IE6, un Opera 4 ou un Firefox 1.5 on ne doit pas choper grand chose aujourd'hui...
@+ -- rm
rm
Salut, Le lundi 15 novembre 2010 à 13:28, Olivier Miakinen a écrit :
La parade consiste à ce que les courrielleurs ne fassent jamais aucun accès externe lors de la réception d'un message. Cela n'interdit ni les images, ni les feuilles de style, mais à condition qu'elles soient incluses dans le message lui-même et pas externes. Quant aux scripts, il y a toutes les raisons de les refuser aussi.
Tiens, à ce sujet, qu'en est-il des webmails ? Certains d'entre eux sont-ils capable de proposer de telles options (désactivation des scripts embarqués et dez contenus externes au message) ? Je pose la question ;)
@+ -- rm
Salut,
Le lundi 15 novembre 2010 à 13:28, Olivier Miakinen a écrit :
La parade consiste à ce que les courrielleurs ne fassent jamais aucun
accès externe lors de la réception d'un message. Cela n'interdit ni
les images, ni les feuilles de style, mais à condition qu'elles soient
incluses dans le message lui-même et pas externes. Quant aux scripts,
il y a toutes les raisons de les refuser aussi.
Tiens, à ce sujet, qu'en est-il des webmails ?
Certains d'entre eux sont-ils capable de proposer de telles options
(désactivation des scripts embarqués et dez contenus externes au message) ?
Je pose la question ;)
Salut, Le lundi 15 novembre 2010 à 13:28, Olivier Miakinen a écrit :
La parade consiste à ce que les courrielleurs ne fassent jamais aucun accès externe lors de la réception d'un message. Cela n'interdit ni les images, ni les feuilles de style, mais à condition qu'elles soient incluses dans le message lui-même et pas externes. Quant aux scripts, il y a toutes les raisons de les refuser aussi.
Tiens, à ce sujet, qu'en est-il des webmails ? Certains d'entre eux sont-ils capable de proposer de telles options (désactivation des scripts embarqués et dez contenus externes au message) ? Je pose la question ;)
@+ -- rm
rm
Le lundi 15 novembre 2010 à 18:53, siger a écrit :
Ce n'est pas clair à mon avis car ça ne répond pas à ceux qui disent qu'il n'y a aucun risque.
Le plus gros risque avec les mails en HTML c'est que le récipiendaire ait envie d'y répondre _aussi_ en HTML, en mettant des mots en gras, en police "à la mode", avec des phrases multicolores et de trucs clignotants/ zigzagants, le tout sur un fond bariolé qui pique les yeux. Les webbugs, les pièces-jointes.txt.pif et les bouts de javascripts, si toutefois c'était un "risque", c'est mignon à coté <:o)
@+ -- rm
Le lundi 15 novembre 2010 à 18:53, siger a écrit :
Ce n'est pas clair à mon avis car ça ne répond pas à ceux qui disent
qu'il n'y a aucun risque.
Le plus gros risque avec les mails en HTML c'est que le récipiendaire ait
envie d'y répondre _aussi_ en HTML, en mettant des mots en gras, en police
"à la mode", avec des phrases multicolores et de trucs clignotants/
zigzagants, le tout sur un fond bariolé qui pique les yeux.
Les webbugs, les pièces-jointes.txt.pif et les bouts de javascripts, si
toutefois c'était un "risque", c'est mignon à coté <:o)
Le lundi 15 novembre 2010 à 18:53, siger a écrit :
Ce n'est pas clair à mon avis car ça ne répond pas à ceux qui disent qu'il n'y a aucun risque.
Le plus gros risque avec les mails en HTML c'est que le récipiendaire ait envie d'y répondre _aussi_ en HTML, en mettant des mots en gras, en police "à la mode", avec des phrases multicolores et de trucs clignotants/ zigzagants, le tout sur un fond bariolé qui pique les yeux. Les webbugs, les pièces-jointes.txt.pif et les bouts de javascripts, si toutefois c'était un "risque", c'est mignon à coté <:o)
@+ -- rm
Olivier Miakinen
Le 17/11/2010 21:45, rm me répondait :
La parade consiste à ce que les courrielleurs ne fassent jamais aucun accès externe lors de la réception d'un message. Cela n'interdit ni les images, ni les feuilles de style, mais à condition qu'elles soient incluses dans le message lui-même et pas externes. Quant aux scripts, il y a toutes les raisons de les refuser aussi.
Tiens, à ce sujet, qu'en est-il des webmails ? Certains d'entre eux sont-ils capable de proposer de telles options (désactivation des scripts embarqués et dez contenus externes au message) ? Je pose la question ;)
C'est une bonne question, et je n'ai aucune idée de la réponse, n'utilisant le webmail qu'en cas d'extrême nécessité.
Le 17/11/2010 21:45, rm me répondait :
La parade consiste à ce que les courrielleurs ne fassent jamais aucun
accès externe lors de la réception d'un message. Cela n'interdit ni
les images, ni les feuilles de style, mais à condition qu'elles soient
incluses dans le message lui-même et pas externes. Quant aux scripts,
il y a toutes les raisons de les refuser aussi.
Tiens, à ce sujet, qu'en est-il des webmails ?
Certains d'entre eux sont-ils capable de proposer de telles options
(désactivation des scripts embarqués et dez contenus externes au message) ?
Je pose la question ;)
C'est une bonne question, et je n'ai aucune idée de la réponse,
n'utilisant le webmail qu'en cas d'extrême nécessité.
La parade consiste à ce que les courrielleurs ne fassent jamais aucun accès externe lors de la réception d'un message. Cela n'interdit ni les images, ni les feuilles de style, mais à condition qu'elles soient incluses dans le message lui-même et pas externes. Quant aux scripts, il y a toutes les raisons de les refuser aussi.
Tiens, à ce sujet, qu'en est-il des webmails ? Certains d'entre eux sont-ils capable de proposer de telles options (désactivation des scripts embarqués et dez contenus externes au message) ? Je pose la question ;)
C'est une bonne question, et je n'ai aucune idée de la réponse, n'utilisant le webmail qu'en cas d'extrême nécessité.
