meilleur logiciel courrier news

Michel Claveau - abstraction meta-galactique non triviale en fuite perpetuelle.

25/08/2004 à 11:11

Bonjour !

Tu oublies une autre explication : il y a aussi ceux qui aiment les messages
en HTML ; alors qu'ils connaissent les messages en texte brut, les
contraintes de certains newsgroups (surtout usenet), l'existence de
logiciels marginaux (ou exotiques) de lecture/écriture des messages. Et qui
savent que le HTML ne comporte pas plus de failles de sécurité que ça.

@-salutations
--
Michel Claveau

Cedric Blancher

25/08/2004 à 11:14

Le Wed, 25 Aug 2004 09:11:50 +0000, Michel Claveau a écrit :

Et qui savent que le HTML ne comporte pas plus de failles de sécurité que ça.

Ce n'est pas HTML en lui même qui comporte des failles, ce n'est jamais
qu'un format de données, mais les interpréteurs HTML. Nuance...

--
[Attention : « vote OUI [resp. NON] pour fr.comp.os.linux » signifie
pour [resp. contre] la _suppression_ de fr.comp.os.linux.]
[...] Ceci est une réponse automatique à votre vote.
-+- CM in: Guide du linuxien pervers - Roby le robot rame et radote -+-

Cedric Blancher

25/08/2004 à 12:13

Le Wed, 25 Aug 2004 10:05:27 +0000, Erwan David a écrit :

Ce n'est pas HTML en lui même qui comporte des failles, ce n'est jamais
qu'un format de données, mais les interpréteurs HTML. Nuance...
Par ailleurs bien rares sont les messages s'annonçant en HTML qui

respectent le langage...

Parce que produits par les logiciels embarquant les interpréteurs
sus-nommés.
Faire un interpréteur, c'est déjà assez difficile. Mais quand il s'agit
de s'interfacer avec un interpréteur et de filtrer ce qu'on lui passe et
ce qu'il nous retourne pour essayer de faire un peu sécurité, ça
commence à devenir le délire. Surtout lorsqu'en plus on prend des
libertés par rapport au standard...

--
Pkoi Q3 est a la foi un jeu qui symbole la bestialite masculine
du jeu PC,mais aussi un jeu dont le champion du monde est une femme,
ca me pose un pb de sens, tous les joueur de Q3 serait des tantouses ?
-+- GaVaGe in GPJ: Réalisation brutale d'une vérité profonde -+-

ComputerHotline

25/08/2004 à 13:58

Le 20/08/2004 10:43, dav, après rigueur et concertation, a rédigé :

quel est actuellement le meilleur logiciel de courrier/news au niveau
sécurité...?
merci,
dav

Il n'y a pas de "meilleur" logiciel, tout dépend l'usage que vous en
avez. Moi, je vous recommande Mozilla ou Thunderbird

--

ComputerHotline
. E-Mail :
. Internet : http://membres.lycos.fr/bt5/

Michel Claveau - abstraction meta-galactique non triviale en fuite perpetuelle.

25/08/2004 à 22:44

... par rapport au standard

Je veux bien, mais c'est quoi, un standard ? Les normes sont précises, les
standards beaucoup moins.
Et, si l'on veut aller dans cette direction, les surprises sont nombreuses :
- jscript est normalisé ; javascript ?
- quels sont les navigateurs capable de traiter de SMIL, pourtant
normalisé depuis longtemps ?
- pour les e-mails, les pièces jointes, les payloads (pièces jointes
intégrées), les messages en HTML, etc. sont décrits dans les RFC. Pourtant,
peut-on dire que les logiciels/systèmes de messagerie qui ne savent
interpréter le HTML ne respectent pas les standards ?

@-salutations
--
Michel Claveau

Cedric Blancher

25/08/2004 à 23:11

Le Wed, 25 Aug 2004 20:44:21 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

... par apport au standard

Outre le fait que ce ne soit pas l'endroit pour parler du respect des
standards, je ne me pose pas sur le fait que certains softs gèrent mieux
les standards que d'autres et bla bla bla. C'est un avis que j'ai mais qui
n'a pas sa place ici. Si on veut discuter de ça, il y a des newsgroups
plus adaptés.
Ce que je veux mettre en avant, c'est la complexification croissante des
MUAs qui entraîne de facto des risques supplémentaire, en particulier
face à des langages dont le spécifications changent souvent (suivez mon
regard).

Je veux bien, mais c'est quoi, un standard ?

