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 ?
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 ?
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.
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.
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... ;-)
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.
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.
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... ;-)
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.
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.
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... ;-)
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
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
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
Nicolas Michel 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 <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 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 :)
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.
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.
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.
Bruno Tréguier 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
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.
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 ?
Notre admin exchange n'a pas documenté cette partie là, il s'est
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
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.
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 ?
Notre admin exchange n'a pas documenté cette partie là, il s'est
Bruno Tréguier 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
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.
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 ?
Notre admin exchange n'a pas documenté cette partie là, il s'est
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 ?
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
> 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 ? ;-)
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
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 ?
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
> 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 ? ;-)
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
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 ?
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
> 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 ? ;-)
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
Bruno Tréguier 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.
Un peu de fatigue en fin de semaine ? ;-)
C'est pas comme si c'était simple non-plus :)
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.
Un peu de fatigue en fin de semaine ? ;-)
C'est pas comme si c'était simple non-plus :)
Bruno Tréguier 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.
Un peu de fatigue en fin de semaine ? ;-)
C'est pas comme si c'était simple non-plus :)
Bonjour
Sur un cluster RHEL5 que je n'administre pas,
je cherche à envoyer un mail en cli via mail, mailx, mutt ou autre.
Bonjour
Sur un cluster RHEL5 que je n'administre pas,
je cherche à envoyer un mail en cli via mail, mailx, mutt ou autre.
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.
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.
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.