Salut à tous
J'ai un soucis concernant l'envoi de mail sur un serveur. Voici l'architecture de mon réseau:
- J'ai un serveur A sous Red Hat AS3 qui est un serveur de production. Il se situe dans un réseau à part et n'a que très peu de ports ouverts. La dernière version de Sendmail est dessus.
Son ip: 172.17.3.135
- J'ai un serveur B sous Win 2000. C'est le serveur SMTP de l'entreprise (sous IIS).
Son ip: 172.17.0.46
Ce que je voudrai faire, c'est lorsque mon serveur A veut envoyer des mails, que ceux ci soient envoyés vers le serveur B (le serveur SMTP) qui se chargera alors de la résolution de l'adresse et de l'envoi.
J'ai fait quelques recherches sur internet et je n'ai pas trouvé grand chose. J'ai appris qu'il fallait que je configure le "smart host" de sendmail avec l'adresse ip de mon serveur SMTP (172.17.0.46). J'ai également déclaré mon serveur smtp dans le hosts.
Mais cela ne fonctionne toujours pas. Quand j'essaie d'envoyer un mail, celui ci se met en queue et au bout d'un moment, je recois un mailer daemon me disant que mon serveur smtp n'est pas accessible. Pourtant, les 2 serveurs arrivent à se pinger.
On m'a expliqué qu'il faudrait que je configure un DNS sur mon serveur A (celui qui veut envoyer les emails) ainsi que sa zone inverse mais à vrai dire je ne vois pas trop l'intéret, vu que je tente d'envoyer un mail à une ip précise.
On m'a dit également que mes 2 serveurs doivent être dans le même domaine ...
Pouvez vous m'aider ? Ce qu'on me dit est il vrai ? Si oui, comment configurer le DNS ?
Merci d'avance.
Forum Linux.général Sendmail et SMTP distant
18
avr.
2005
# sendmail.cf
Posté par JJD . Évalué à 2.
Dans ton fichier /etc/sendmail.cf tu dois avoir une ligne avec :
DS172.17.0.46
Ainsi, TOUS les mails seront envoyés vers ton serveur SMTP.
Attention cependant, le fait que tu puisses pinger B depuis A ne te garantis pas que A puisse se connecter sur B en SMTP. Pour t'en assurer, essaie plutôt, depuis A, un telnet sur le port 25 de B :
$ telnet 172.17.0.46 25
Si tout va bien, tu dois obtenir une réponse du serveur SMTP (ligne commençant par le code 220) et tu devrais pouvoir passer des commandes SMTP (HELO, QUIT, HELP, ...). Dans le cas contraire, il faudra vérifier les paramètres de tes firewalls/routeurs.
JJD
[^] # Re: sendmail.cf
Posté par Ian X . Évalué à 1.
Merci de ta réponse.
Effectivement, j'arrive à me connecter en telnet sur le port 25 de mon serveur SMTP et j'arrive à passer les commandes SMTP.
Néanmoins, l'envoi de mail ne fonctionne pas.
Le Smart Host de Sendmail a pourtant été configuré. (J'ai bien le DS172.17.0.46 dans mon sendmail.cf)
J'ai fait une analyse de ce qui sort de mon serveur A (celui qui envoie les mails) avec tcpdump et il s'avère que rien ne sort du serveur lors de l'envoi d'un mail via la commande mail. Par contre, je vois bien les paquets sortir si je fais un telnet 172.17.0.46 25.
Une idée ?
Merci d'avance.
[^] # Re: sendmail.cf
Posté par mac . Évalué à 2.
[^] # Re: sendmail.cf
Posté par igor38 . Évalué à 2.
[^] # Re: sendmail.cf
Posté par Ian X . Évalué à 1.
Voici un extrait de mon maillog: (j'ai modifié l'adresse en toto@yahoo.fr)
Apr 15 16:57:05 srvtest sendmail[3460]: j3FEujkU003460: from=root, size=909, class=0, nrcpts=1, msgid=<200504151456.j3FEujkU003460@localhost.localdomain>, relay=root@localhost
Apr 15 16:57:05 srvtest sendmail[3460]: j3FEujkU003460: to=toto@yahoo.fr, delay=00:00:20, mailer=esmtp, pri=30909, dsn=4.4.3, stat=queued
Et c'est tout. Ensuite, au bout de plusieurs heures, je recois un mail dans la boite du root avec cette ligne en particulier:
451 yahoo.fr: Name server timeout
Ce sent l'erreur de DNS ca non ? Je n'ai pas de DNS de déclaré car je pense ne pas en avoir besoin vu que je n'attaque que 2 ip, le 172.17.0.46 (le smtp) et une autre (c'est pour la production et cela marche parfaitement). Mais bon je me trompe peut etre.
Merci d'avance.
[^] # Re: sendmail.cf
Posté par igor38 . Évalué à 2.
451 ? Dis moi, ton serveur A, il peut bien effectuer des requêtes DNS (résoudre les noms de domaines ) ? Parce que là il n'a pas l'air.
Si effectivement ton intention est de ne pas le laisser résoudre les noms lui même, faut que tu précise dans ton sendmail.mc
FEATURE(`accept_unresolvable_domains')
C'est pas le top ni trop conseillé, mais si tu veux fonctionner comme ça, t'as pas vraiment le choix, sinon tu lui laisses résoudre les adresses.
[^] # Re: sendmail.cf
Posté par Ian X . Évalué à 1.
Voici ce que j'ai fait pour l'instant:
- dans le fichier /etc/hosts, j'ai le 127.0.0.1 et j'ai aussi déclaré le serveur B (le smtp), à savoir 172.17.0.46.
- dans le resolv.conf, j'ai mis ceci: nameserver 172.17.0.46
Enfin, j'essaie de configurer le named.conf, en créant une zone primaire et inverse, mais à vrai dire je ne sais pas trop comment configurer cela, surtout les fichiers zone.db et zone.rev.
Pour l'instant j'ai mis cela dans mon fichier named.conf: (j'ai mis toto.fr en domaine)
controls {
inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};
zone "." IN {
type hint;
file "named.ca";
};
zone "localhost" IN {
type master;
file "localhost.zone";
allow-update { none; };
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "named.local";
allow-update { none; };
};
zone "toto.fr" IN {
type master;
file "toto.fr.db";
};
zone "17.172.in-addr.arpa" IN {
type master;
file "toto.fr.rev;
};
Mais je ne sais pas trop comment configurer mes fichiers db et rev.
Ai je bon pour l'instant ? Si oui, que me reste t'il à faire ? Si non, ba ... comment permettre à mon serveur de résoudre les noms ?
Dans tous les cas, un grand merci pour votre aide !
[^] # Re: sendmail.cf
Posté par igor38 . Évalué à 1.
Pour que ton serveur puisse résoudre les noms de domaines, il suffit tout simplement que tu lui fournisse un accés à internet ou à un quelconque serveur DNS, donc port 53 ouvert en tcp/udp.
si tu mets dans le resolv.conf l'adresse de ton server B, alors c'est ton serveur B qui traitera les requêtes DNS, et c'est lui qui devrait être configuré en serveur DNS.
Le fait de déclarer des zones dans ton named.conf sur ton serveur transformera A en serveur DNS, et c'est pas ce que tu veux. Donc tu peux laisser ton named.conf vide, t'en a pas besoin sur A
Et pour beaucoup moins te prendre la tête, je te conseillerai plutôt de déclarer dans ton resolv.conf les DNS fournis par ton FAI.
Et à partir de là et en toute logique, tout devrait rentrer dans l'ordre.
Teste déjà comme ça, après c'est du peaufinage
[^] # Re: sendmail.cf
Posté par Ian X . Évalué à 1.
En fait le serveur A est un serveur "blindé", il n'a pas accès à internet (je ne suis pas chez moi, je suis dans un gros réseau d'entreprise).
Et je n'ai pas de DNS extérieur (en fait si, il y en a, mais ils ne connaissent pas le serveur B SMTP) et je ne peux pas l'ajouter car ces serveurs DNS sont en Allemagne et je n'y ai aucun droit. Je sais ce réseau est un peu naze mais c'est pas moi qui l'ai fait :o)
Donc en gros, le serveur DNS sera mon serveur A. C'est possible ? Si oui comment faire ? Dans le resolv.conf, je dois mettre nameserver 127.0.0.1 alors ? Ou alors nameserver 172.17.3.135 (ip externe du serveur A).
Merci d'avance.
[^] # Re: sendmail.cf
Posté par igor38 . Évalué à 2.
Bon, si t'as pas trouver depuis, c'est clair il te faut un DNS, pour la déclaration des zone rev et db, là je peux pas vraiment t'aider, c'est pas mon truc. Donc google est ton ami.
Pour ton nameserver, 127.0.0.1 ou 172.17.3.135, ce sera la même chose.
Après, pour ton sendmail, il faudra effectivement que tu valides le 'accept_unreasolvable_domain' , sous peine de rien pouvoir envoyer. Là sans DNS accessible, t'as pas le choix.
C'est pas top, et j'espère que ton SMTP 2000 s'en sort bien avec les Spams, forged et autres bestioles du genre (si c'est pas le cas, tu comprendras très vite ce que je veux dire :) )
Et bien entendu, tu devras faire du 'masquerading' de domaine (dans sendmail.mc), et l'autoriser sous 2k, sans quoi tu te prendra un rejected dans les dents dans 99,99% des cas.
Tiens nous au courant.
[^] # Re: sendmail.cf
Posté par igor38 . Évalué à 2.
# ssmtp`ne ferait-il pas l'affaire?
Posté par Djax . Évalué à 2.
est-ce que ssmtp ne suffirait pas dans ton cas?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.