C'est un ensemble de règles, de contraintes, visant à assurer
l'interopérabilité entre les systèmes (entre autres).

Les normes sont précises, les standards beaucoup moins.

Ça dépend lesquels. Le standard W3C est, par exemple, nettement plus
précis que certaines normes... Et il est clair que le HTML généré par
certains outils, dont des MUA, n'y est clairement pas conforme.

- pour les e-mails, les pièces jointes, les payloads (pièces
jointes intégrées), les messages en HTML, etc. sont décrits dans
les RFC. Pourtant, peut-on dire que les logiciels/systèmes de
messagerie qui ne savent interpréter le HTML ne respectent pas
les standards ?

Non, parce que le boulot d'un MUA est de lire du courrier électronique.
Or, si tu regardes un mail en HTML, il s'agit d'une pièce jointe. Le MUA,
pour autant que je sache, a toute latitude à interpréter cette pièce ou
la déléguer à un interpréteur externe, ou simplement la présenter à
l'utilisateur comme pièce attachée dont il fera ce qu'il veut.

Pour en revenir au problème de sécurité, je ne dis pas que les mails en
HTML c'est mal, même si je le pense fortement, ne voyant pas l'intérêt
à produire des message pesant 3 fois plus pour, dans 99% des cas, une
mise en page identique (cf. Outlook) ou, encore pire, des trombine
animées débiles dans les signatures... Je dis qu'embarquer de plus en
plus d'interpréteurs dans des logiciels de courrier électronique n'est
sûrement pas une approche des plus sûres.

Si on prend ne serait-ce que le Java, il y a eu tant de différence entre :

. les différentes versions successives de Java
. les différentes implémentations (Sun vs. MS en particulier)
. les ajouts spécifiques de chacun (MS en particulier)

Que finalement, avoir un interpréteur Java embarqué dans un MUA ou même
un navigateur a été abandonné par tout le monde, préférant laisser
l'utilisateur installer la JVM de son choix avec le plugin kivabien(TM).
Si on regarde l'histoire des JVM en terme de sécurité, on voit bien que
parvenir à gérer un langage portable en environnement restreint est un
véritable casse-tête. Et les différences n'ont pas aidé. Certains
produits généraient du code exploitant des failles de sécurité pour
réaliser certaines opérations (!?). Dans d'autres registres, j'ai vu une
boîte coder un ActiveX exploitant une faille de sécurité chargeant une
DLL de Word pour fournir une correction orthographique à la frappe dans
un formulaire Web (!?).

