Ce groupe n'a plus aucune raison d'être : les sujets liés à la prise de
vue sont en charte sur fr.rec.photo, le post-traitement sur
fr.rec.photo.labo.numerique
Par ailleurs le groupe est illisible puisqu'on y parle jeux video, ou
mac vs PC, mais surtout pas photo numérique.
Je propose donc la destruction de ce groupe mal foutu, et l'utilisation
des groupes cités pour la faible part des messages qui y sont postés en
charte.
Suite sur fr.usenet.forums.evolution, puisque c'est là que se discutent
les créations et destructions de groupes.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Il reste néanmoins possible de voir si le filtrage est au niveau TCP ou dû à une analyse protocolaire sur une couche supérieure: déjà, si le "3 way handshake" (SYN/SYN-ACK/ACK) a lieu (facilement vérifiable via un simple "telnet"), c'est qu'a priori ce n'est pas un filtrage au niveau du port TCP...
[...]
Pas forcement. Dans le cas de SSH et NNTP, le "application level firewall" peut etablir la communication avec le server sur reception du SYN et le protocol peut etre identifié immediatement (car pour SSH et NNTP, un message est envoyé a la connection par le server), donc il peut ne rien renvoyer au client, ou renvoyer un ICMP ou un RST...
-- Stephane
2011-10-22, 21:11(+02), Bruno Tréguier:
[...]
Il reste néanmoins possible de voir si le filtrage est au niveau TCP ou
dû à une analyse protocolaire sur une couche supérieure: déjà, si le "3
way handshake" (SYN/SYN-ACK/ACK) a lieu (facilement vérifiable via un
simple "telnet"), c'est qu'a priori ce n'est pas un filtrage au niveau
du port TCP...
[...]
Pas forcement. Dans le cas de SSH et NNTP, le "application level
firewall" peut etablir la communication avec le server sur
reception du SYN et le protocol peut etre identifié
immediatement (car pour SSH et NNTP, un message est envoyé a la
connection par le server), donc il peut ne rien renvoyer au
client, ou renvoyer un ICMP ou un RST...
Il reste néanmoins possible de voir si le filtrage est au niveau TCP ou dû à une analyse protocolaire sur une couche supérieure: déjà, si le "3 way handshake" (SYN/SYN-ACK/ACK) a lieu (facilement vérifiable via un simple "telnet"), c'est qu'a priori ce n'est pas un filtrage au niveau du port TCP...
[...]
Pas forcement. Dans le cas de SSH et NNTP, le "application level firewall" peut etablir la communication avec le server sur reception du SYN et le protocol peut etre identifié immediatement (car pour SSH et NNTP, un message est envoyé a la connection par le server), donc il peut ne rien renvoyer au client, ou renvoyer un ICMP ou un RST...
-- Stephane
Bruno Tréguier
Le 22/10/2011 à 21:27, Stephane CHAZELAS a écrit :
2011-10-22, 21:11(+02), Bruno Tréguier: [...]
Il reste néanmoins possible de voir si le filtrage est au niveau TCP ou dû à une analyse protocolaire sur une couche supérieure: déjà, si le "3 way handshake" (SYN/SYN-ACK/ACK) a lieu (facilement vérifiable via un simple "telnet"), c'est qu'a priori ce n'est pas un filtrage au niveau du port TCP...
[...]
Pas forcement. Dans le cas de SSH et NNTP, le "application level firewall" peut etablir la communication avec le server sur reception du SYN et le protocol peut etre identifié immediatement (car pour SSH et NNTP, un message est envoyé a la connection par le server), donc il peut ne rien renvoyer au client, ou renvoyer un ICMP ou un RST...
Effectivement, je ne me plaçais pas, pour ma part, dans une optique de proxy transparent, mais dans celle consistant à "tuer" une connexion en cas de détection d'un trafic illicite. Cela dit vous avez parfaitement raison. NNTP, SSH, SMTP et quelques autres peuvent être bloqués de cette manière.
Cordialement,
-- Bruno Tréguier
Le 22/10/2011 à 21:27, Stephane CHAZELAS a écrit :
2011-10-22, 21:11(+02), Bruno Tréguier:
[...]
Il reste néanmoins possible de voir si le filtrage est au niveau TCP ou
dû à une analyse protocolaire sur une couche supérieure: déjà, si le "3
way handshake" (SYN/SYN-ACK/ACK) a lieu (facilement vérifiable via un
simple "telnet"), c'est qu'a priori ce n'est pas un filtrage au niveau
du port TCP...
[...]
Pas forcement. Dans le cas de SSH et NNTP, le "application level
firewall" peut etablir la communication avec le server sur
reception du SYN et le protocol peut etre identifié
immediatement (car pour SSH et NNTP, un message est envoyé a la
connection par le server), donc il peut ne rien renvoyer au
client, ou renvoyer un ICMP ou un RST...
Effectivement, je ne me plaçais pas, pour ma part, dans une optique de
proxy transparent, mais dans celle consistant à "tuer" une connexion en
cas de détection d'un trafic illicite. Cela dit vous avez parfaitement
raison. NNTP, SSH, SMTP et quelques autres peuvent être bloqués de cette
manière.
Le 22/10/2011 à 21:27, Stephane CHAZELAS a écrit :
2011-10-22, 21:11(+02), Bruno Tréguier: [...]
Il reste néanmoins possible de voir si le filtrage est au niveau TCP ou dû à une analyse protocolaire sur une couche supérieure: déjà, si le "3 way handshake" (SYN/SYN-ACK/ACK) a lieu (facilement vérifiable via un simple "telnet"), c'est qu'a priori ce n'est pas un filtrage au niveau du port TCP...
[...]
Pas forcement. Dans le cas de SSH et NNTP, le "application level firewall" peut etablir la communication avec le server sur reception du SYN et le protocol peut etre identifié immediatement (car pour SSH et NNTP, un message est envoyé a la connection par le server), donc il peut ne rien renvoyer au client, ou renvoyer un ICMP ou un RST...
Effectivement, je ne me plaçais pas, pour ma part, dans une optique de proxy transparent, mais dans celle consistant à "tuer" une connexion en cas de détection d'un trafic illicite. Cela dit vous avez parfaitement raison. NNTP, SSH, SMTP et quelques autres peuvent être bloqués de cette manière.
Cordialement,
-- Bruno Tréguier
siger
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache a éc rit :
Je ne trouve pas la recherche de TB très puissante. Disons plutôt que celle de google/gmail est très en avance.
Tu peux détailler ?
(attention, TB ça peut être The Bat)
-- siger
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache <pehache.7@gmail.com> a éc rit :
Je ne trouve pas la recherche de TB très puissante. Disons plutôt que
celle de google/gmail est très en avance.
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache a éc rit :
Je ne trouve pas la recherche de TB très puissante. Disons plutôt que celle de google/gmail est très en avance.
Tu peux détailler ?
(attention, TB ça peut être The Bat)
-- siger
pehache
Le 22/10/11 23:20, siger a écrit :
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache a écrit :
Je ne trouve pas la recherche de TB très puissante. Disons plutôt que celle de google/gmail est très en avance.
Tu peux détailler ?
Dans la recherche google, inutile de préciser dans quel champs tu fais la recherche. Aussi, une orthographe erronée te renvoie quand même des résultats pertinents. Et la recherche est très rapide, les mails étant entièrement indexés.
Bref, gmail profite de l'efficacité des algos de recherche de google.
-- pehache
Le 22/10/11 23:20, siger a écrit :
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache <pehache.7@gmail.com> a écrit :
Je ne trouve pas la recherche de TB très puissante. Disons plutôt que
celle de google/gmail est très en avance.
Tu peux détailler ?
Dans la recherche google, inutile de préciser dans quel champs tu fais
la recherche. Aussi, une orthographe erronée te renvoie quand même des
résultats pertinents. Et la recherche est très rapide, les mails étant
entièrement indexés.
Bref, gmail profite de l'efficacité des algos de recherche de google.
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache a écrit :
Je ne trouve pas la recherche de TB très puissante. Disons plutôt que celle de google/gmail est très en avance.
Tu peux détailler ?
Dans la recherche google, inutile de préciser dans quel champs tu fais la recherche. Aussi, une orthographe erronée te renvoie quand même des résultats pertinents. Et la recherche est très rapide, les mails étant entièrement indexés.
Bref, gmail profite de l'efficacité des algos de recherche de google.
-- pehache
siger
Le Sat, 22 Oct 2011 23:27:28 +0200, pehache a éc rit :
Le 22/10/11 23:20, siger a écrit :
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache a écrit :
Je ne trouve pas la recherche de TB très puissante. Disons plutô t que celle de google/gmail est très en avance.
Tu peux détailler ?
Dans la recherche google, inutile de préciser dans quel champs tu fa is la recherche.
C'est le cas dans tout logiciel où tu peux choisir de chercher dans to ut. Mais c'est vrai qu'avec la vitesse dont tu parles plus bas, on n'a pas à choisir de restreindre la recherche pour aller plus vite.
Aussi, une orthographe erronée te renvoie quand même des résulta ts pertinents.
Bien ça.
Et la recherche est très rapide, les mails étant entièrement ind exés.
Vu la taille des disques durs aujourd'hui, il n'y a pas de courrielleur qui a l'option "indexage" ? Ni de logiciel à part, comme ça existe p our les DOC, PDF, ODT, TXT, etc. ?
Bref, gmail profite de l'efficacité des algos de recherche de google .
-- siger
Le Sat, 22 Oct 2011 23:27:28 +0200, pehache <pehache.7@gmail.com> a éc rit :
Le 22/10/11 23:20, siger a écrit :
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache <pehache.7@gmail.com> a
écrit :
Je ne trouve pas la recherche de TB très puissante. Disons plutô t que
celle de google/gmail est très en avance.
Tu peux détailler ?
Dans la recherche google, inutile de préciser dans quel champs tu fa is
la recherche.
C'est le cas dans tout logiciel où tu peux choisir de chercher dans to ut.
Mais c'est vrai qu'avec la vitesse dont tu parles plus bas, on n'a pas à
choisir de restreindre la recherche pour aller plus vite.
Aussi, une orthographe erronée te renvoie quand même des résulta ts
pertinents.
Bien ça.
Et la recherche est très rapide, les mails étant entièrement ind exés.
Vu la taille des disques durs aujourd'hui, il n'y a pas de courrielleur
qui a l'option "indexage" ? Ni de logiciel à part, comme ça existe p our
les DOC, PDF, ODT, TXT, etc. ?
Bref, gmail profite de l'efficacité des algos de recherche de google .
Le Sat, 22 Oct 2011 23:27:28 +0200, pehache a éc rit :
Le 22/10/11 23:20, siger a écrit :
Le Sat, 22 Oct 2011 16:18:04 +0200, pehache a écrit :
Je ne trouve pas la recherche de TB très puissante. Disons plutô t que celle de google/gmail est très en avance.
Tu peux détailler ?
Dans la recherche google, inutile de préciser dans quel champs tu fa is la recherche.
C'est le cas dans tout logiciel où tu peux choisir de chercher dans to ut. Mais c'est vrai qu'avec la vitesse dont tu parles plus bas, on n'a pas à choisir de restreindre la recherche pour aller plus vite.
Aussi, une orthographe erronée te renvoie quand même des résulta ts pertinents.
Bien ça.
Et la recherche est très rapide, les mails étant entièrement ind exés.
Vu la taille des disques durs aujourd'hui, il n'y a pas de courrielleur qui a l'option "indexage" ? Ni de logiciel à part, comme ça existe p our les DOC, PDF, ODT, TXT, etc. ?
Bref, gmail profite de l'efficacité des algos de recherche de google .
-- siger
pehache
Le 21/10/11 11:19, Olivier Miakinen a écrit :
Bonjour,
Le 21/10/2011 08:49, pehache répondait à Gérald Niel :
Dans mon cas le filtrage ne se fait pas que sur le port, mais aussi sur le protocole. nntp est bloqué, quel que soit le port.
Heuh... mes modestes compétences me font quand même douter de la possibiliter de filtrer sur le protocole. Puisque dans les deux cas c'est une connexion TCP qui est initiée. À moins que ça se passe une couche au dessus ?
Je ne sais pas grand chose du contexte puisque le fil semble avoir démarré ailleurs, mais sauf besoin spécifique j'ai du mal à imaginer que quelqu'un mette en place un filtrage de protocole sur un numéro de port.
Contexte : accès au grand ternet derrière un grand méchant proxy :-)
Je ne sais pas, je constate. Impossible d'établir une quelconque connection nntp, même sur le port 80 (news de free par exemple), alors que depuis chez moi ça marche.
Et une connexion directe HTTP fonctionne ?
Non. Il faut passer par le proxy obligatoirement.
-- pehache
Le 21/10/11 11:19, Olivier Miakinen a écrit :
Bonjour,
Le 21/10/2011 08:49, pehache répondait à Gérald Niel :
Dans mon cas le filtrage ne se fait pas que sur le port, mais aussi sur
le protocole. nntp est bloqué, quel que soit le port.
Heuh... mes modestes compétences me font quand même douter de la
possibiliter de filtrer sur le protocole.
Puisque dans les deux cas c'est une connexion TCP qui est initiée.
À moins que ça se passe une couche au dessus ?
Je ne sais pas grand chose du contexte puisque le fil semble avoir
démarré ailleurs, mais sauf besoin spécifique j'ai du mal à imaginer
que quelqu'un mette en place un filtrage de protocole sur un numéro
de port.
Contexte : accès au grand ternet derrière un grand méchant proxy :-)
Je ne sais pas, je constate. Impossible d'établir une quelconque
connection nntp, même sur le port 80 (news de free par exemple), alors
que depuis chez moi ça marche.
Le 21/10/2011 08:49, pehache répondait à Gérald Niel :
Dans mon cas le filtrage ne se fait pas que sur le port, mais aussi sur le protocole. nntp est bloqué, quel que soit le port.
Heuh... mes modestes compétences me font quand même douter de la possibiliter de filtrer sur le protocole. Puisque dans les deux cas c'est une connexion TCP qui est initiée. À moins que ça se passe une couche au dessus ?
Je ne sais pas grand chose du contexte puisque le fil semble avoir démarré ailleurs, mais sauf besoin spécifique j'ai du mal à imaginer que quelqu'un mette en place un filtrage de protocole sur un numéro de port.
Contexte : accès au grand ternet derrière un grand méchant proxy :-)
Je ne sais pas, je constate. Impossible d'établir une quelconque connection nntp, même sur le port 80 (news de free par exemple), alors que depuis chez moi ça marche.
Et une connexion directe HTTP fonctionne ?
Non. Il faut passer par le proxy obligatoirement.
-- pehache
Erwan David
siger écrivait :
Vu la taille des disques durs aujourd'hui, il n'y a pas de courrielleur qui a l'option "indexage" ? Ni de logiciel à part, comme ça existe pour les DOC, PDF, ODT, TXT, etc. ?
Thunderbird l'a (via l'option de "recherche globale")
Pour l'indexation autre il ya des logiciels comme mairix.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
siger <guinness@hic.invalid> écrivait :
Vu la taille des disques durs aujourd'hui, il n'y a pas de
courrielleur qui a l'option "indexage" ? Ni de logiciel à part, comme
ça existe pour les DOC, PDF, ODT, TXT, etc. ?
Thunderbird l'a (via l'option de "recherche globale")
Pour l'indexation autre il ya des logiciels comme mairix.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Vu la taille des disques durs aujourd'hui, il n'y a pas de courrielleur qui a l'option "indexage" ? Ni de logiciel à part, comme ça existe pour les DOC, PDF, ODT, TXT, etc. ?
Thunderbird l'a (via l'option de "recherche globale")
Pour l'indexation autre il ya des logiciels comme mairix.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
pehache
Le 23/10/11 18:35, Erwan David a écrit :
siger écrivait :
Vu la taille des disques durs aujourd'hui, il n'y a pas de courrielleur qui a l'option "indexage" ? Ni de logiciel à part, comme ça existe pour les DOC, PDF, ODT, TXT, etc. ?
Thunderbird l'a (via l'option de "recherche globale")
Pour l'indexation autre il ya des logiciels comme mairix.
Je ne sais pas comment TB indexe, mais ce qui est certain c'est que la recherche dans TB n'a pas l'instantanéité de la recherche dans gmail.
-- pehache
Le 23/10/11 18:35, Erwan David a écrit :
siger<guinness@hic.invalid> écrivait :
Vu la taille des disques durs aujourd'hui, il n'y a pas de
courrielleur qui a l'option "indexage" ? Ni de logiciel à part, comme
ça existe pour les DOC, PDF, ODT, TXT, etc. ?
Thunderbird l'a (via l'option de "recherche globale")
Pour l'indexation autre il ya des logiciels comme mairix.
Je ne sais pas comment TB indexe, mais ce qui est certain c'est que la
recherche dans TB n'a pas l'instantanéité de la recherche dans gmail.
Vu la taille des disques durs aujourd'hui, il n'y a pas de courrielleur qui a l'option "indexage" ? Ni de logiciel à part, comme ça existe pour les DOC, PDF, ODT, TXT, etc. ?
Thunderbird l'a (via l'option de "recherche globale")
Pour l'indexation autre il ya des logiciels comme mairix.
Je ne sais pas comment TB indexe, mais ce qui est certain c'est que la recherche dans TB n'a pas l'instantanéité de la recherche dans gmail.
-- pehache
Olivier Miakinen
Le 23/10/2011 00:09, pehache m'a répondu :
Je ne sais pas, je constate. Impossible d'établir une quelconque connection nntp, même sur le port 80 (news de free par exemple), alors que depuis chez moi ça marche.
Et une connexion directe HTTP fonctionne ?
Non. Il faut passer par le proxy obligatoirement.
Et donc, cela confirme qu'il n'y a pas besoin d'un filtrage de protocole pour expliquer ce comportement : une simple fermeture du port suffit.
-- Olivier Miakinen
Le 23/10/2011 00:09, pehache m'a répondu :
Je ne sais pas, je constate. Impossible d'établir une quelconque
connection nntp, même sur le port 80 (news de free par exemple), alors
que depuis chez moi ça marche.
Et une connexion directe HTTP fonctionne ?
Non. Il faut passer par le proxy obligatoirement.
Et donc, cela confirme qu'il n'y a pas besoin d'un filtrage de protocole
pour expliquer ce comportement : une simple fermeture du port suffit.
Je ne sais pas, je constate. Impossible d'établir une quelconque connection nntp, même sur le port 80 (news de free par exemple), alors que depuis chez moi ça marche.
Et une connexion directe HTTP fonctionne ?
Non. Il faut passer par le proxy obligatoirement.
Et donc, cela confirme qu'il n'y a pas besoin d'un filtrage de protocole pour expliquer ce comportement : une simple fermeture du port suffit.
-- Olivier Miakinen
pehache
Le 24/10/11 11:32, Olivier Miakinen a écrit :
Le 23/10/2011 00:09, pehache m'a répondu :
Je ne sais pas, je constate. Impossible d'établir une quelconque connection nntp, même sur le port 80 (news de free par exemple), alors que depuis chez moi ça marche.
Et une connexion directe HTTP fonctionne ?
Non. Il faut passer par le proxy obligatoirement.
Et donc, cela confirme qu'il n'y a pas besoin d'un filtrage de protocole pour expliquer ce comportement : une simple fermeture du port suffit.
Pourtant le http sur port 80 passe. Donc il y a forcément un filtrage sur le protocole, non ?
-- pehache
Le 24/10/11 11:32, Olivier Miakinen a écrit :
Le 23/10/2011 00:09, pehache m'a répondu :
Je ne sais pas, je constate. Impossible d'établir une quelconque
connection nntp, même sur le port 80 (news de free par exemple), alors
que depuis chez moi ça marche.
Et une connexion directe HTTP fonctionne ?
Non. Il faut passer par le proxy obligatoirement.
Et donc, cela confirme qu'il n'y a pas besoin d'un filtrage de protocole
pour expliquer ce comportement : une simple fermeture du port suffit.
Pourtant le http sur port 80 passe. Donc il y a forcément un filtrage
sur le protocole, non ?
Je ne sais pas, je constate. Impossible d'établir une quelconque connection nntp, même sur le port 80 (news de free par exemple), alors que depuis chez moi ça marche.
Et une connexion directe HTTP fonctionne ?
Non. Il faut passer par le proxy obligatoirement.
Et donc, cela confirme qu'il n'y a pas besoin d'un filtrage de protocole pour expliquer ce comportement : une simple fermeture du port suffit.
Pourtant le http sur port 80 passe. Donc il y a forcément un filtrage sur le protocole, non ?
