Bonsoir,
Depuis longtemps je m'interroge sur les raisons pour lesquelles certains
de nos isp ne suppriment pas les courriels vecteurs de virus, ou les
virus eux-mêmes. Je viens ici recueillir votre avis sur une petite idée
que j'ai eue touchant un des aspects techniques de la question.
Mon exemple : Il y a quelques mois, je recevais quotidiennement par
laposte.net une cinquantaine de messages d'environ 140 ko. Si
laposte.net a, disons, 1 million de "clients" aussi gâtés que moi et que
ceux-ci vident leur boîte à lettre 1 fois par jour, le volume moyen de
toutes ces boîtes additionnées dépasserait 3,5 millions de Mo, soit 3,5
To ou 3500 Go. (Sauf erreur et en négligeant le courrier utile.)
Nos ISP stockent-ils vraiment d'aussi monstrueux volumes ? Ou plutôt ne
constituent-ils pas dans un coin une bibliothèque de virus ? Il serait
tellement plus économique d'identifier le virus contenu dans tel
message, de le supprimer s'il existe déjà dans la bibliothèque, de
stocker le message sans virus. À la demande, il n'y aurait qu'à
réinjecter dans le message le virus répertorié par copie depuis la
bibliothèque. Et hop, voici le joli petit message non ouvert !
Est-ce un mauvais rêve ou de telles pratiques existent-elles ? Si oui
dans quel but ? Pour nous obliger à payer un service supplémentaire de
nettoyage ? Ma bal chez laposte.net est gratuite...
Vous me direz : 3500 Go, ça tient dans 35 disques de 100 Go, ce n'est
pas grand-chose.
et il faut aussi que le destinataire accepte ce genre de filtrage.
Le service se protège contre des bombes logicielles. L'utilisateur n'a pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une attaque de virus.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux. Et un virus n'est pas de la correspondance privée.
ca peut l'etre...
Laurent Wacrenier wrote:
JustMe <pasdesp@m.merci> écrit:
et il faut aussi que le destinataire accepte ce genre de filtrage.
Le service se protège contre des bombes logicielles. L'utilisateur n'a
pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une
attaque de virus.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux.
Et un virus n'est pas de la correspondance privée.
et il faut aussi que le destinataire accepte ce genre de filtrage.
Le service se protège contre des bombes logicielles. L'utilisateur n'a pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une attaque de virus.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux. Et un virus n'est pas de la correspondance privée.
ca peut l'etre...
Laurent Wacrenier
JustMe écrit:
Et un virus n'est pas de la correspondance privée.
ca peut l'etre...
Rien à foutre. Si vous échangez volontairement des choses dangereuses voir illégales, n'obligez pas un relai tiers à supporter vos trafics.
JustMe <pasdesp@m.merci> écrit:
Et un virus n'est pas de la correspondance privée.
ca peut l'etre...
Rien à foutre. Si vous échangez volontairement des choses dangereuses
voir illégales, n'obligez pas un relai tiers à supporter vos trafics.
Et un virus n'est pas de la correspondance privée.
ca peut l'etre...
Rien à foutre. Si vous échangez volontairement des choses dangereuses voir illégales, n'obligez pas un relai tiers à supporter vos trafics.
Tiens les éditeurs d'antivirus demandent des choses illégales à leur clients ?
Ah bon...
Olivier Zolli
JustMe écrivait :
Rien à foutre. Si vous échangez volontairement des choses dangereuses voir illégales, n'obligez pas un relai tiers à supporter vos trafics.
Tiens les éditeurs d'antivirus demandent des choses illégales à leur clients ?
Ah bon...
Un bon éditeur d'anti-virus a mis en place une page web pour uploader ses virus. Il est parfaitement au courant que ça ne passera probablement pas par mail vu que c'est son boulot et celui de ses confrères de l'empêcher.
Rien à foutre. Si vous échangez volontairement des choses dangereuses
voir illégales, n'obligez pas un relai tiers à supporter vos trafics.
Tiens les éditeurs d'antivirus demandent des choses illégales à leur
clients ?
Ah bon...
Un bon éditeur d'anti-virus a mis en place une page web pour uploader
ses virus. Il est parfaitement au courant que ça ne passera probablement
pas par mail vu que c'est son boulot et celui de ses confrères de
l'empêcher.
Rien à foutre. Si vous échangez volontairement des choses dangereuses voir illégales, n'obligez pas un relai tiers à supporter vos trafics.
Tiens les éditeurs d'antivirus demandent des choses illégales à leur clients ?
Ah bon...
Un bon éditeur d'anti-virus a mis en place une page web pour uploader ses virus. Il est parfaitement au courant que ça ne passera probablement pas par mail vu que c'est son boulot et celui de ses confrères de l'empêcher.
pas sim simple : 1/ il faudrait que le virus determine le nom du relais SMTP du client
Héh. Dans 90% des cas (outlook express configuré), c'est particulièrement simple.
Je n'ai jamais dit que c'était dur. Mais ca fait grossir le virus.
Un lien vers une librairie standard, ça doit faire quelques bytes. Et puis, de nos jours, les concepteurs de virus ne sont plus exactement des pros de l'optimisation, on dirait.
D'ailleurs, je pense que c'est toute la série des MyDoom qui passait par le smtp du FAI. Ca a fait un carton.
2/ il faudrait que l'admin du dit MTA soit aveugle pour ne pas voir ses queues exploser
Mmmmwais. Franchement, quand on voit l'état du réseau en ce moment, je crois que les admins des gros fournisseurs sont aveugles, sourds, muets et inexistants, dans la plupart des cas.
il y a finalement assez peu de spams, de nos jours, qui passent par les MTA officiels des FAI.
Ils passent par les tuyeaux et les routeurs, par milliers, par contre.
Quand à gérer une queue en local sur le PC infecté...
C'est l'enfance de l'art, 'faut pas déconner, non plus. Surtout que les mails ne sont pas particulièrement personnalisés, non plus (donc ça demande de stocker une fois un template, et n adresses qui ont échoué), et les programmes qui font ça (les trojans, quoi) peuvent se permettre d'être particulièrement approximatifs.
Ca prend de la place disque, dela mémoire, de la CPU, etc : la furtivité du virus en prend un coup.
Mais les concepteurs se foutent totalement de la furtivité, enfin ! A voir le nombre de machines compromises qui passent leur temps à envoyer des spams par centaine, on dirait qu'ils ont raison.
Hélas, je n'arrive plus à remettre la main sur la page qui avait été écrite par un gars qui avait été compromis, mais en avait profité pour analyser le serveur smtp modifié installé dans un stage ultérieur par le virus.
A propos de discrétion, d'ailleurs, je te renvoie à :
http://www.lurhq.com/sobig.html
Qui explique (en anglais) le fonctionnement de sobig, qui, en gros, après s'être répandu, installe un trojan et un proxy socks sur les machines des victimes.
tant que les greylist sont une minorité...
Heh. Amusant paradoxe : une technique qui ne demande qu'à être victime de son succès... :)
comme le spam.... Quand je recevais 1 spam par mois je le lisais. Maintenant greylist/filtrage/poubelle/abuse/etc...
Et puis, à la fin, le spam qui passe est totalement illisible à force d'insérer des caractères bizarres pour tromper les filtres...
Mais bon, dans tout ça, y'a toujours quelqu'un qui se fait de la thune, même si ce n'est pas le spammeur ou son commanditaire.
Fred -- Over thinking, over analyzing separates the body from the mind. Withering my intuition, missing opportunities and I must Feed my will to feel my moment drawing way outside the lines. (Tool, Lateralus)
F. Senault wrote:
pas sim simple :
1/ il faudrait que le virus determine le nom du relais SMTP du client
Héh. Dans 90% des cas (outlook express configuré), c'est
particulièrement simple.
Je n'ai jamais dit que c'était dur. Mais ca fait grossir le virus.
Un lien vers une librairie standard, ça doit faire quelques bytes. Et
puis, de nos jours, les concepteurs de virus ne sont plus exactement des
pros de l'optimisation, on dirait.
D'ailleurs, je pense que c'est toute la série des MyDoom qui passait par
le smtp du FAI. Ca a fait un carton.
2/ il faudrait que l'admin du dit MTA soit aveugle pour ne pas voir ses
queues exploser
Mmmmwais. Franchement, quand on voit l'état du réseau en ce moment, je
crois que les admins des gros fournisseurs sont aveugles, sourds, muets
et inexistants, dans la plupart des cas.
il y a finalement assez peu de spams, de nos jours, qui passent par les
MTA officiels des FAI.
Ils passent par les tuyeaux et les routeurs, par milliers, par contre.
Quand à gérer une queue en local sur le PC infecté...
C'est l'enfance de l'art, 'faut pas déconner, non plus. Surtout que les
mails ne sont pas particulièrement personnalisés, non plus (donc ça
demande de stocker une fois un template, et n adresses qui ont échoué),
et les programmes qui font ça (les trojans, quoi) peuvent se permettre
d'être particulièrement approximatifs.
Ca prend de la place disque, dela mémoire, de la CPU, etc : la furtivité
du virus en prend un coup.
Mais les concepteurs se foutent totalement de la furtivité, enfin ! A
voir le nombre de machines compromises qui passent leur temps à envoyer
des spams par centaine, on dirait qu'ils ont raison.
Hélas, je n'arrive plus à remettre la main sur la page qui avait été
écrite par un gars qui avait été compromis, mais en avait profité pour
analyser le serveur smtp modifié installé dans un stage ultérieur par le
virus.
A propos de discrétion, d'ailleurs, je te renvoie à :
http://www.lurhq.com/sobig.html
Qui explique (en anglais) le fonctionnement de sobig, qui, en gros,
après s'être répandu, installe un trojan et un proxy socks sur les
machines des victimes.
tant que les greylist sont une minorité...
Heh. Amusant paradoxe : une technique qui ne demande qu'à être victime
de son succès... :)
comme le spam.... Quand je recevais 1 spam par mois je le lisais.
Maintenant greylist/filtrage/poubelle/abuse/etc...
Et puis, à la fin, le spam qui passe est totalement illisible à force
d'insérer des caractères bizarres pour tromper les filtres...
Mais bon, dans tout ça, y'a toujours quelqu'un qui se fait de la thune,
même si ce n'est pas le spammeur ou son commanditaire.
Fred
--
Over thinking, over analyzing separates the body from the mind.
Withering my intuition, missing opportunities and I must
Feed my will to feel my moment drawing way outside the lines.
(Tool, Lateralus)
pas sim simple : 1/ il faudrait que le virus determine le nom du relais SMTP du client
Héh. Dans 90% des cas (outlook express configuré), c'est particulièrement simple.
Je n'ai jamais dit que c'était dur. Mais ca fait grossir le virus.
Un lien vers une librairie standard, ça doit faire quelques bytes. Et puis, de nos jours, les concepteurs de virus ne sont plus exactement des pros de l'optimisation, on dirait.
D'ailleurs, je pense que c'est toute la série des MyDoom qui passait par le smtp du FAI. Ca a fait un carton.
2/ il faudrait que l'admin du dit MTA soit aveugle pour ne pas voir ses queues exploser
Mmmmwais. Franchement, quand on voit l'état du réseau en ce moment, je crois que les admins des gros fournisseurs sont aveugles, sourds, muets et inexistants, dans la plupart des cas.
il y a finalement assez peu de spams, de nos jours, qui passent par les MTA officiels des FAI.
Ils passent par les tuyeaux et les routeurs, par milliers, par contre.
Quand à gérer une queue en local sur le PC infecté...
C'est l'enfance de l'art, 'faut pas déconner, non plus. Surtout que les mails ne sont pas particulièrement personnalisés, non plus (donc ça demande de stocker une fois un template, et n adresses qui ont échoué), et les programmes qui font ça (les trojans, quoi) peuvent se permettre d'être particulièrement approximatifs.
Ca prend de la place disque, dela mémoire, de la CPU, etc : la furtivité du virus en prend un coup.
Mais les concepteurs se foutent totalement de la furtivité, enfin ! A voir le nombre de machines compromises qui passent leur temps à envoyer des spams par centaine, on dirait qu'ils ont raison.
Hélas, je n'arrive plus à remettre la main sur la page qui avait été écrite par un gars qui avait été compromis, mais en avait profité pour analyser le serveur smtp modifié installé dans un stage ultérieur par le virus.
A propos de discrétion, d'ailleurs, je te renvoie à :
http://www.lurhq.com/sobig.html
Qui explique (en anglais) le fonctionnement de sobig, qui, en gros, après s'être répandu, installe un trojan et un proxy socks sur les machines des victimes.
tant que les greylist sont une minorité...
Heh. Amusant paradoxe : une technique qui ne demande qu'à être victime de son succès... :)
comme le spam.... Quand je recevais 1 spam par mois je le lisais. Maintenant greylist/filtrage/poubelle/abuse/etc...
Et puis, à la fin, le spam qui passe est totalement illisible à force d'insérer des caractères bizarres pour tromper les filtres...
Mais bon, dans tout ça, y'a toujours quelqu'un qui se fait de la thune, même si ce n'est pas le spammeur ou son commanditaire.
Fred -- Over thinking, over analyzing separates the body from the mind. Withering my intuition, missing opportunities and I must Feed my will to feel my moment drawing way outside the lines. (Tool, Lateralus)
F. Senault
Fabien LE LEZ écrit:
et surtout, il faut pas mal de puissance processeur.
Pas tant que ça. Un ordinateur domestique peut traiter des centaines de milliers de messages par jour.
Comparé à un antispam, l'antivirus est généralement très léger.
Par exemple :
22:28 lagavulin:~/autobounce4# /usr/bin/time -l /usr/local/f-prot/f-prot ./corpus/vir_bagle_h.msg > /dev/null 0.44 real 0.34 user 0.08 sys 2376 maximum resident set size 699 average shared memory size 1054 average unshared data size 128 average unshared stack size 510 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 14 voluntary context switches 302 involuntary context switches
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Fred -- ... I've seen Sun monitors on fire off the side of the multimedia lab. I've seen NTU lights glitter in the dark near the Mail Gate. All these things will be lost in time, like the root partition last week. Time to die... (Peter Gutmann in the scary devil monastery)
Fabien LE LEZ <gramster@gramster.com> écrit:
et surtout, il faut
pas mal de puissance processeur.
Pas tant que ça. Un ordinateur domestique peut traiter des centaines
de milliers de messages par jour.
Comparé à un antispam, l'antivirus est généralement très léger.
Par exemple :
22:28 lagavulin:~/autobounce4# /usr/bin/time -l /usr/local/f-prot/f-prot
./corpus/vir_bagle_h.msg > /dev/null
0.44 real 0.34 user 0.08 sys
2376 maximum resident set size
699 average shared memory size
1054 average unshared data size
128 average unshared stack size
510 page reclaims
0 page faults
0 swaps
0 block input operations
0 block output operations
0 messages sent
0 messages received
0 signals received
14 voluntary context switches
302 involuntary context switches
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en
fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Fred
--
... I've seen Sun monitors on fire off the side of the multimedia lab.
I've seen NTU lights glitter in the dark near the Mail Gate.
All these things will be lost in time, like the root partition last
week. Time to die... (Peter Gutmann in the scary devil monastery)
et surtout, il faut pas mal de puissance processeur.
Pas tant que ça. Un ordinateur domestique peut traiter des centaines de milliers de messages par jour.
Comparé à un antispam, l'antivirus est généralement très léger.
Par exemple :
22:28 lagavulin:~/autobounce4# /usr/bin/time -l /usr/local/f-prot/f-prot ./corpus/vir_bagle_h.msg > /dev/null 0.44 real 0.34 user 0.08 sys 2376 maximum resident set size 699 average shared memory size 1054 average unshared data size 128 average unshared stack size 510 page reclaims 0 page faults 0 swaps 0 block input operations 0 block output operations 0 messages sent 0 messages received 0 signals received 14 voluntary context switches 302 involuntary context switches
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Fred -- ... I've seen Sun monitors on fire off the side of the multimedia lab. I've seen NTU lights glitter in the dark near the Mail Gate. All these things will be lost in time, like the root partition last week. Time to die... (Peter Gutmann in the scary devil monastery)
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Et si je ne m'abuse, f-prot se charge en mémoire à l'excution, ce qui consomme en soi des ressources.
Ici, on utilise clamav en démon, qui répond en un ou deux dixièmes de seconde tout en scannant une dizaine de messages en paralèlle par CPU (PIII 800).
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en
fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Et si je ne m'abuse, f-prot se charge en mémoire à l'excution, ce qui
consomme en soi des ressources.
Ici, on utilise clamav en démon, qui répond en un ou deux dixièmes de
seconde tout en scannant une dizaine de messages en paralèlle par CPU
(PIII 800).
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Et si je ne m'abuse, f-prot se charge en mémoire à l'excution, ce qui consomme en soi des ressources.
Ici, on utilise clamav en démon, qui répond en un ou deux dixièmes de seconde tout en scannant une dizaine de messages en paralèlle par CPU (PIII 800).
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Et si je ne m'abuse, f-prot se charge en mémoire à l'excution, ce qui consomme en soi des ressources.
Ah oui, c'est vraiment un test idiot avec scanner en ligne de commande, aucune optimisation. Le but était de donner un ordre de grandeur, exemple à peu près concret à l'appui.
Ici, on utilise clamav en démon, qui répond en un ou deux dixièmes de seconde tout en scannant une dizaine de messages en paralèlle par CPU (PIII 800).
A noter que, dans mes tests, f-prot en ligne de commande était à peu près aussi rapide que clamav en démon.
Fred -- I have kissed honey lips Felt the healing in her fingertips It burned like fire This burning desire I have spoke with the tongue of angels I have held the hand of the devil It was warm in the night I was cold as a stone (U2, I Still Haven't Found What I'm Looking For)
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en
fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU)
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Et si je ne m'abuse, f-prot se charge en mémoire à l'excution, ce qui
consomme en soi des ressources.
Ah oui, c'est vraiment un test idiot avec scanner en ligne de commande,
aucune optimisation. Le but était de donner un ordre de grandeur,
exemple à peu près concret à l'appui.
Ici, on utilise clamav en démon, qui répond en un ou deux dixièmes de
seconde tout en scannant une dizaine de messages en paralèlle par CPU
(PIII 800).
A noter que, dans mes tests, f-prot en ligne de commande était à peu
près aussi rapide que clamav en démon.
Fred
--
I have kissed honey lips Felt the healing in her fingertips
It burned like fire This burning desire I have spoke with the tongue
of angels I have held the hand of the devil It was warm in the night
I was cold as a stone (U2, I Still Haven't Found What I'm Looking For)
Disons une demie-seconde pour scanner un mail (infecté). Ca nous en fait 120 à la minute, donc 7200 à l'heure, donc 172800 en une journée.
Sur ça :
CPU: Pentium II/Pentium II Xeon/Celeron (333.05-MHz 686-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Et si je ne m'abuse, f-prot se charge en mémoire à l'excution, ce qui consomme en soi des ressources.
Ah oui, c'est vraiment un test idiot avec scanner en ligne de commande, aucune optimisation. Le but était de donner un ordre de grandeur, exemple à peu près concret à l'appui.
Ici, on utilise clamav en démon, qui répond en un ou deux dixièmes de seconde tout en scannant une dizaine de messages en paralèlle par CPU (PIII 800).
A noter que, dans mes tests, f-prot en ligne de commande était à peu près aussi rapide que clamav en démon.
Fred -- I have kissed honey lips Felt the healing in her fingertips It burned like fire This burning desire I have spoke with the tongue of angels I have held the hand of the devil It was warm in the night I was cold as a stone (U2, I Still Haven't Found What I'm Looking For)
Renaud RAKOTOMALALA
JustMe écrit:
et il faut aussi que le destinataire accepte ce genre de filtrage.
Le service se protège contre des bombes logicielles. L'utilisateur n'a pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une attaque de virus.
non le courriel est un espace privatif ou seul l'interesser peut intervenir (sauf autorisation de sa part). C'est à l'hebergeur de savoir gérer ce type de trafic.
Sauf à dire qu'il est inscrit dans les CGV et explicitement rappelé au client lors de la souscription du contrat, que tous les mails sans exception ferons l'objet d'un test antiviral, celui-ci pouvant conduire à la destruction du message et donc perte d'information.
Pour rappel l'analyse antiviral, tout comme celui du spam (dans une moindre mesure) n'est pas fiable à 100% ce qui signifie qu'il ya un risque de perte d'information et potentiellement de préjudice.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux. Et un virus n'est pas de la correspondance privée.
Jusqu'à ce que la LCEN ne soit definitivement adopté (l'est elle ?) tout trafic courriel est privé et sans exception ! La LCEN assoupli les règles en la matière pour le plus grand bonheur de certain :(
et il faut aussi que le destinataire accepte ce genre de filtrage.
Le service se protège contre des bombes logicielles. L'utilisateur n'a
pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une
attaque de virus.
non le courriel est un espace privatif ou seul l'interesser peut
intervenir (sauf autorisation de sa part). C'est à l'hebergeur de savoir
gérer ce type de trafic.
Sauf à dire qu'il est inscrit dans les CGV et explicitement rappelé au
client lors de la souscription du contrat, que tous les mails sans
exception ferons l'objet d'un test antiviral, celui-ci pouvant conduire
à la destruction du message et donc perte d'information.
Pour rappel l'analyse antiviral, tout comme celui du spam (dans une
moindre mesure) n'est pas fiable à 100% ce qui signifie qu'il ya un
risque de perte d'information et potentiellement de préjudice.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux.
Et un virus n'est pas de la correspondance privée.
Jusqu'à ce que la LCEN ne soit definitivement adopté (l'est elle ?) tout
trafic courriel est privé et sans exception ! La LCEN assoupli les
règles en la matière pour le plus grand bonheur de certain :(
et il faut aussi que le destinataire accepte ce genre de filtrage.
Le service se protège contre des bombes logicielles. L'utilisateur n'a pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une attaque de virus.
non le courriel est un espace privatif ou seul l'interesser peut intervenir (sauf autorisation de sa part). C'est à l'hebergeur de savoir gérer ce type de trafic.
Sauf à dire qu'il est inscrit dans les CGV et explicitement rappelé au client lors de la souscription du contrat, que tous les mails sans exception ferons l'objet d'un test antiviral, celui-ci pouvant conduire à la destruction du message et donc perte d'information.
Pour rappel l'analyse antiviral, tout comme celui du spam (dans une moindre mesure) n'est pas fiable à 100% ce qui signifie qu'il ya un risque de perte d'information et potentiellement de préjudice.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux. Et un virus n'est pas de la correspondance privée.
Jusqu'à ce que la LCEN ne soit definitivement adopté (l'est elle ?) tout trafic courriel est privé et sans exception ! La LCEN assoupli les règles en la matière pour le plus grand bonheur de certain :(
Le service se protège contre des bombes logicielles. L'utilisateur n'a pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une attaque de virus.
non le courriel est un espace privatif ou seul l'interesser peut intervenir (sauf autorisation de sa part). C'est à l'hebergeur de savoir gérer ce type de trafic.
Faux, un virus n'est pas un "espace privatif" ou quoi que ce soit de ce genre. Un relai par contre, est un service privé.
D'autre part, les relais ont depuis la nuit de temps des restrictions sur ce qu'ils sont capables de relayer. Par exemple, ils refusent les messages au delà d'une certaine taille.
Un relai n'a jamais été contraint de se battre jusqu'à la mort pour relayer n'importe quoi, notement des messages directement ou indirectement dangereux pour lui même.
Sauf à dire qu'il est inscrit dans les CGV et explicitement rappelé au client lors de la souscription du contrat, que tous les mails sans exception ferons l'objet d'un test antiviral, celui-ci pouvant conduire à la destruction du message et donc perte d'information.
Ce procole (pas si bon, soit di en passant), n'est nullement nessessaire.
Pour rappel l'analyse antiviral, tout comme celui du spam (dans une moindre mesure) n'est pas fiable à 100% ce qui signifie qu'il ya un risque de perte d'information et potentiellement de préjudice.
Comparez donc ce préjudice potentiel à celui que vont connaitre ceux qui partent en vacances un mois et dont la boîte sera en dépassement de quota et qui perdra à coup sûr bon nombre de messages.
Comparez le aussi au préjudice causé à tous les utilisateurs par l'un d'eux qui saturera le relai et fera perdre ou ralentira les messages de tout le monde.
N'oubliez pas de le comparer au surcoût que le relai de virus peut engendrer, surcoût qui sera reporté sur les utilisateurs.
La mise en place d'un antivirus est une mesure proportionnée aux risques actuels.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux. Et un virus n'est pas de la correspondance privée.
Jusqu'à ce que la LCEN ne soit definitivement adopté (l'est elle ?) tout trafic courriel est privé et sans exception ! La LCEN assoupli les règles en la matière pour le plus grand bonheur de certain :(
Faux, la LCEN ne change rien au statut privé ou non d'un message. Le conseil constitutionnel l'a rappelé.
Le service se protège contre des bombes logicielles. L'utilisateur n'a
pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une
attaque de virus.
non le courriel est un espace privatif ou seul l'interesser peut
intervenir (sauf autorisation de sa part). C'est à l'hebergeur de savoir
gérer ce type de trafic.
Faux, un virus n'est pas un "espace privatif" ou quoi que ce soit de
ce genre. Un relai par contre, est un service privé.
D'autre part, les relais ont depuis la nuit de temps des restrictions
sur ce qu'ils sont capables de relayer. Par exemple, ils refusent les
messages au delà d'une certaine taille.
Un relai n'a jamais été contraint de se battre jusqu'à la mort pour
relayer n'importe quoi, notement des messages directement ou
indirectement dangereux pour lui même.
Sauf à dire qu'il est inscrit dans les CGV et explicitement rappelé au
client lors de la souscription du contrat, que tous les mails sans
exception ferons l'objet d'un test antiviral, celui-ci pouvant conduire
à la destruction du message et donc perte d'information.
Ce procole (pas si bon, soit di en passant), n'est nullement
nessessaire.
Pour rappel l'analyse antiviral, tout comme celui du spam (dans une
moindre mesure) n'est pas fiable à 100% ce qui signifie qu'il ya un
risque de perte d'information et potentiellement de préjudice.
Comparez donc ce préjudice potentiel à celui que vont connaitre ceux
qui partent en vacances un mois et dont la boîte sera en dépassement
de quota et qui perdra à coup sûr bon nombre de messages.
Comparez le aussi au préjudice causé à tous les utilisateurs par l'un
d'eux qui saturera le relai et fera perdre ou ralentira les messages
de tout le monde.
N'oubliez pas de le comparer au surcoût que le relai de virus peut
engendrer, surcoût qui sera reporté sur les utilisateurs.
La mise en place d'un antivirus est une mesure proportionnée aux
risques actuels.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux.
Et un virus n'est pas de la correspondance privée.
Jusqu'à ce que la LCEN ne soit definitivement adopté (l'est elle ?) tout
trafic courriel est privé et sans exception ! La LCEN assoupli les
règles en la matière pour le plus grand bonheur de certain :(
Faux, la LCEN ne change rien au statut privé ou non d'un message.
Le conseil constitutionnel l'a rappelé.
Le service se protège contre des bombes logicielles. L'utilisateur n'a pas à choisir s'il accepte que son hébergeur puisse être l'objet d'une attaque de virus.
non le courriel est un espace privatif ou seul l'interesser peut intervenir (sauf autorisation de sa part). C'est à l'hebergeur de savoir gérer ce type de trafic.
Faux, un virus n'est pas un "espace privatif" ou quoi que ce soit de ce genre. Un relai par contre, est un service privé.
D'autre part, les relais ont depuis la nuit de temps des restrictions sur ce qu'ils sont capables de relayer. Par exemple, ils refusent les messages au delà d'une certaine taille.
Un relai n'a jamais été contraint de se battre jusqu'à la mort pour relayer n'importe quoi, notement des messages directement ou indirectement dangereux pour lui même.
Sauf à dire qu'il est inscrit dans les CGV et explicitement rappelé au client lors de la souscription du contrat, que tous les mails sans exception ferons l'objet d'un test antiviral, celui-ci pouvant conduire à la destruction du message et donc perte d'information.
Ce procole (pas si bon, soit di en passant), n'est nullement nessessaire.
Pour rappel l'analyse antiviral, tout comme celui du spam (dans une moindre mesure) n'est pas fiable à 100% ce qui signifie qu'il ya un risque de perte d'information et potentiellement de préjudice.
Comparez donc ce préjudice potentiel à celui que vont connaitre ceux qui partent en vacances un mois et dont la boîte sera en dépassement de quota et qui perdra à coup sûr bon nombre de messages.
Comparez le aussi au préjudice causé à tous les utilisateurs par l'un d'eux qui saturera le relai et fera perdre ou ralentira les messages de tout le monde.
N'oubliez pas de le comparer au surcoût que le relai de virus peut engendrer, surcoût qui sera reporté sur les utilisateurs.
La mise en place d'un antivirus est une mesure proportionnée aux risques actuels.
Sinon, détournement de correspondance privée, toussa.... Voir les
"détournement", comme vous dites, non frauduleux. Et un virus n'est pas de la correspondance privée.
Jusqu'à ce que la LCEN ne soit definitivement adopté (l'est elle ?) tout trafic courriel est privé et sans exception ! La LCEN assoupli les règles en la matière pour le plus grand bonheur de certain :(
Faux, la LCEN ne change rien au statut privé ou non d'un message. Le conseil constitutionnel l'a rappelé.
