sendmail et hostname
Le
NicolasAlex.Michel.remove
Bonjour
Sur un cluster RHEL5 que je n'administre pas,
je cherche à envoyer un mail en cli via mail, mailx, mutt ou autre.
Le mail ne part pas les logs disent :
Unable to verify MX-Record for domain master.cluster
La solution que je trouves sur le net proposent de modifier /etc/host
pour que `hostname` retourne le fqdn (qui existe et est enregistré dans
les DNS)
Dans le cas présent, le fqdn est présent dans le fichier host
mais la commande hostname retourne l'adresse interne au cluster.
Je souhaiterais contourner le problème pour éviter que les fonctions
internes au cluster, qui pourraient également s'appuyer sur le hostname,
ne risquent pas de poser problème.
Est-ce qu'on peut spécifier le MX-Record dans sendmail en dur ?
Ou mettre une variable d'environnement ?
Ou "forger" le mail en spécifiant le domaine ?
(comme vous l'aurez sans-doutes lu, je ne suis pas un pro de sendmail)
Merci !
--
Nicolas Michel
Sur un cluster RHEL5 que je n'administre pas,
je cherche à envoyer un mail en cli via mail, mailx, mutt ou autre.
Le mail ne part pas les logs disent :
Unable to verify MX-Record for domain master.cluster
La solution que je trouves sur le net proposent de modifier /etc/host
pour que `hostname` retourne le fqdn (qui existe et est enregistré dans
les DNS)
Dans le cas présent, le fqdn est présent dans le fichier host
mais la commande hostname retourne l'adresse interne au cluster.
Je souhaiterais contourner le problème pour éviter que les fonctions
internes au cluster, qui pourraient également s'appuyer sur le hostname,
ne risquent pas de poser problème.
Est-ce qu'on peut spécifier le MX-Record dans sendmail en dur ?
Ou mettre une variable d'environnement ?
Ou "forger" le mail en spécifiant le domaine ?
(comme vous l'aurez sans-doutes lu, je ne suis pas un pro de sendmail)
Merci !
--
Nicolas Michel
Poser une question
Michel) a écrit :
Bonjour,
[...]
En règle générale, en interne sur un LAN, on n'utilise pas de MX, le
serveur de courrier étant le même pour tous les clients (même s'il est
redondé). Au pire on a un fichier "mailertable" qui définit quels sont
les serveurs à utiliser pour quels domaines.
Dans votre cas il devrait suffire de signaler à votre cluster le nom de
la machine qui joue le rôle du serveur SMTP, que votre sendmail devra
donc contacter.
Cela se fait généralement en mettant dans votre fichier
/etc/mail/sendmail.mc une ligne de ce type:
FEATURE(`nullclient', `votre.serveur.de.courrier.interne')
La plupart du temps (mais je ne connais pas bien RH) elle est déjà en
commentaire dans le fichier, il suffit de la décommenter et de
renseigner correctement le nom de votre serveur de mail.
Attention aux "quotes": il s'agit bien de ` en début de chaîne et de '
en fin de chaîne.
Il faut ensuite regénérer le fichier sendmail.cf à partir du .mc,
souvent cela se fait en tapant "make" dans le répertoire /etc/mail (mais
encore une fois, sur RH cela diffère peut-être), et redémarrer sendmail.
Bon courage... ;-)
Cordialement,
Bruno
Donc on parle d'utiliser le SMTP "oficiel", celui là même qui gère les
mails de tout le monde ?
ça semble logique, mais notre smtp requiert une authentifiaction et du
ssl, est-ce que sendmail a droit à un passe-droit du fait qu'il est lui
aussi un serveur mail ?
(si non, j'aurai le problème du passwd en clair)
Soit l'authentification coince, soit j'ai fait une bourde :
Selon les logs il contact bien le smtp (relay=mail.ici.ch)
mais retourne le même problème : statÚta format error
Ensuite j'ai activé le MASQUERADE,
en mettant ces ligne :
dnl # EXPOSED_USER(`root')dnl
dnl # (donc je retire l'exclusion de root pour le masquerade)
FEATURE(masquerade_envelope)dnl
FEATURE(masquerade_entire_domain)dnl
FEATURE(allmasquerade)dnl
MASQUERADE_AS(`fqdn') MASQUERADE_DOMAIN(`master.cluster')dnl
Et ça marche !
Yeah :)
J'ai dû l'ajouter, mais c'est pas dramatique quand on a une explication
comme celle ci :)
Ah, ça c'est un truc que j'avais loupé.
C'est cool d'avoir une explication complète, sur le web j'étais tombé
sur des tuto qui supposaient qu'on connais les bases.
Merci !!!
--
Nicolas Michel
Bon, en faisant la doc (on notifie toutes les modifs de nos servdeurs)
je vois que je me suis un peu emporté :
On a pas besoins de masquerade_entire_domain ni de allmasquerade.
Après désactivation, ça fonctionne toujours.
Merci encore, Bruno :)
--
Nicolas Michel
De rien ! :-)
Pour l'histoire de l'authentification+ssl, ça s'est soldé comment en fin
de compte ?
AMHA, une bonne solution pour mélanger soumissions par des MSA et des
MTA est d'utiliser les ports "qui vont bien": les MSA doivent
normalement causer sur le port 587/tcp, mais actuellement, l'immense
majorité est encore configurée pour attaquer le port 25. Après, tout
dépend du chiffrement employé: si c'est du TLS, on reste sur 25, si
c'est du SSL, on passe sur 465, en standard. Donc il y a de nombreuses
possibilités de filtrage permettant de n'autoriser que certains hôtes
(d'autres MTA comme votre cluster) à envoyer directement des mails au
hub central, les autres machines devant passer par une phase
d'authentification préalable de l'utilisateur... Mais le problème ne
s'est peut-être pas posé ?
Concernant votre autre remarque (dans votre précédent message) sur
l'utilisation du serveur SMTP "officiel": oui, c'est tout à fait logique
de procéder ainsi, afin que les courriels soumis par cette voie
subissent les mêmes contrôles que les autres. Mais je parle bien sûr ici
du SMTP interne, qui n'est pas forcément le même que le SMTP externe,
situé en DMZ, et par lequel vous recevez les courriers de l'extérieur.
La plupart du temps les deux sont bien séparés.
Cordialement,
Bruno
Comme j'ai activé le masquerading, j'utilises le serveur local plutôt
que le smtp de la boite
Du coup ça ne s'est pas soldé,
j'ai évité la confrontation :)
Aille, je ne connais rien aux protocoles MTA et MSA.
J'ai toujours bossé dans des grosses boites où les tâches sont séparées
et où il y a un admin spécifique pour le mail.
J'ai tenté de lire 3 lignes dans wikipedia, mais à la seconde ligne
j'avais déjà mal à la tête.
Je crois que je vais me mettre ce truc sous le coude pour plus tard :)
Je comprends ton point de vue.
Mais en même temps on utlise la fonction mail interne de nos serveurs
uniquement dans des scripts, pas en interactif. Et sendmail n'écoute pas
sur le réseau. Tu penses que même dans ce cas là les filtres sont
nécessaires ?
Sendmail en local ça a l'avantage de ne pas dépendre d'un autre
serveur/admin.
Notre admin exchange n'a pas documenté cette partie là, il s'est
contenté de donner les paramètres imap et smtp, et il n'y a qu'une seule
adresse pour toutes les connexions smtp.
Je ne sais pas si le machin qui répartit la charge des connexion mails
entre les différents serveurs filtre l'origine de la demande ou si c'est
pas simplement filtré au niveau du service smtp.
--
Nicolas Michel