sendmail et hostname

Le 22/04/2010 à 16:07, NicolasAlex.Michel.remove@epfl.ch (Nicolas
Michel) a écrit :

Bonjour

Bonjour,

Sur un cluster RHEL5 que je n'administre pas,
je cherche à envoyer un mail en cli via mail, mailx, mutt ou autre.

[...]

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 ?

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

Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> wrote:

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.

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)

FEATURE(`nullclient', `votre.serveur.de.courrier.interne')

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 :)

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.

J'ai dû l'ajouter, mais c'est pas dramatique quand on a une explication
comme celle ci :)

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.

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.

Bon courage... ;-)

Merci !!!

--
Nicolas Michel

Nicolas Michel <NicolasAlex.Michel.remove@epfl.ch> wrote:

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

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

Nicolas Michel wrote:

Nicolas Michel <NicolasAlex.Michel.remove@epfl.ch> wrote:

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

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 :)

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

Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> wrote:

Pour l'histoire de l'authentification+ssl, ça s'est soldé comment en fin
de compte ?

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 :)

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é ?

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 :)

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.

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.

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.

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

Nicolas Michel wrote:

Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> wrote:

Pour l'histoire de l'authentification+ssl, ça s'est soldé comment en fin
de compte ?

Comme j'ai activé le masquerading, j'utilises le serveur local plutôt
que le smtp de la boite

Euh... Pas compris. Il part où, le mail, après ? Il faut bien qu'il soit
acheminé ailleurs, non ?

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.

Ce ne sont pas des protocoles, juste des acronymes qui veulent dire
"Mail Submission Agent" (employé pour les clients qui soumettent du mail
à un serveur), "Mail Transport Agent" (utilisé pour les serveurs de
courriers eux-mêmes) et "Mail Delivery Agent" (MDA, que je n'avais pas
évoqué) pour la phase finale du dépôt du courrier dans votre boîte. Il y
a donc 3 types de liaisons dans le trajet d'un mail:

1) la liaison MSA -> MTA lors de la soumission initiale du mail sur le
serveur de départ
2) les liaisons MTA -> MTA dans le transit du mail
3) la liaison MTA -> MDA sur le serveur final

On pourrait rajouter un 4) avec la récupération finale par l'utilisateur
via un protocole type POP ou autre, mais ce n'est plus du domaine SMTP
(bon, ok, strictement parlant, le 3) non plus puisque c'est une
délivrance locale, mais c'est le serveur SMTP qui s'en charge via
l'exécution d'un autre programme, la plupart du temps).

J'ai tenté de lire 3 lignes dans wikipedia, mais à la seconde ligne
j'avais déjà mal à la tête.

Un peu de fatigue en fin de semaine ? ;-)

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 ?

Le filtrage se fait au niveau du hub central, pas sur chacun des
serveurs qui peut éventuellement envoyer des mails. Il est fréquent, en
effet, que sendmail sur les serveurs ne soit activé que pour examiner
régulièrement la queue de messages à envoyer au hub central, dans ce
cas-là il n'a pas besoin d'écouter. Mais bon, pas la peine de se prendre
la tête avec ça, vous avez votre solution... ;-)

Notre admin exchange n'a pas documenté cette partie là, il s'est

^^^^^^^^
Ah oui, mais bon, si vous commencez à dire des gros mots sur un groupe
qui cause d'Unix aussi, là ça va pas aller ! :-D

Bon week-end quand-même !

Cordialement,

Bruno

Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> wrote:

Nicolas Michel wrote:

> Comme j'ai activé le masquerading, j'utilises le serveur local plutôt
> que le smtp de la boite

Euh... Pas compris. Il part où, le mail, après ? Il faut bien qu'il soit
acheminé ailleurs, non ?

Oui, mais euh ...
Il me semble que si l'authentification peut être requise pour du MSA
le MTA n'est jamais soumis à authentification. Non ?