Je me souviens, j'avais fait une étude biblio sur le sujet en 1999[1] à
la fin de mes études. Et bien que je n'ai pas eu le temps de creuser le
problème bien profond, quand je la relis maintenant, je me dis que
finalement les problèmes n'ont pas changé et qu'on se retrouve face aux
mêmes limitations (sachant que là, je ne me préoccupais pas des
différences d'interprétations des standards). Si on part sur des
choses simples, carrées, , un fortement typées, mais de fait assez
limitées et je pense qu'on peut s'en sortir. Si on va vers des choses
plus puissantes, plus laxistes et plus difficiles à contenir, plus les
problèmes de sécurité vont s'empiler. Et le HTML n'y est pour rien
(HTML est assez strict et inoffensif en lui-même), mais il constitue une
passerelle vers ces langages peu sûrs que, amha, un MUA devrait laisser
de côté (JavaScript, ActiveX, etc.).

[1] http://www.netexit.com/~sid/articles/codes_mobiles/

--

On va peut-être savoir si un FreeBSDiste peut se reproduire avec un
linuxien.
Ah ! C'est ça HURD ?

-+- fyr in Guide du linuxien pervers - "Linux transgenique" -+-

Le Wed, 25 Aug 2004 20:44:21 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

... par apport au standard

Outre le fait que ce ne soit pas l'endroit pour parler du respect des
standards, je ne me pose pas sur le fait que certains softs gèrent mieux
les standards que d'autres et bla bla bla. C'est un avis que j'ai mais qui
n'a pas sa place ici. Si on veut discuter de ça, il y a des newsgroups
plus adaptés.
Ce que je veux mettre en avant, c'est la complexification croissante des
MUAs qui entraîne de facto des risques supplémentaire, en particulier
face à des langages dont le spécifications changent souvent (suivez mon
regard).

Je veux bien, mais c'est quoi, un standard ?

C'est un ensemble de règles, de contraintes, visant à assurer
l'interopérabilité entre les systèmes (entre autres).

Les normes sont précises, les standards beaucoup moins.

Ça dépend lesquels. Le standard W3C est, par exemple, nettement plus
précis que certaines normes... Et il est clair que le HTML généré par
certains outils, dont des MUA, n'y est clairement pas conforme.

- pour les e-mails, les pièces jointes, les payloads (pièces
jointes intégrées), les messages en HTML, etc. sont décrits dans
les RFC. Pourtant, peut-on dire que les logiciels/systèmes de
messagerie qui ne savent interpréter le HTML ne respectent pas
les standards ?

Non, parce que le boulot d'un MUA est de lire du courrier électronique.
Or, si tu regardes un mail en HTML, il s'agit d'une pièce jointe. Le MUA,
pour autant que je sache, a toute latitude à interpréter cette pièce ou
la déléguer à un interpréteur externe, ou simplement la présenter à
l'utilisateur comme pièce attachée dont il fera ce qu'il veut.

Pour en revenir au problème de sécurité, je ne dis pas que les mails en
HTML c'est mal, même si je le pense fortement, ne voyant pas l'intérêt
à produire des message pesant 3 fois plus pour, dans 99% des cas, une
mise en page identique (cf. Outlook) ou, encore pire, des trombine
animées débiles dans les signatures... Je dis qu'embarquer de plus en
plus d'interpréteurs dans des logiciels de courrier électronique n'est
sûrement pas une approche des plus sûres.

Si on prend ne serait-ce que le Java, il y a eu tant de différence entre :

. les différentes versions successives de Java
. les différentes implémentations (Sun vs. MS en particulier)
. les ajouts spécifiques de chacun (MS en particulier)

Que finalement, avoir un interpréteur Java embarqué dans un MUA ou même
un navigateur a été abandonné par tout le monde, préférant laisser
l'utilisateur installer la JVM de son choix avec le plugin kivabien(TM).
Si on regarde l'histoire des JVM en terme de sécurité, on voit bien que
parvenir à gérer un langage portable en environnement restreint est un
véritable casse-tête. Et les différences n'ont pas aidé. Certains
produits généraient du code exploitant des failles de sécurité pour
réaliser certaines opérations (!?). Dans d'autres registres, j'ai vu une
boîte coder un ActiveX exploitant une faille de sécurité chargeant une
DLL de Word pour fournir une correction orthographique à la frappe dans
un formulaire Web (!?).

Je me souviens, j'avais fait une étude biblio sur le sujet en 1999[1] à
la fin de mes études. Et bien que je n'ai pas eu le temps de creuser le
problème bien profond, quand je la relis maintenant, je me dis que
finalement les problèmes n'ont pas changé et qu'on se retrouve face aux
mêmes limitations (sachant que là, je ne me préoccupais pas des
différences d'interprétations des standards). Si on part sur des
choses simples, carrées, , un fortement typées, mais de fait assez
limitées et je pense qu'on peut s'en sortir. Si on va vers des choses
plus puissantes, plus laxistes et plus difficiles à contenir, plus les
problèmes de sécurité vont s'empiler. Et le HTML n'y est pour rien
(HTML est assez strict et inoffensif en lui-même), mais il constitue une
passerelle vers ces langages peu sûrs que, amha, un MUA devrait laisser
de côté (JavaScript, ActiveX, etc.).

[1] http://www.netexit.com/~sid/articles/codes_mobiles/

--

On va peut-être savoir si un FreeBSDiste peut se reproduire avec un
linuxien.
Ah ! C'est ça HURD ?

-+- fyr in Guide du linuxien pervers - "Linux transgenique" -+-

Vous avez filtré cet utilisateur ! Consultez son message

Le Wed, 25 Aug 2004 20:44:21 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

... par apport au standard

Outre le fait que ce ne soit pas l'endroit pour parler du respect des
standards, je ne me pose pas sur le fait que certains softs gèrent mieux
les standards que d'autres et bla bla bla. C'est un avis que j'ai mais qui
n'a pas sa place ici. Si on veut discuter de ça, il y a des newsgroups
plus adaptés.
Ce que je veux mettre en avant, c'est la complexification croissante des
MUAs qui entraîne de facto des risques supplémentaire, en particulier
face à des langages dont le spécifications changent souvent (suivez mon
regard).

Je veux bien, mais c'est quoi, un standard ?

C'est un ensemble de règles, de contraintes, visant à assurer
l'interopérabilité entre les systèmes (entre autres).

Les normes sont précises, les standards beaucoup moins.

Ça dépend lesquels. Le standard W3C est, par exemple, nettement plus
précis que certaines normes... Et il est clair que le HTML généré par
certains outils, dont des MUA, n'y est clairement pas conforme.

- pour les e-mails, les pièces jointes, les payloads (pièces
jointes intégrées), les messages en HTML, etc. sont décrits dans
les RFC. Pourtant, peut-on dire que les logiciels/systèmes de
messagerie qui ne savent interpréter le HTML ne respectent pas
les standards ?

Non, parce que le boulot d'un MUA est de lire du courrier électronique.
Or, si tu regardes un mail en HTML, il s'agit d'une pièce jointe. Le MUA,
pour autant que je sache, a toute latitude à interpréter cette pièce ou
la déléguer à un interpréteur externe, ou simplement la présenter à
l'utilisateur comme pièce attachée dont il fera ce qu'il veut.

Pour en revenir au problème de sécurité, je ne dis pas que les mails en
HTML c'est mal, même si je le pense fortement, ne voyant pas l'intérêt
à produire des message pesant 3 fois plus pour, dans 99% des cas, une
mise en page identique (cf. Outlook) ou, encore pire, des trombine
animées débiles dans les signatures... Je dis qu'embarquer de plus en
plus d'interpréteurs dans des logiciels de courrier électronique n'est
sûrement pas une approche des plus sûres.

Si on prend ne serait-ce que le Java, il y a eu tant de différence entre :

. les différentes versions successives de Java
. les différentes implémentations (Sun vs. MS en particulier)
. les ajouts spécifiques de chacun (MS en particulier)

Que finalement, avoir un interpréteur Java embarqué dans un MUA ou même
un navigateur a été abandonné par tout le monde, préférant laisser
l'utilisateur installer la JVM de son choix avec le plugin kivabien(TM).
Si on regarde l'histoire des JVM en terme de sécurité, on voit bien que
parvenir à gérer un langage portable en environnement restreint est un
véritable casse-tête. Et les différences n'ont pas aidé. Certains
produits généraient du code exploitant des failles de sécurité pour
réaliser certaines opérations (!?). Dans d'autres registres, j'ai vu une
boîte coder un ActiveX exploitant une faille de sécurité chargeant une
DLL de Word pour fournir une correction orthographique à la frappe dans
un formulaire Web (!?).

Je me souviens, j'avais fait une étude biblio sur le sujet en 1999[1] à
la fin de mes études. Et bien que je n'ai pas eu le temps de creuser le
problème bien profond, quand je la relis maintenant, je me dis que
finalement les problèmes n'ont pas changé et qu'on se retrouve face aux
mêmes limitations (sachant que là, je ne me préoccupais pas des
différences d'interprétations des standards). Si on part sur des
choses simples, carrées, , un fortement typées, mais de fait assez
limitées et je pense qu'on peut s'en sortir. Si on va vers des choses
plus puissantes, plus laxistes et plus difficiles à contenir, plus les
problèmes de sécurité vont s'empiler. Et le HTML n'y est pour rien
(HTML est assez strict et inoffensif en lui-même), mais il constitue une
passerelle vers ces langages peu sûrs que, amha, un MUA devrait laisser
de côté (JavaScript, ActiveX, etc.).

[1] http://www.netexit.com/~sid/articles/codes_mobiles/

--

On va peut-être savoir si un FreeBSDiste peut se reproduire avec un
linuxien.
Ah ! C'est ça HURD ?

-+- fyr in Guide du linuxien pervers - "Linux transgenique" -+-

Beretta Vexee

26/08/2004 à 00:42

"Bertrand" ecrivait dans
news::

Comment peux tu savoir que un de tes softs n'a jamais fait l'objet
d'une attaque ? Quelqu'un une fois entré dans ton PC peut vouloir te
faire faire certaines choses par le biais d'un de ces programmes, par
exemple.

Faut dir qu'un logiciel developpé seul par un developpeur japonais et qui
en plus est un shareware a 30 avec une page web qui doit dater d'une demis
douzaine d'année est nettement moin exposé aux attaques...

Apres moi ce que je voudrais qu'on m'explique c'est qu'a t'il de pro ce
logiciel ?

Just kidding ;) quoi que...
De même

--
Les fautes d'orthographes sus-citées sont déposées auprès de leurs
propriétaires respectifs. Aucune responsabilité n'est engagé sur
la lisibilité du message ou les éventuelles dommages qu'il peut
engendrer. Beretta Vexée [utilisez l'addresse Reply-to, SVP]

Michel Claveau - abstraction meta-galactique non triviale en fuite perpetuelle.

26/08/2004 à 14:38

Bonjour !

Je ne répond qu'à quelques petits points :
- dans un e-mail en HTML, le HTML n'est pas en pièce jointe, mais bien
dans le corps du message. D'ailleurs, au point de vue sécurité, si l'on veut
chercher un éventuel script, c'est bien là qu'il faut aller voir.
- un message en HTML n'est pas 3 fois plus lourd. En réalité, comme
certains lecteurs ne sont pas capables de lire le HTML, Outlook-Express,
comme MesNews, et plusieurs autres logiciels copient le message en texte
brut (plain/text). Cela fait que l'on a deux fois le message : une fois en
HTML, et une fois en plain.text. Cela peut se voir, avec outlook-express,
en regardant la source du message (Ctrl-F3), ou en jouant avec les onglets
(MesNews). De plus lorsqu'un message est petit, l'impact des en-têtes
(headers) est important, sur le poids des messages ; a contrario, plus le
message est gros, moins il y a de différence entre le HTML et le plain/text.
- on ne peut pas reprocher au HTML le mauvais usage qu'en font certains
(genre clignotement vert sur du rouge) ; de la même manière que l'on ne peut
pas reprocher au texte brut les propos anormaux (genre insultes) d'autres
posteurs. Dans les deux cas, on perd du temps et de la place.
- autant que je sache, on ne peux pas embarquer de scripts java dans un
message. On peux y mettre un applet, mais ce dernier s'exécutera d'après un
serveur, et le lecteur ne verra que le résultat. Si la connexion avec le
serveur a été bloquée, on n'aura qu'un rectangle gris.
- au niveau sécurité, java fait partie des solutions les plus sûres.

@-salutations
--
Michel Claveau

Cedric Blancher

26/08/2004 à 15:04

Le Thu, 26 Aug 2004 12:38:36 +0000, Michel Claveau - abstraction
meta-galactique non triviale en fuite perpetuelle. a écrit :

- autant que je sache, on ne peux pas embarquer de scripts java dans un
message.

J'ai dit ça moi ? On le référence dans le HTML, c'est tout, comme une
page web classique.

On peux y mettre un applet, mais ce dernier s'exécutera d'après un
serveur, et le lecteur ne verra que le résultat. Si la connexion avec le
serveur a été bloquée, on n'aura qu'un rectangle gris.

Elle s'exécute où l'applet ? Sur le poste client, pas sur le serveur.
Le serveur ne fait que fournir le code ou le bytecode à exécuter
localement sur la machine virtuelle appelée par l'interpréteur HTML
du MUA, qui prend donc la décision de faire exécuter ou pas ce code.

- au niveau sécurité, java fait partie des solutions les plus sûres.

À l'heure d'aujourd'hui, sûrement, c'était loin d'être le cas il y a 3
ou 4 ans. Je prenais un exemple, à savoir la gestation de Java, qui me
semble assez représentative des problèmes que posent l'inclusion de
codes

Pour l'histoire du HTML, je viens de tester 5 MUA, ils me le collent tous
en deux pièces jointes, mais bon, effectivement si on ne double pas le
texte, il doit pouvoir passer en body en content-type text/html.

--
Et quand je fais cat /dev/random > /dev/audio, l'auteur de /dev/random
il touche des sous de la SACEM ?
-+- JFB in GFA : "SACEM le vent et récolte le pognon" -+-

Thomas Labourdette

26/08/2004 à 21:13

Le 26-08-2004, Cedric Blancher a écrit :

Pour l'histoire du HTML, je viens de tester 5 MUA, ils me le collent tous
en deux pièces jointes, mais bon, effectivement si on ne double pas le
texte, il doit pouvoir passer en body en content-type text/html.

Ce qui sera automatiquement détruit par mes filtres anti-spam (99,99%
des tex/html pure sont des spams). De plus la taille est quand même
largement supérieure au texte brute pour un confort de lecture
négligable.

@+
--
Betty ZIER
BAC :
- Dans le cinéma muet, les acteurs parlaient avec des mots qu'ils
écrivaient en bas du film.

meilleur logiciel courrier news

10 réponses

Veuillez sélectionner un problème