Effectivement, quand tu resoud smtp.wanadoo.fr sans utiliser les serveurs DNS internes à wanadoo, l'adresse IP qui t'es renvoyée ne permet pas de relayer les mails.
Ou est le probleme ? (si ce n'est que un peu de documentation m'aurait fait gagner quelques heures a debugger ce binz). Con, Incompetent...
je te trouve un peu rapide en conclusion la.
Tu es assez malin pour definir l'adresse IP du serveur DNS de wanadoo dans ton /etc/hosts non ?
chez moi quand je me connecte (IP dynamique), je recupere aussi l'@ des serveurs internes à wanadoo et je les définis dans mon DNS interne ...
wanadoo a choisit d'isoler les serveurs destinés a leur clients des serveurs accessibles à l'extérieur. D'un point de vue sécurité c'est à mon avis une bonne chose !!
oui ma phrase est trompeuse ... puisque nmap tente d'echaper aux filtrages. Néanmoins avec un firewall qui ne laisse passer QUE ce qui est necessaire, nmap n'obtient rien de plus que "port filtered", et avec un IDS qui detecte le scan et filtre l'IP source, le résultat de ton scan nmap est incomplet ...
pour resoudre le probleme d'aujourd'hui telnet ou nc (netcat) sont les outils les plus appropriés.
smtp.wanadoo.fr est en fait 2 machines avec 2 adresses IP differentes selon que tu resoud le nom avec le DNS normal (externe a wanadoo) ou interne à wanadoo.
le serveur smtp.wanadoo.fr interne (@IP dans DNS interne) n'est evidement pas joingnable depuis l'exterieur !!, le DNS interne de wandoo non plus d'ailleur. Faut quand même pas les prendre pour plus cons qu'ils ne sont !!
Donc oui, les abonnés de wanadoo peuvent utiliser les relais smtp de wanadoo ... quelle nouvelle !!
C'est toi le parano.
Si le serveur refuse le telnet sur le port 25, il ne peut pas recevoir de mail. un point c'est tout.
Ton nmap il ne te sert à rien de plus [dans ce cas la] qu'a faire chier le monde et à prouver que tu capte quedalle aux réseaux IP.
D'ailleur il y a des chances que les scans nmap soient filtré en grande partie (car non essentiel au fonctionnement d'un serveur mail - meme dangereux) alors que la connection sur le port tcp/25, si tu la filtre tu peux aussi eteindre le serveur mail :-)
J'avais écrit: >> De plus je viens d'essayer des connexions sur le port SMTP des @IP données dans cette nouvelle, les connexions semblent ne pas aboutir, ca va etre dur de relayer du spam avec ces machines !!
Ta réponse: >J'espère que ce n'est pas avec ping que tu as essayé.
Humm, il va falloir que tu lise un cours réseau juste une fois. Quelques indices qui prouve tes lacunes:
ping ==> icmp != connecté
port SMTP ==> tcp/25
De plus nmap n'est pas le meilleur moyen de tester si tu peux te connecter en tcp sur le port 25, non. C'est comme utiliser un marteau piqueur pour planter un clou, ca peut marcher ... mais essaye telnet ou nc plutot !!
De plus nmap est assez dangereux à utiliser: une erreur d'argument et c'est un portscan complet qui est lancé ... très facile a repérer !!
En gros tu as compris le problème, mais
1/ en vérifiant cela semble plus de la désinformation qu'autre chose.
2/ smtp c'est courier sortant et entrant
3/ les admins ne vont pas sauter sur toutes les listes pseudo-maintenues de serveurs open-relai. rien qu'a voir le temps qu'il faut pour patcher IIS contre redcode, on se dit que le spam n'est pas pres d'etre traité correctement ...
Hummm, je me demande si cette nouvelle n'est pas un peu bidonnée:
chez wanadoo, les serveurs SMTP qui acceptent de relayer le courier ne sont accessibles que de l'interieur de wanadoo (c'est a dire que par leurs abonnés). Les serveurs qui sont accessibles de l'extérieur (smtp.wanadoo.fr par exemple) ne relai le mail POUR PERSONNE (meme les abonnés).
La machine smtp.wanadoo.fr est définie avec 2 adresses IP différentes selon le DNS interogé (interne a wanadoo ou externe), ce sont 2 machines différentes.
De plus je viens d'essayer des connexions sur le port SMTP des @IP données dans cette nouvelle, les connexions semblent ne pas aboutir, ca va etre dur de relayer du spam avec ces machines !!
Vous voudriez pas faire tourner ce site sous IIS plutot ?
parce que la avec tous les problemes (DNS, onduleur ...) vous faites chuter les statistiques d'uptime d'apache/linux !!
Merci beaucoup, ca fait un moment que j'ai pas fait de mesures de performance et je ne connaissais pas ces 2 projets opensource. ==> bookmark.
Je suis tout de même agréablement surpris par les chiffres que tu donnes. Ils sont plus qu'honnorable pour la configuration matérielle utilisée.
Ca me fait penser à un jour ou un collegue avait des temps de réponse terrible ... en fait les pages qu'il récupérait avec son injecteur etaient toutes des erreurs 404 :-)) Mais vu ta réponse je vois que tu as du étudier tout cela de près.
humm ... comment a tu fait tes tests ?
avec quel injecteur ??
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
de plus 1 requete != 1 utilisateur:
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
bref prenons des pincettes pour manipuler ces chiffres.
Bon je rebondis de suite sur cette phrase: Java c'est lourd,c'est lent, ....
Je ne suis pas un trolleur fou et je vais donc argumenter.
Java est une solution technique (c'est pas seulement un language) forcement lourde puisque le code généré n'est pas adapté au CPU mais à une machine virtuelle [quand on a pas un cpu JAVA]. Ca ressemble à executer du code pour x86 sur un macIntosh dans un emulateur.
Les fanatiques de JAVA vont dire que ca marche quand meme et ils auront raison. Mais le même programme compilé pour l'architecture cible et écrit correctement sera forcement moins gourmand en ressources CPU/RAM/... et donc potentiellement plus rapide puique seul l'algo utile tournera.
Ensuite les mêmes fanatiques de JAVA nous reparleront des tests qui ont montré un code JAVA tourner aussi vite que son homologue en C, mais ils oublieront que cela depend de la charge de la machine, que en JAVA sur beaucoup de plateformes c'est la JVM qui gère le scheduling des threads JAVA [et elle est moins douée que le scheduleur de l'OS, ca peut même bloquer tous les threads JAVA sur un seul CPU !!] et enfin que dans le cadre de ces tests, le code JAVA avait été soigné [de vous à moi, entre un développeur C et un développeur JAVA, lequel des deux risque de mieux soigner son algo ? celui qui ne se pose même pas la question de libérer la mémoire et espère le passage d'un garbage collector à un moment ou son appli n'aura pas besoin de trop de CPU ??]
Je ne suis pas un fanatique de JAVA, mais je vois bien les avantages des solutions JAVA quand même:
Un seul package qui s'installe sur toutes les plateformes. C'est le seul avantage mais il est de taille pour tous ceux qui ont déjà VRAIMENT produit du logiciel, cela supprime des hommes/mois de boulot de packaging, tests ...
Ce package multiplateforme est donc tout indiqué pour le web ou l'architecture du client est inconnue (applets). Pour les servlets ca se discute plus, mais ca fait le bonheur des vendeurs de serveurs ... et des developpeurs. Si JAVA est plutot une solution d'architecture, il a su séduire beaucoup de développeurs en tant que langage. Du coup il y a souvent confusion ...
Il y a aussi un autre phénomène qui entre en jeu:
Les entreprises ne sont pas encore habituées à l'idée des logiciels libres et/ou gratuits. La maintenance réalisée par la communautée les intrigue (dépasse ?). Les décideurs en place aujourd'hui ont souvent trop baigné dans l'univers commercial des logiciels (ca risque de changer petit à petit ...)
Tout ca pour dire que convaincre son employeur d'installer un BSD ou Linux comme serveur d'impression c'est facile. Lui prouver que les performances en tant que serveur HTTP sont la c'est faisable avec un test ... mais démontrer la pertinance de la solution en termes de sécurité c'est quasiment impossible. Le décideur à esprit ouvert qui aura intégré Linux dans son entreprise ne PEUT PAS se permettre de mettre OpenSSH ou Netfilter pour assurer la sécurité ...
Attendons encore 5/10 ans. Les décideurs seront des gens plus familiers des logiciels libres et le mouvement fera son chemin. Les logiciels propriétaires seront alors obligé d'assurer la qualité en plus des fonctionnalités pour supporter la comparaison.
Ta préparation etait nickel, je reviens sur mon avis de tout à l'heure :-))
Par contre je ne comprends pas ton probleme pour les joindre puisque tu avais un mec au bout du fil lors de la modification ?
Quand aux tarifs, à mon avis ils se sont tous mis d'accord :-) c'est le même partout quoi.
qui va tu consulter ? ATT, Oleane, Colt, ...
Il faut aussi garder à l'esprit que ca arrive de se planter... En ce moment, la plupart des mecs sur site sont surement des back-up à cause des congés ... Tu devrais surtout mettre en avant la pub qu'ils sont en train de se faire sur ton site frequenté principalement par des informaticiens ... clients potentiels, consultants, techniciens !! pas bon pour eux ca !!
Bonne chance en tout cas. Une journée sans linuxfr c'etait long :-) [et pourtant je consulte avec un lien UUNET ... ca devrait rouleze c'est quasi de l'intranet :-)]
Cet anonyme à bien parlé...
aviez vous reduit le TTL de vos enregistrements DNS pour que les caches s'adaptent plus vite ?
ne pouviez vous pas garder la meme IP en doublon sur votre DNS primaire le temps du switch ?
ne pouviez vous pas demander une seconde plage d'adresse IP au lieu de changer d'adresses juste pour en avoir plus ?
Avez vous fait le changement avec un technicien de UUNET en ligne ?
Quand je fais des modifs avec UUNET et ATT, je decris les operations dans un doc par mail et je leur donne RV au telephone pour que les manips soient faites en meme temps de leur coté et du mien ...
Ces boites (UUNET, ATT, ...) ne font rien qui ne soit pas explicitement demandé par le client. Si vous ne leurs soufflez pas des idées, ils ne proposeront rien ...
PLuG qui pense que UUNET a bien merdé, mais que l'opération aurait pu être mieux préparée...
[^] # Re: je vois pas le rapport
Posté par PLuG . En réponse à la dépêche Serveurs mails de Wanadoo blacklistés. Évalué à 1.
Ou est le probleme ? (si ce n'est que un peu de documentation m'aurait fait gagner quelques heures a debugger ce binz).
Con, Incompetent...
je te trouve un peu rapide en conclusion la.
Tu es assez malin pour definir l'adresse IP du serveur DNS de wanadoo dans ton /etc/hosts non ?
chez moi quand je me connecte (IP dynamique), je recupere aussi l'@ des serveurs internes à wanadoo et je les définis dans mon DNS interne ...
wanadoo a choisit d'isoler les serveurs destinés a leur clients des serveurs accessibles à l'extérieur. D'un point de vue sécurité c'est à mon avis une bonne chose !!
[^] # Re: BIDON !!
Posté par PLuG . En réponse à la dépêche Serveurs mails de Wanadoo blacklistés. Évalué à 1.
pour resoudre le probleme d'aujourd'hui telnet ou nc (netcat) sont les outils les plus appropriés.
[^] # Re: Black liste ?
Posté par PLuG . En réponse à la dépêche Serveurs mails de Wanadoo blacklistés. Évalué à 1.
le serveur smtp.wanadoo.fr interne (@IP dans DNS interne) n'est evidement pas joingnable depuis l'exterieur !!, le DNS interne de wandoo non plus d'ailleur. Faut quand même pas les prendre pour plus cons qu'ils ne sont !!
Donc oui, les abonnés de wanadoo peuvent utiliser les relais smtp de wanadoo ... quelle nouvelle !!
[^] # Re: BIDON !!
Posté par PLuG . En réponse à la dépêche Serveurs mails de Wanadoo blacklistés. Évalué à 1.
Si le serveur refuse le telnet sur le port 25, il ne peut pas recevoir de mail. un point c'est tout.
Ton nmap il ne te sert à rien de plus [dans ce cas la] qu'a faire chier le monde et à prouver que tu capte quedalle aux réseaux IP.
D'ailleur il y a des chances que les scans nmap soient filtré en grande partie (car non essentiel au fonctionnement d'un serveur mail - meme dangereux) alors que la connection sur le port tcp/25, si tu la filtre tu peux aussi eteindre le serveur mail :-)
[^] # Re: BIDON !!
Posté par PLuG . En réponse à la dépêche Serveurs mails de Wanadoo blacklistés. Évalué à 1.
>> De plus je viens d'essayer des connexions sur le port SMTP des @IP données dans cette nouvelle, les connexions semblent ne pas aboutir, ca va etre dur de relayer du spam avec ces machines !!
Ta réponse:
>J'espère que ce n'est pas avec ping que tu as essayé.
Humm, il va falloir que tu lise un cours réseau juste une fois. Quelques indices qui prouve tes lacunes:
ping ==> icmp != connecté
port SMTP ==> tcp/25
De plus nmap n'est pas le meilleur moyen de tester si tu peux te connecter en tcp sur le port 25, non. C'est comme utiliser un marteau piqueur pour planter un clou, ca peut marcher ... mais essaye telnet ou nc plutot !!
De plus nmap est assez dangereux à utiliser: une erreur d'argument et c'est un portscan complet qui est lancé ... très facile a repérer !!
[^] # Re: Précision SVP
Posté par PLuG . En réponse à la dépêche Serveurs mails de Wanadoo blacklistés. Évalué à 1.
1/ en vérifiant cela semble plus de la désinformation qu'autre chose.
2/ smtp c'est courier sortant et entrant
3/ les admins ne vont pas sauter sur toutes les listes pseudo-maintenues de serveurs open-relai. rien qu'a voir le temps qu'il faut pour patcher IIS contre redcode, on se dit que le spam n'est pas pres d'etre traité correctement ...
Critiquer FT c'est toujours à la mode ?
[^] # BIDON !!
Posté par PLuG . En réponse à la dépêche Serveurs mails de Wanadoo blacklistés. Évalué à 1.
chez wanadoo, les serveurs SMTP qui acceptent de relayer le courier ne sont accessibles que de l'interieur de wanadoo (c'est a dire que par leurs abonnés). Les serveurs qui sont accessibles de l'extérieur (smtp.wanadoo.fr par exemple) ne relai le mail POUR PERSONNE (meme les abonnés).
La machine smtp.wanadoo.fr est définie avec 2 adresses IP différentes selon le DNS interogé (interne a wanadoo ou externe), ce sont 2 machines différentes.
De plus je viens d'essayer des connexions sur le port SMTP des @IP données dans cette nouvelle, les connexions semblent ne pas aboutir, ca va etre dur de relayer du spam avec ces machines !!
vérifiez avant de crier au loup ...
# uptime
Posté par PLuG . En réponse à la dépêche La tempête arrive, LinuxFr s'en va .... Évalué à 1.
parce que la avec tous les problemes (DNS, onduleur ...) vous faites chuter les statistiques d'uptime d'apache/linux !!
faudrait pas faire de la contre-publicité :-))
PLuG
[^] # Re: Mouais
Posté par PLuG . En réponse à la dépêche "Enfin" un livre sur les techniques de piratage. Évalué à -1.
PLuG
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par PLuG . En réponse à la dépêche Comparatif jsp/php. Évalué à 1.
Je suis tout de même agréablement surpris par les chiffres que tu donnes. Ils sont plus qu'honnorable pour la configuration matérielle utilisée.
Ca me fait penser à un jour ou un collegue avait des temps de réponse terrible ... en fait les pages qu'il récupérait avec son injecteur etaient toutes des erreurs 404 :-)) Mais vu ta réponse je vois que tu as du étudier tout cela de près.
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par PLuG . En réponse à la dépêche Comparatif jsp/php. Évalué à 1.
avec quel injecteur ??
qu'est-ce qu'un UTILISATEUR pour ton injecteur ?
parce que simuler ne serai-ce que 1000 requetes simultanées c'est pas une chose aisée ... il faut plusieurs machines en parallèle ...
de plus 1 requete != 1 utilisateur:
sur une page web souvent il y a des images ... donc plusieurs requetes HTTP.
quand il y a des saisies, un utilisateur qui par pisser au milieu d'un écran de saisie ca peut bloquer sa session du cote du serveur ... et quand tu as 1000 utilisateurs simultanés, tu peux avoir beaucoup de sessions en attente ...
bref prenons des pincettes pour manipuler ces chiffres.
PLuG
[^] # Re: Pour les JSP, c'est objectif :-)
Posté par PLuG . En réponse à la dépêche Comparatif jsp/php. Évalué à 1.
Java c'est lourd,c'est lent, ....
Je ne suis pas un trolleur fou et je vais donc argumenter.
Java est une solution technique (c'est pas seulement un language) forcement lourde puisque le code généré n'est pas adapté au CPU mais à une machine virtuelle [quand on a pas un cpu JAVA]. Ca ressemble à executer du code pour x86 sur un macIntosh dans un emulateur.
Les fanatiques de JAVA vont dire que ca marche quand meme et ils auront raison. Mais le même programme compilé pour l'architecture cible et écrit correctement sera forcement moins gourmand en ressources CPU/RAM/... et donc potentiellement plus rapide puique seul l'algo utile tournera.
Ensuite les mêmes fanatiques de JAVA nous reparleront des tests qui ont montré un code JAVA tourner aussi vite que son homologue en C, mais ils oublieront que cela depend de la charge de la machine, que en JAVA sur beaucoup de plateformes c'est la JVM qui gère le scheduling des threads JAVA [et elle est moins douée que le scheduleur de l'OS, ca peut même bloquer tous les threads JAVA sur un seul CPU !!] et enfin que dans le cadre de ces tests, le code JAVA avait été soigné [de vous à moi, entre un développeur C et un développeur JAVA, lequel des deux risque de mieux soigner son algo ? celui qui ne se pose même pas la question de libérer la mémoire et espère le passage d'un garbage collector à un moment ou son appli n'aura pas besoin de trop de CPU ??]
Je ne suis pas un fanatique de JAVA, mais je vois bien les avantages des solutions JAVA quand même:
Un seul package qui s'installe sur toutes les plateformes. C'est le seul avantage mais il est de taille pour tous ceux qui ont déjà VRAIMENT produit du logiciel, cela supprime des hommes/mois de boulot de packaging, tests ...
Ce package multiplateforme est donc tout indiqué pour le web ou l'architecture du client est inconnue (applets). Pour les servlets ca se discute plus, mais ca fait le bonheur des vendeurs de serveurs ... et des developpeurs. Si JAVA est plutot une solution d'architecture, il a su séduire beaucoup de développeurs en tant que langage. Du coup il y a souvent confusion ...
PLuG
[^] # Re: La raison est simple
Posté par PLuG . En réponse à la dépêche Trou dans SSH 3.0.0. Évalué à 2.
Les entreprises ne sont pas encore habituées à l'idée des logiciels libres et/ou gratuits. La maintenance réalisée par la communautée les intrigue (dépasse ?). Les décideurs en place aujourd'hui ont souvent trop baigné dans l'univers commercial des logiciels (ca risque de changer petit à petit ...)
Tout ca pour dire que convaincre son employeur d'installer un BSD ou Linux comme serveur d'impression c'est facile. Lui prouver que les performances en tant que serveur HTTP sont la c'est faisable avec un test ... mais démontrer la pertinance de la solution en termes de sécurité c'est quasiment impossible. Le décideur à esprit ouvert qui aura intégré Linux dans son entreprise ne PEUT PAS se permettre de mettre OpenSSH ou Netfilter pour assurer la sécurité ...
Attendons encore 5/10 ans. Les décideurs seront des gens plus familiers des logiciels libres et le mouvement fera son chemin. Les logiciels propriétaires seront alors obligé d'assurer la qualité en plus des fonctionnalités pour supporter la comparaison.
PLuG
[^] # Re: Methodologie
Posté par PLuG . En réponse à la dépêche UUNet (update). Évalué à 1.
Par contre je ne comprends pas ton probleme pour les joindre puisque tu avais un mec au bout du fil lors de la modification ?
Quand aux tarifs, à mon avis ils se sont tous mis d'accord :-) c'est le même partout quoi.
qui va tu consulter ? ATT, Oleane, Colt, ...
Il faut aussi garder à l'esprit que ca arrive de se planter... En ce moment, la plupart des mecs sur site sont surement des back-up à cause des congés ... Tu devrais surtout mettre en avant la pub qu'ils sont en train de se faire sur ton site frequenté principalement par des informaticiens ... clients potentiels, consultants, techniciens !! pas bon pour eux ca !!
Bonne chance en tout cas. Une journée sans linuxfr c'etait long :-) [et pourtant je consulte avec un lien UUNET ... ca devrait rouleze c'est quasi de l'intranet :-)]
[^] # Re: Methodologie
Posté par PLuG . En réponse à la dépêche UUNet (update). Évalué à 1.
aviez vous reduit le TTL de vos enregistrements DNS pour que les caches s'adaptent plus vite ?
ne pouviez vous pas garder la meme IP en doublon sur votre DNS primaire le temps du switch ?
ne pouviez vous pas demander une seconde plage d'adresse IP au lieu de changer d'adresses juste pour en avoir plus ?
Avez vous fait le changement avec un technicien de UUNET en ligne ?
Quand je fais des modifs avec UUNET et ATT, je decris les operations dans un doc par mail et je leur donne RV au telephone pour que les manips soient faites en meme temps de leur coté et du mien ...
Ces boites (UUNET, ATT, ...) ne font rien qui ne soit pas explicitement demandé par le client. Si vous ne leurs soufflez pas des idées, ils ne proposeront rien ...
PLuG qui pense que UUNET a bien merdé, mais que l'opération aurait pu être mieux préparée...
[^] # Re: Le Boycott du rire
Posté par PLuG . En réponse à la dépêche Boycott Adobe... un air de déja vu ?. Évalué à 1.