Stephane Faure écrit:
> Venez pas débattre ici alors.
Belle démonstration d'ouverture.
Qu'ils en savent quoi ? Qu'ils sont content ? Ma foi, je ne leur est
pas demandé de le "prouver", comme vous demandez à tout propos. Ils me
l'ont dit et je leur fais confiance là dessus.
Stephane Faure <mysterion@alussinan.org> écrit:
> Venez pas débattre ici alors.
Belle démonstration d'ouverture.
Qu'ils en savent quoi ? Qu'ils sont content ? Ma foi, je ne leur est
pas demandé de le "prouver", comme vous demandez à tout propos. Ils me
l'ont dit et je leur fais confiance là dessus.
Stephane Faure écrit:
> Venez pas débattre ici alors.
Belle démonstration d'ouverture.
Qu'ils en savent quoi ? Qu'ils sont content ? Ma foi, je ne leur est
pas demandé de le "prouver", comme vous demandez à tout propos. Ils me
l'ont dit et je leur fais confiance là dessus.
Voilà, au moins, on sait que vous êtes à bout d'arguments, et que ma
lettre va bientôt pouvoir partir.
Voilà, au moins, on sait que vous êtes à bout d'arguments, et que ma
lettre va bientôt pouvoir partir.
Voilà, au moins, on sait que vous êtes à bout d'arguments, et que ma
lettre va bientôt pouvoir partir.
S'il a envoyé sa lettre par le « canal escargot » (La Poste), comme
pourrait le laisser penser l'adresse postale mentionnée dans son message
du 26/10 à 23:55 (qui confirmait son intention précédemment annoncée
d'écrire à la CNIL), il est infiniment peu probable qu'il ait déjà une
réponse trois jours après...
S'il a envoyé sa lettre par le « canal escargot » (La Poste), comme
pourrait le laisser penser l'adresse postale mentionnée dans son message
du 26/10 à 23:55 (qui confirmait son intention précédemment annoncée
d'écrire à la CNIL), il est infiniment peu probable qu'il ait déjà une
réponse trois jours après...
S'il a envoyé sa lettre par le « canal escargot » (La Poste), comme
pourrait le laisser penser l'adresse postale mentionnée dans son message
du 26/10 à 23:55 (qui confirmait son intention précédemment annoncée
d'écrire à la CNIL), il est infiniment peu probable qu'il ait déjà une
réponse trois jours après...
Entre nous, elle aurait pu partir dès lundi matin, *en l'état*. Car les
arguments que j'ai vu passer n'ont pas dû faire beaucoup évoluer son
contenu, je me trompe ?
Entre nous, elle aurait pu partir dès lundi matin, *en l'état*. Car les
arguments que j'ai vu passer n'ont pas dû faire beaucoup évoluer son
contenu, je me trompe ?
Entre nous, elle aurait pu partir dès lundi matin, *en l'état*. Car les
arguments que j'ai vu passer n'ont pas dû faire beaucoup évoluer son
contenu, je me trompe ?
C'est vrai que sur ce forum, à part l'intervention récente d'Emmanuel
Dreyfus, on a vu beaucoup de mépris, mais pas grand chose pour faire
avancer le schmilblik. Mais le gestionnaire des serveurs de Free a
apporté des mises au point sur proxad.free.divers. Il n'a pas respecté
le suivi, heureusement que j'étais abonné à ce forum...
Il a précisé que les messages filtrés comme étant susceptibles
de contenir Swen n'étaient pas renvoyés à leur expéditeur déclaré, mais
bel et bien supprimés.
Ce qui me paraît tout à fait normal, mais pose
tout de même des questions juridiques. Il a également rappelé que la
liste noire ne recenserait pas des adresses IP reconnues comme étant
émettrices de spam, mais des relais SMTP ouverts.
Voici pour info la version actuelle, que je compte poster lundi :
C'est vrai que sur ce forum, à part l'intervention récente d'Emmanuel
Dreyfus, on a vu beaucoup de mépris, mais pas grand chose pour faire
avancer le schmilblik. Mais le gestionnaire des serveurs de Free a
apporté des mises au point sur proxad.free.divers. Il n'a pas respecté
le suivi, heureusement que j'étais abonné à ce forum...
Il a précisé que les messages filtrés comme étant susceptibles
de contenir Swen n'étaient pas renvoyés à leur expéditeur déclaré, mais
bel et bien supprimés.
Ce qui me paraît tout à fait normal, mais pose
tout de même des questions juridiques. Il a également rappelé que la
liste noire ne recenserait pas des adresses IP reconnues comme étant
émettrices de spam, mais des relais SMTP ouverts.
Voici pour info la version actuelle, que je compte poster lundi :
C'est vrai que sur ce forum, à part l'intervention récente d'Emmanuel
Dreyfus, on a vu beaucoup de mépris, mais pas grand chose pour faire
avancer le schmilblik. Mais le gestionnaire des serveurs de Free a
apporté des mises au point sur proxad.free.divers. Il n'a pas respecté
le suivi, heureusement que j'étais abonné à ce forum...
Il a précisé que les messages filtrés comme étant susceptibles
de contenir Swen n'étaient pas renvoyés à leur expéditeur déclaré, mais
bel et bien supprimés.
Ce qui me paraît tout à fait normal, mais pose
tout de même des questions juridiques. Il a également rappelé que la
liste noire ne recenserait pas des adresses IP reconnues comme étant
émettrices de spam, mais des relais SMTP ouverts.
Voici pour info la version actuelle, que je compte poster lundi :
Voici pour info la version actuelle, que je compte poster lundi :
Ca serait bien que tu parles de l'arret de la cours d'appel de Paris du
17/12/2001, pour eviter que le débat ne sombre dans des marécages sur la
violation des correspondances. La jurisprudence a l'air d'autoriser Free à
faire le filtrage de Swen, le seul problème c'est les faux positifs: la
solution adoptée n'est pas la meilleure disponible.
Voici pour info la version actuelle, que je compte poster lundi :
Ca serait bien que tu parles de l'arret de la cours d'appel de Paris du
17/12/2001, pour eviter que le débat ne sombre dans des marécages sur la
violation des correspondances. La jurisprudence a l'air d'autoriser Free à
faire le filtrage de Swen, le seul problème c'est les faux positifs: la
solution adoptée n'est pas la meilleure disponible.
Voici pour info la version actuelle, que je compte poster lundi :
Ca serait bien que tu parles de l'arret de la cours d'appel de Paris du
17/12/2001, pour eviter que le débat ne sombre dans des marécages sur la
violation des correspondances. La jurisprudence a l'air d'autoriser Free à
faire le filtrage de Swen, le seul problème c'est les faux positifs: la
solution adoptée n'est pas la meilleure disponible.
Le grand problème est que l'adresse d'expedition est toujours fausse.
Renvoyer un avis à cette adresse ne sert donc à rien, à part ennuyer la
personne dont l'adresse a été utilisée.
La bonne solution pour filtrer Swen sans destruction sauvage de messages,
c'est de ne pas l'accepter au moment de son entrée dans la messagerie (pour
ceux qui connaissent: au niveau du MTA sur le MX). Ainsi, c'est au virus lui
même que l'on dit que le message est refusé, et si ca n'est pas le virus
(faux positif), il y aura un rapport d'erreur généré par le serveur
expediteur.
Beaucoup de serveurs de messagerie font le filtrage plus tard: le message
est accepté, puis filtré et eventuellement détruit et signalé en tant que
tel. Le problème c'est qu'à ce moment là, la seule facon de signaler, c'est
d'envoyer un message d'erreur à l'adresse d'expedition qui est fausse.
expéditeur > SMTP/expéditeur > MX/recepteur > récepteur
Cela dépend ou se situe le filtre : MX/destinataire ou SMTP/expéditeur ?
Si le filtre se situe au niveau du :
- MX/destinataire -> mais le SMTP/expéditeur qui tente de contacter le
MX/destinataire envoie un bounce au prétendu expéditeur.
Sur le plan juridique, la nuance entre les deux solutions est de taille. Le
fait que le message soit refusé par le serveur au moment de son entrée sur
la messagerie a son importance: il n'est pas accepté puis détruit avec
notification, il est simplement refusé. Si ca n'est pas un virus, il reste
donc sous la responsabilité du serveur qui essaye de l'envoyer.
Ensuite, comment le filtrer. Le filtre de Free à base de mots clés me
parrait etrange.
Pourquoi ne pas filtrer sur l'executable lui même? Si le
message contient la ligne suivante:
ZGUuDQ0KJAAAAAAAAAB+i6hSOurGATrqxgE66sYBQfbKATvqxgG59sgBLerGAdL1zAEA6sYBWPXV
alors il y a de bonnes chances pour que ca soit Swen.
Ca me parrait très sain de refuser le courrier emmannant des relais ouverts.
Ce sont des nids à spam, et bloquer tout le courrier qui en emmanne permet
de pousser les administrateurs de ces serveurs à corriger leurs
configuration. Tout relais ouvert sera tot ou tard utilisé pour envoyer du
spam.
> Voici pour info la version actuelle, que je compte poster lundi :
Ca serait bien que tu parles de l'arret de la cours d'appel de Paris du
17/12/2001, pour eviter que le débat ne sombre dans des marécages sur la
violation des correspondances. La jurisprudence a l'air d'autoriser Free à
faire le filtrage de Swen, le seul problème c'est les faux positifs: la
solution adoptée n'est pas la meilleure disponible.
Le grand problème est que l'adresse d'expedition est toujours fausse.
Renvoyer un avis à cette adresse ne sert donc à rien, à part ennuyer la
personne dont l'adresse a été utilisée.
La bonne solution pour filtrer Swen sans destruction sauvage de messages,
c'est de ne pas l'accepter au moment de son entrée dans la messagerie (pour
ceux qui connaissent: au niveau du MTA sur le MX). Ainsi, c'est au virus lui
même que l'on dit que le message est refusé, et si ca n'est pas le virus
(faux positif), il y aura un rapport d'erreur généré par le serveur
expediteur.
Beaucoup de serveurs de messagerie font le filtrage plus tard: le message
est accepté, puis filtré et eventuellement détruit et signalé en tant que
tel. Le problème c'est qu'à ce moment là, la seule facon de signaler, c'est
d'envoyer un message d'erreur à l'adresse d'expedition qui est fausse.
expéditeur > SMTP/expéditeur > MX/recepteur > récepteur
Cela dépend ou se situe le filtre : MX/destinataire ou SMTP/expéditeur ?
Si le filtre se situe au niveau du :
- MX/destinataire -> mais le SMTP/expéditeur qui tente de contacter le
MX/destinataire envoie un bounce au prétendu expéditeur.
Sur le plan juridique, la nuance entre les deux solutions est de taille. Le
fait que le message soit refusé par le serveur au moment de son entrée sur
la messagerie a son importance: il n'est pas accepté puis détruit avec
notification, il est simplement refusé. Si ca n'est pas un virus, il reste
donc sous la responsabilité du serveur qui essaye de l'envoyer.
Ensuite, comment le filtrer. Le filtre de Free à base de mots clés me
parrait etrange.
Pourquoi ne pas filtrer sur l'executable lui même? Si le
message contient la ligne suivante:
ZGUuDQ0KJAAAAAAAAAB+i6hSOurGATrqxgE66sYBQfbKATvqxgG59sgBLerGAdL1zAEA6sYBWPXV
alors il y a de bonnes chances pour que ca soit Swen.
Ca me parrait très sain de refuser le courrier emmannant des relais ouverts.
Ce sont des nids à spam, et bloquer tout le courrier qui en emmanne permet
de pousser les administrateurs de ces serveurs à corriger leurs
configuration. Tout relais ouvert sera tot ou tard utilisé pour envoyer du
spam.
> Voici pour info la version actuelle, que je compte poster lundi :
Ca serait bien que tu parles de l'arret de la cours d'appel de Paris du
17/12/2001, pour eviter que le débat ne sombre dans des marécages sur la
violation des correspondances. La jurisprudence a l'air d'autoriser Free à
faire le filtrage de Swen, le seul problème c'est les faux positifs: la
solution adoptée n'est pas la meilleure disponible.
Le grand problème est que l'adresse d'expedition est toujours fausse.
Renvoyer un avis à cette adresse ne sert donc à rien, à part ennuyer la
personne dont l'adresse a été utilisée.
La bonne solution pour filtrer Swen sans destruction sauvage de messages,
c'est de ne pas l'accepter au moment de son entrée dans la messagerie (pour
ceux qui connaissent: au niveau du MTA sur le MX). Ainsi, c'est au virus lui
même que l'on dit que le message est refusé, et si ca n'est pas le virus
(faux positif), il y aura un rapport d'erreur généré par le serveur
expediteur.
Beaucoup de serveurs de messagerie font le filtrage plus tard: le message
est accepté, puis filtré et eventuellement détruit et signalé en tant que
tel. Le problème c'est qu'à ce moment là, la seule facon de signaler, c'est
d'envoyer un message d'erreur à l'adresse d'expedition qui est fausse.
expéditeur > SMTP/expéditeur > MX/recepteur > récepteur
Cela dépend ou se situe le filtre : MX/destinataire ou SMTP/expéditeur ?
Si le filtre se situe au niveau du :
- MX/destinataire -> mais le SMTP/expéditeur qui tente de contacter le
MX/destinataire envoie un bounce au prétendu expéditeur.
Sur le plan juridique, la nuance entre les deux solutions est de taille. Le
fait que le message soit refusé par le serveur au moment de son entrée sur
la messagerie a son importance: il n'est pas accepté puis détruit avec
notification, il est simplement refusé. Si ca n'est pas un virus, il reste
donc sous la responsabilité du serveur qui essaye de l'envoyer.
Ensuite, comment le filtrer. Le filtre de Free à base de mots clés me
parrait etrange.
Pourquoi ne pas filtrer sur l'executable lui même? Si le
message contient la ligne suivante:
ZGUuDQ0KJAAAAAAAAAB+i6hSOurGATrqxgE66sYBQfbKATvqxgG59sgBLerGAdL1zAEA6sYBWPXV
alors il y a de bonnes chances pour que ca soit Swen.
Ca me parrait très sain de refuser le courrier emmannant des relais ouverts.
Ce sont des nids à spam, et bloquer tout le courrier qui en emmanne permet
de pousser les administrateurs de ces serveurs à corriger leurs
configuration. Tout relais ouvert sera tot ou tard utilisé pour envoyer du
spam.
> Voici pour info la version actuelle, que je compte poster lundi :
Ca serait bien que tu parles de l'arret de la cours d'appel de Paris du
17/12/2001, pour eviter que le débat ne sombre dans des marécages sur la
violation des correspondances. La jurisprudence a l'air d'autoriser Free à
faire le filtrage de Swen, le seul problème c'est les faux positifs: la
solution adoptée n'est pas la meilleure disponible.
Je ne comprends pas : que voulez-vous dire par "c'est au virus lui
même que l'on dit que le message est refusé" ? Le serveur expéditeur ne
renverra-t-il pas son rapport d'erreur à l'adresse d'enveloppe
falsifiée ?
J'aimerais introduire cela dans ma lettre, mais ce que je ne comprends
pas, c'est en quoi le fait que le mail soit refusé à l'entrée de la
messagerie empêche que le rapport d'erreur généré par le serveur
demandant la connexion soit envoyé à une adresse falsifiée, si celle-ci
appartient au domaine dudit serveur ? Et que se passe-t-il si elle n'y
appartient pas ?
> Pourquoi ne pas filtrer sur l'executable lui même? Si le
> message contient la ligne suivante:
> ZGUuDQ0KJAAAAAAAAAB+i6hSOurGATrqxgE66sYBQfbKATvqxgG59sgBLerGAdL1zAEA6sYBWPXV
> alors il y a de bonnes chances pour que ca soit Swen.
Vous avez entièrement raison. Cette solution, qui ne pose pas les mêmes
questions de confidentialité, a été suggérée plusieurs fois, mais le
gestionnaire n'en a pas tenu compte, pour une raison que j'ignore. Soit
dit en passant, elle (de même que le filtrage actuel bien sûr) ne nous
sauvera que de Swen, pas de tous les virus à venir.
D'un point de vue pratique, je suis d'accord avec vous. Est-ce que les
RFC prohibent les relais ouverts ? Auquel cas, les FAI étant tenus de
les respecter (quoique ?), cela rendrait-il leur refus également
légitime aux yeux de la loi ?
Oui, je vais en parler, et je vous remercie d'être intervenu dans ce
débat qui n'avançait plus pour nous le signaler. Ne pensez-vous pas
qu'il soit également utile de signaler celui du 18 décembre, dont parle
Jerotito ?
Toutefois, celui du 17 décembre me paraît effectivement assez clair,
puisque les administrateurs peuvent utiliser tous les moyens à leur
disposition pour la sécurité de leur réseau, y compris lire
personnellement le contenu des messages. Aussi je remets en question
l'utilité de la partie de ma lettre qui traite de cette question (pas
celle sur les blacklists, pour ce qui est de l'utilisation de bases de
données nominatives). Mais il me semble rester un doute sur le fait
qu'il s'agit d'un moyen automatisé qui ne détecte pas directement et
sûrement le risque informatique, et qu'il n'est pas annoncé aux
utilisateurs.
Je ne comprends pas : que voulez-vous dire par "c'est au virus lui
même que l'on dit que le message est refusé" ? Le serveur expéditeur ne
renverra-t-il pas son rapport d'erreur à l'adresse d'enveloppe
falsifiée ?
J'aimerais introduire cela dans ma lettre, mais ce que je ne comprends
pas, c'est en quoi le fait que le mail soit refusé à l'entrée de la
messagerie empêche que le rapport d'erreur généré par le serveur
demandant la connexion soit envoyé à une adresse falsifiée, si celle-ci
appartient au domaine dudit serveur ? Et que se passe-t-il si elle n'y
appartient pas ?
> Pourquoi ne pas filtrer sur l'executable lui même? Si le
> message contient la ligne suivante:
> ZGUuDQ0KJAAAAAAAAAB+i6hSOurGATrqxgE66sYBQfbKATvqxgG59sgBLerGAdL1zAEA6sYBWPXV
> alors il y a de bonnes chances pour que ca soit Swen.
Vous avez entièrement raison. Cette solution, qui ne pose pas les mêmes
questions de confidentialité, a été suggérée plusieurs fois, mais le
gestionnaire n'en a pas tenu compte, pour une raison que j'ignore. Soit
dit en passant, elle (de même que le filtrage actuel bien sûr) ne nous
sauvera que de Swen, pas de tous les virus à venir.
D'un point de vue pratique, je suis d'accord avec vous. Est-ce que les
RFC prohibent les relais ouverts ? Auquel cas, les FAI étant tenus de
les respecter (quoique ?), cela rendrait-il leur refus également
légitime aux yeux de la loi ?
Oui, je vais en parler, et je vous remercie d'être intervenu dans ce
débat qui n'avançait plus pour nous le signaler. Ne pensez-vous pas
qu'il soit également utile de signaler celui du 18 décembre, dont parle
Jerotito ?
Toutefois, celui du 17 décembre me paraît effectivement assez clair,
puisque les administrateurs peuvent utiliser tous les moyens à leur
disposition pour la sécurité de leur réseau, y compris lire
personnellement le contenu des messages. Aussi je remets en question
l'utilité de la partie de ma lettre qui traite de cette question (pas
celle sur les blacklists, pour ce qui est de l'utilisation de bases de
données nominatives). Mais il me semble rester un doute sur le fait
qu'il s'agit d'un moyen automatisé qui ne détecte pas directement et
sûrement le risque informatique, et qu'il n'est pas annoncé aux
utilisateurs.
Je ne comprends pas : que voulez-vous dire par "c'est au virus lui
même que l'on dit que le message est refusé" ? Le serveur expéditeur ne
renverra-t-il pas son rapport d'erreur à l'adresse d'enveloppe
falsifiée ?
J'aimerais introduire cela dans ma lettre, mais ce que je ne comprends
pas, c'est en quoi le fait que le mail soit refusé à l'entrée de la
messagerie empêche que le rapport d'erreur généré par le serveur
demandant la connexion soit envoyé à une adresse falsifiée, si celle-ci
appartient au domaine dudit serveur ? Et que se passe-t-il si elle n'y
appartient pas ?
> Pourquoi ne pas filtrer sur l'executable lui même? Si le
> message contient la ligne suivante:
> ZGUuDQ0KJAAAAAAAAAB+i6hSOurGATrqxgE66sYBQfbKATvqxgG59sgBLerGAdL1zAEA6sYBWPXV
> alors il y a de bonnes chances pour que ca soit Swen.
Vous avez entièrement raison. Cette solution, qui ne pose pas les mêmes
questions de confidentialité, a été suggérée plusieurs fois, mais le
gestionnaire n'en a pas tenu compte, pour une raison que j'ignore. Soit
dit en passant, elle (de même que le filtrage actuel bien sûr) ne nous
sauvera que de Swen, pas de tous les virus à venir.
D'un point de vue pratique, je suis d'accord avec vous. Est-ce que les
RFC prohibent les relais ouverts ? Auquel cas, les FAI étant tenus de
les respecter (quoique ?), cela rendrait-il leur refus également
légitime aux yeux de la loi ?
Oui, je vais en parler, et je vous remercie d'être intervenu dans ce
débat qui n'avançait plus pour nous le signaler. Ne pensez-vous pas
qu'il soit également utile de signaler celui du 18 décembre, dont parle
Jerotito ?
Toutefois, celui du 17 décembre me paraît effectivement assez clair,
puisque les administrateurs peuvent utiliser tous les moyens à leur
disposition pour la sécurité de leur réseau, y compris lire
personnellement le contenu des messages. Aussi je remets en question
l'utilité de la partie de ma lettre qui traite de cette question (pas
celle sur les blacklists, pour ce qui est de l'utilisation de bases de
données nominatives). Mais il me semble rester un doute sur le fait
qu'il s'agit d'un moyen automatisé qui ne détecte pas directement et
sûrement le risque informatique, et qu'il n'est pas annoncé aux
utilisateurs.
Évoquer cette question « annexe » (avec lien vers
la reproduction PDF de l'arrêt),
Évoquer cette question « annexe » (avec lien vers
la reproduction PDF de l'arrêt),
Évoquer cette question « annexe » (avec lien vers
la reproduction PDF de l'arrêt),
Voila pour un virus moderne, qui a son propre moteur SMTP:
[OUI au blacklistage des relais ouverts]
Sur l'aspect
legal du blacklistage des relais ouverts, c'est un faux problème: le MX
refuse les messages, c'est à l'emmeteur de les signaler comme perdus. Le
blocage est signalé, je ne vois pas de soucis (Ah oui, il est
interessant de préciser que la RFC 2821 sur SMTP n'a jamais dit qu'il
etait obligatoire d'accepter un message. La Poste a aussi le droit de
refuser des colis ou lettres pour diverses raisons).
> Ne pensez-vous pas
> qu'il soit également utile de signaler celui du 18 décembre, dont parle
> Jerotito ?
URL?
Voila pour un virus moderne, qui a son propre moteur SMTP:
[OUI au blacklistage des relais ouverts]
Sur l'aspect
legal du blacklistage des relais ouverts, c'est un faux problème: le MX
refuse les messages, c'est à l'emmeteur de les signaler comme perdus. Le
blocage est signalé, je ne vois pas de soucis (Ah oui, il est
interessant de préciser que la RFC 2821 sur SMTP n'a jamais dit qu'il
etait obligatoire d'accepter un message. La Poste a aussi le droit de
refuser des colis ou lettres pour diverses raisons).
> Ne pensez-vous pas
> qu'il soit également utile de signaler celui du 18 décembre, dont parle
> Jerotito ?
URL?
Voila pour un virus moderne, qui a son propre moteur SMTP:
[OUI au blacklistage des relais ouverts]
Sur l'aspect
legal du blacklistage des relais ouverts, c'est un faux problème: le MX
refuse les messages, c'est à l'emmeteur de les signaler comme perdus. Le
blocage est signalé, je ne vois pas de soucis (Ah oui, il est
interessant de préciser que la RFC 2821 sur SMTP n'a jamais dit qu'il
etait obligatoire d'accepter un message. La Poste a aussi le droit de
refuser des colis ou lettres pour diverses raisons).
> Ne pensez-vous pas
> qu'il soit également utile de signaler celui du 18 décembre, dont parle
> Jerotito ?
URL?