pourquoi 10 minutes ?
cela me semble une valeur arbitraire ...
le relaying authentifié par adresses IP c'est bien si tu maitrise ces adresses (ton LAN, ou alors c'est toi qui les fournis (tu est FAI)).
sinon il vaudrait mieux authentifier les connections smtp autrement (clefs).
elle va se libérer car ta belle mère ne va pas aimer le crachouilli du protocole ppp en parallele avec sa fille dans le combiné :-))
bon évidement si la ligne est occupée, cela ne marchera pas. mais aucun mail n'est perdu car les mails arrivant restent sur le serveur pop de ton FAI et les mails sortants restent dans la mail queue de ton serveur smtp.
effectivement, je faisait juste la remarque que tout cela n'etait pas traité dans le document. une petite ligne pour dire qu'un 486 suffit, un paragraphe pour la sécurité (ssh,ssl,chroot jail,pam) ca ferait pas de mal au document.
l'auteur demandait des commentaires ...
effectivement, merci pour ces corrections (ces imprécisions en plus des fotes d'ortaugraf ... j'aurai du me relire !!)
a mon tour donc de paufiner (ensuite y aura plus qu'a ajouter un résumé de ce thread dans la doc au dessus :-))
1/pendant les deconnections, les serveurs smtp vont ré-éssayer plusieurs fois d'envoyer le mail donc à moins de ne pas etre connecté pendant plusieurs jours (durée habituelle des ré-émissions), normalement il n'y aura pas de perte de courier. De plus quelqu'un ayant l'adsl et se lancant dans ce genre de manip prévoit certainement de laisser la machine up tout le temps (onduleur, 2 machines en vrrp ...).
2/dyndns ou minidns.net ou d'autres effectivement il faut un compte chez un fournisseur de dns gratuit et dynamique.
C'est pas une bonne idée effectivement car les infos contenues dans les "DNS dynamiques" ne sont pas gardées en cache par les autres DNS (pour faciliter la mise à jour), du coup le serveur (dyndns ou minidns ou autre) se tape une requete à chaque mail recu (et même envoyé si le nom de domaine est validé ...).
Je ne comprend pas bien tes inquietudes.
Effectivement pour le courier sortant tu as le choix entre le router via la passerelle smtp de ton provider si il l'autorise (cf plus bas), soit d'envoyer le courier directement au serveur destinataire.
Quand aux IP blacklistées a mon avis tu te mélanges les pinceaux:
1/ les black-list sont des liste d'adresses IP de serveurs DE QUI il ne faut pas accepter le mail (mais on peut leur en envoyer)
2/ ton serveur n'est pas obligé (par défaut il ne le fera pas d'ailleurs) de respecter ces black-lists.
Par contre pour recevoir du mail avec un nom de domaine a toi (genre plug@nowhere.com), il faut
1/ acheter le domaine en question
2/ faire heberger (heberger soi meme) le DNS de ce domaine [il existe des solutions gratos genre minidns.net et autres, google est ton ami !!]
3/ enregistrer l'IP de la passerelle smtp de ce domaine dans le DNS en question (champ MX du DNS).
A la suite de quoi quand quelqu'un ecrira à plug@nowhere.com, le mail sera envoyé en smtp directement a la passerelle smtp de nowhere.com.
C'est la que le blacklistage des IP peut t'embeter plus: si ton serveur est mal configuré (open relai), tu risque de voir l'adresse IP de ta passerelle smtp black-listée et tu ne recevra plus les mails passant par des passerelles qui se confortents aux black-lists en question.
plus-bas:
wanadoo pour le moment accepte de relayer le courier sortant de ses abonnés. Mais cela risque de changer car certains abonnés ont placés des serveurs smtp open-relai qui routent le mail via les passerelles de wanadoo. résultat les passerelles de wanadoo apparaissent dans certaines black-lists (on en a deja parlé). Comme solution wanadoo enviseage de ne plus relayer le mail de ses abonnés si le mail vient d'une passerelle smtp.
OK, c'est une bonne initiative d'ecrire des docs en francais. Je trouve cependant que cette doc n'apporte pas grand chose, meme si il faut encourager ce genre de comportement communautaire.
la doc pourrait aborder les problemes comme:
-comment creer des comptes mails sans creer de compte UNIX pour la personne. (un serveur de mail autonome n'a pas besoin d'avoir autant de comptes avec des password bidons la plupart du temps ...). d'ailleur ou est l'install de imap/popd et comment choisir entre les 2 ?
-comment filtrer avec un anti-virus les messages recus et envoyés
-quel hardware pour quelle charge ?
-utilisation de ssl
bref des trucs qui ne seraient pas dans le man quoi.
Merci quand meme à l'auteur qui aura toujours passé du temps a partager !!
humm, c'est pas si simple.
la VM de linux a ete modifiée mainte fois, et comparée a celle des autres OS. En particulier a celle de BSD qui est tres bien documentée.
La VM de BSD possède elle aussi des défauts. Du coups les développeurs kernel linux ont préféré essayer de prendre les idées de plusieurs VM plus des idées à eux.
Il faut savoir que le gros probleme de la VM c'est que son optimisation depend énormemement de la taille mémoire disponible et des process qui vont tourner dessus (gros process, beaucoup de petits process, beaucoup d'interactivité ou batch ...).
Bref il n'y a pas de VM parfaite.
De plus, déjà que les développeurs travaillent gratos, tu voudrais pas qu'on leur demande d'arreter leurs expériences amusantes pour copier bêtement le code du voisin. ca n'interesse personne de récupérer le code du voisin tel quel.
Ce document est vraiment très bien écrit. Je vais de ce pas diffuser l'URL ...
il parcourt la sécurité sous la plupart de ses aspects (anti-hack mais aussi sécurité physique, vol de données, perte des données ...).
Ecrit très lisiblement (en anglais).
Avec en plus une tendance a enfoncer les OS moins sécurisés (on y parle de windows a plusieurs reprises). Le paragraphe sur les virus est tres juste ...
bref que du bon.
en fait ca depend carrement du processeur utilisé (et de l'OS mais la on parle de linux, il faudrait connaitre la version du noyau).
un load average de 120 sur un pentium 133 c'est carrement le freeze complet (j'ai deja essayé pendant un bench samba, au alentours de 100 la machine se freeze mais ne plante pas et redevenait utilisable des que la charge redescendait - kernel 2.2). Les CPU s'améliorent et supportent de mieux en mieux ces charges (le noyau aussi j'espère mais je ne fais plus de bench donc pas testé le 2.4).
Avec des BSD j'ai deja vu des machines au dessus de 250 24h/24 mais qui continuaient de rendre leur service (gateway mail).
C'est la longueur moyenne de la file d'attente de l'ordonnanceur du noyau
bonne définition, avec un exemple cela donne:
si tu as un load average de 2.85 pour les 5 dernières minutes, cela signifie que en moyenne pendant ces 5 minutes, a chaque fois que le kernel devait choisir un process à executer, il avait le choix entre 2.85 process.
(comme il ne peut en executer plus d'un a la fois par processeur, cela signifie que les autres ont du attendre leur tour).
un load average a 1 est optimal, en dessous ton processeur s'ennuie ferme, au dessus il trime à mort.
relis mon post au dessus: conrad.fr != conrad.de
je vois pas pourquoi j'irai acheter ca en allemagne ... sauf si ils ne vendent pas la meme chose selon le pays !!
Non ces linux ne sont pas desktop (sauf le mien sur mon portable :-)).
Les linux installé chez mon client actuel sont chargé de la reception du mail, du proxy web/ftp, du proxy dns, de la remontée d'alarmes snmp. plus 1 sniffer adapté au besoin local tres spécifique (introuvable dans le commerce), plus 1 firewall interne (l'intranet est assez grand pour necessiter des firewalls en interne)...
En clair rien de visible pour les utilisateurs lambda... qui continuent avec win2k.
Il n'empeche que à force de placer des linux comme serveurs, les gens s'habituent à l'idée et certains demandent si on peut l'utiliser en desktop.Et puis il y a un public facile a convertir: tout ceux qui travaillent sous exceed sous win2k.
ici l'admin windows principal m'a déjà demandé si il pouvait dupliquer mes cd redhat ... on progresse je vous dit.
De plus beaucoup ne sont pas interessés par l'aspect politique (philosophique) du mouvement du libre.
Si je place des linux de partout chez mes clients, c'est pas pour des aspects plus terre à terre:
-pas de solution equivalente non libre
-pas le temps de passer une commande (delai de mise en oeuvre: qques heures)
-cout/performances
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.
[^] # Re: :)
Posté par PLuG . En réponse à la dépêche Installation d'un serveur de messagerie. Évalué à 2.
voici un extrait illustrant le concept:
Examples:
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH FOOBAR
S: 504 Unrecognized authentication type.
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
[^] # Re: :)
Posté par PLuG . En réponse à la dépêche Installation d'un serveur de messagerie. Évalué à 1.
cela me semble une valeur arbitraire ...
le relaying authentifié par adresses IP c'est bien si tu maitrise ces adresses (ton LAN, ou alors c'est toi qui les fournis (tu est FAI)).
sinon il vaudrait mieux authentifier les connections smtp autrement (clefs).
[^] # Re: Et si la ligne telephonique est occupee ?
Posté par PLuG . En réponse à la dépêche Installation d'un serveur de messagerie. Évalué à 1.
bon évidement si la ligne est occupée, cela ne marchera pas. mais aucun mail n'est perdu car les mails arrivant restent sur le serveur pop de ton FAI et les mails sortants restent dans la mail queue de ton serveur smtp.
[^] # Re: oui mais ...
Posté par PLuG . En réponse à la dépêche Installation d'un serveur de messagerie. Évalué à 1.
l'auteur demandait des commentaires ...
[^] # Re: petite précision
Posté par PLuG . En réponse à la dépêche Installation d'un serveur de messagerie. Évalué à 3.
a mon tour donc de paufiner (ensuite y aura plus qu'a ajouter un résumé de ce thread dans la doc au dessus :-))
1/pendant les deconnections, les serveurs smtp vont ré-éssayer plusieurs fois d'envoyer le mail donc à moins de ne pas etre connecté pendant plusieurs jours (durée habituelle des ré-émissions), normalement il n'y aura pas de perte de courier. De plus quelqu'un ayant l'adsl et se lancant dans ce genre de manip prévoit certainement de laisser la machine up tout le temps (onduleur, 2 machines en vrrp ...).
2/dyndns ou minidns.net ou d'autres effectivement il faut un compte chez un fournisseur de dns gratuit et dynamique.
C'est pas une bonne idée effectivement car les infos contenues dans les "DNS dynamiques" ne sont pas gardées en cache par les autres DNS (pour faciliter la mise à jour), du coup le serveur (dyndns ou minidns ou autre) se tape une requete à chaque mail recu (et même envoyé si le nom de domaine est validé ...).
[^] # Re: ADSL ?
Posté par PLuG . En réponse à la dépêche Installation d'un serveur de messagerie. Évalué à 7.
Effectivement pour le courier sortant tu as le choix entre le router via la passerelle smtp de ton provider si il l'autorise (cf plus bas), soit d'envoyer le courier directement au serveur destinataire.
Quand aux IP blacklistées a mon avis tu te mélanges les pinceaux:
1/ les black-list sont des liste d'adresses IP de serveurs DE QUI il ne faut pas accepter le mail (mais on peut leur en envoyer)
2/ ton serveur n'est pas obligé (par défaut il ne le fera pas d'ailleurs) de respecter ces black-lists.
Par contre pour recevoir du mail avec un nom de domaine a toi (genre plug@nowhere.com), il faut
1/ acheter le domaine en question
2/ faire heberger (heberger soi meme) le DNS de ce domaine [il existe des solutions gratos genre minidns.net et autres, google est ton ami !!]
3/ enregistrer l'IP de la passerelle smtp de ce domaine dans le DNS en question (champ MX du DNS).
A la suite de quoi quand quelqu'un ecrira à plug@nowhere.com, le mail sera envoyé en smtp directement a la passerelle smtp de nowhere.com.
C'est la que le blacklistage des IP peut t'embeter plus: si ton serveur est mal configuré (open relai), tu risque de voir l'adresse IP de ta passerelle smtp black-listée et tu ne recevra plus les mails passant par des passerelles qui se confortents aux black-lists en question.
plus-bas:
wanadoo pour le moment accepte de relayer le courier sortant de ses abonnés. Mais cela risque de changer car certains abonnés ont placés des serveurs smtp open-relai qui routent le mail via les passerelles de wanadoo. résultat les passerelles de wanadoo apparaissent dans certaines black-lists (on en a deja parlé). Comme solution wanadoo enviseage de ne plus relayer le mail de ses abonnés si le mail vient d'une passerelle smtp.
ai-je répondu a ta question ??
# oui mais ...
Posté par PLuG . En réponse à la dépêche Installation d'un serveur de messagerie. Évalué à 4.
la doc pourrait aborder les problemes comme:
-comment creer des comptes mails sans creer de compte UNIX pour la personne. (un serveur de mail autonome n'a pas besoin d'avoir autant de comptes avec des password bidons la plupart du temps ...). d'ailleur ou est l'install de imap/popd et comment choisir entre les 2 ?
-comment filtrer avec un anti-virus les messages recus et envoyés
-quel hardware pour quelle charge ?
-utilisation de ssl
bref des trucs qui ne seraient pas dans le man quoi.
Merci quand meme à l'auteur qui aura toujours passé du temps a partager !!
[^] # Re: Une petite question (HS)
Posté par PLuG . En réponse à la dépêche La version 5.0 de FreeBSD retardée. Évalué à 6.
la VM de linux a ete modifiée mainte fois, et comparée a celle des autres OS. En particulier a celle de BSD qui est tres bien documentée.
La VM de BSD possède elle aussi des défauts. Du coups les développeurs kernel linux ont préféré essayer de prendre les idées de plusieurs VM plus des idées à eux.
Il faut savoir que le gros probleme de la VM c'est que son optimisation depend énormemement de la taille mémoire disponible et des process qui vont tourner dessus (gros process, beaucoup de petits process, beaucoup d'interactivité ou batch ...).
Bref il n'y a pas de VM parfaite.
De plus, déjà que les développeurs travaillent gratos, tu voudrais pas qu'on leur demande d'arreter leurs expériences amusantes pour copier bêtement le code du voisin. ca n'interesse personne de récupérer le code du voisin tel quel.
un peu de lecture:
http://www.multicians.org/multics-vm.html(...)
http://docs.freebsd.org/44doc/papers/newvm.html(...)
cette page possede plein de liens en relation:
http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html(...)
# Tres bien ce document IBM
Posté par PLuG . En réponse à la dépêche La sécu Linux vu par IBM. Évalué à 2.
il parcourt la sécurité sous la plupart de ses aspects (anti-hack mais aussi sécurité physique, vol de données, perte des données ...).
Ecrit très lisiblement (en anglais).
Avec en plus une tendance a enfoncer les OS moins sécurisés (on y parle de windows a plusieurs reprises). Le paragraphe sur les virus est tres juste ...
bref que du bon.
[^] # Re: A propos du load.... ?
Posté par PLuG . En réponse à la dépêche DaNews: bonne rentrée! :). Évalué à 1.
un load average de 120 sur un pentium 133 c'est carrement le freeze complet (j'ai deja essayé pendant un bench samba, au alentours de 100 la machine se freeze mais ne plante pas et redevenait utilisable des que la charge redescendait - kernel 2.2). Les CPU s'améliorent et supportent de mieux en mieux ces charges (le noyau aussi j'espère mais je ne fais plus de bench donc pas testé le 2.4).
Avec des BSD j'ai deja vu des machines au dessus de 250 24h/24 mais qui continuaient de rendre leur service (gateway mail).
[^] # Re: A propos du load.... ?
Posté par PLuG . En réponse à la dépêche DaNews: bonne rentrée! :). Évalué à 2.
bonne définition, avec un exemple cela donne:
si tu as un load average de 2.85 pour les 5 dernières minutes, cela signifie que en moyenne pendant ces 5 minutes, a chaque fois que le kernel devait choisir un process à executer, il avait le choix entre 2.85 process.
(comme il ne peut en executer plus d'un a la fois par processeur, cela signifie que les autres ont du attendre leur tour).
un load average a 1 est optimal, en dessous ton processeur s'ennuie ferme, au dessus il trime à mort.
[^] # Re: references
Posté par PLuG . En réponse à la dépêche PC DCF-77-Uhr-Modul, parallel. Évalué à 1.
je vois pas pourquoi j'irai acheter ca en allemagne ... sauf si ils ne vendent pas la meme chose selon le pays !!
# references
Posté par PLuG . En réponse à la dépêche PC DCF-77-Uhr-Modul, parallel. Évalué à 1.
t'aurai pas les references completes de ton recepteur pour port parallele ? je ne l'ai pas trouvé sur le catalogue en ligne conrad.fr
[^] # Re: etat d'esprit
Posté par PLuG . En réponse à la dépêche Sondage sur le libre en entreprise. Évalué à 1.
Les linux installé chez mon client actuel sont chargé de la reception du mail, du proxy web/ftp, du proxy dns, de la remontée d'alarmes snmp. plus 1 sniffer adapté au besoin local tres spécifique (introuvable dans le commerce), plus 1 firewall interne (l'intranet est assez grand pour necessiter des firewalls en interne)...
En clair rien de visible pour les utilisateurs lambda... qui continuent avec win2k.
Il n'empeche que à force de placer des linux comme serveurs, les gens s'habituent à l'idée et certains demandent si on peut l'utiliser en desktop.Et puis il y a un public facile a convertir: tout ceux qui travaillent sous exceed sous win2k.
ici l'admin windows principal m'a déjà demandé si il pouvait dupliquer mes cd redhat ... on progresse je vous dit.
[^] # Re: etat d'esprit
Posté par PLuG . En réponse à la dépêche Sondage sur le libre en entreprise. Évalué à 1.
De plus beaucoup ne sont pas interessés par l'aspect politique (philosophique) du mouvement du libre.
Si je place des linux de partout chez mes clients, c'est pas pour des aspects plus terre à terre:
-pas de solution equivalente non libre
-pas le temps de passer une commande (delai de mise en oeuvre: qques heures)
-cout/performances
[^] # 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.