Donc en ayant un sendmail local on fait ensuite du MTA et ça passe.

Il y a donc 3 types de liaisons dans le trajet d'un mail:

1) la liaison MSA -> MTA lors de la soumission initiale du mail sur le
serveur de départ
2) les liaisons MTA -> MTA dans le transit du mail
3) la liaison MTA -> MDA sur le serveur final

Merci pour l'explication :)
Archivé.

> J'ai tenté de lire 3 lignes dans wikipedia, mais à la seconde ligne
> j'avais déjà mal à la tête.

Un peu de fatigue en fin de semaine ? ;-)

C'est pas comme si c'était simple non-plus :)

Le filtrage se fait au niveau du hub central, pas sur chacun des
serveurs qui peut éventuellement envoyer des mails. Il est fréquent, en
effet, que sendmail sur les serveurs ne soit activé que pour examiner
régulièrement la queue de messages à envoyer au hub central, dans ce
cas-là il n'a pas besoin d'écouter.

Oui, c'est ça que je fais sauf erreur.

Mais bon, pas la peine de se prendre
la tête avec ça, vous avez votre solution... ;-)

> Notre admin exchange n'a pas documenté cette partie là, il s'est
^^^^^^^^
Ah oui, mais bon, si vous commencez à dire des gros mots sur un groupe
qui cause d'Unix aussi, là ça va pas aller ! :-D

Arf :)


Merci encore !
--
Nicolas Michel

Bonjour,

Le 26/04/2010 à 12:55, NicolasAlex.Michel.remove@epfl.ch (Nicolas
Michel) a écrit :

Bruno Tréguier <bruno.treguier_at_shom.fr@nullepart.invalid> wrote:

Nicolas Michel wrote:

Comme j'ai activé le masquerading, j'utilises le serveur local plutôt
que le smtp de la boite

Euh... Pas compris. Il part où, le mail, après ? Il faut bien qu'il soit
acheminé ailleurs, non ?

Oui, mais euh ...
Il me semble que si l'authentification peut être requise pour du MSA
le MTA n'est jamais soumis à authentification. Non ?

En interne c'est très rare, effectivement, mais sur Internet, les MTAs
utilisent différents moyens (crypto ou pas) pour évaluer la "réputation"
de leurs homologues (listes noires, SPF, DKIM et autres).

Donc en ayant un sendmail local on fait ensuite du MTA et ça passe.

Tout à fait, on est d'accord. ;-)

Un peu de fatigue en fin de semaine ? ;-)

C'est pas comme si c'était simple non-plus :)

;-)

Bonne fin de semaine !

Cordialement,

Bruno

Le 22/04/2010 16:07, Nicolas Michel a écrit :

Bonjour

Sur un cluster RHEL5 que je n'administre pas,
je cherche à envoyer un mail en cli via mail, mailx, mutt ou autre.

Je pense que tu as déjà obtenu des réponses...
Néanmoins sache que sinon sous RHEL on peut installer postfix qui a un
fichier de conf, comment dire un peu moins chiant à modifier.

Perso, il n'y a plus que sur les serveurs Unix proprio ou je configure
sendmail... parce que virer sendmail et le remplacer par postfix
foutrait la grouille

Cdlt,

LENHOF Jean-Yves <jylenhof@toto> wrote:

Je pense que tu as déjà obtenu des réponses...
Néanmoins sache que sinon sous RHEL on peut installer postfix qui a un
fichier de conf, comment dire un peu moins chiant à modifier.

On est bien d'accord.
Je me demande du reste pourquoi c'est encore sendmail qui est proposé
par défaut.

J'ai soumis l'idée (je ne bosses pas seul) et on va y réfléchir. Mais ça
nous demande de virer sendmail sur tous nos serveurs et le remplacer par
postfix, c'est pas évident que l'effort en vaille la peine vu l'usage
qu'on en a (logwatch et autre retour de log, en gros)

Merci !
--
Nicolas Michel