Description

L'échange de mails est le moyen standard de communication au ResEl. Il permet de nombreuses choses :

  • aux machines d'envoyer des rapports (bugs, logs, ...) aux autres machines (centralisateur de log, voir ELK), ainsi qu'aux admins.
  • aux personnes le souhaitant, d'utiliser un mail @resel.fr
  • de faire circuler des mails d'adresses externes aux adresses internes
  • de mettre en place des mailings-listes

Le ResEl possède une stack de services mail permettant de mettre en place ces échange de mail au sein du réseau.

Cet article décrit l'infrastructure des mails, ses points importants, et sa configuration.

warning Cette page ne traite pas de l'infrastructure des mailing-lists, allez plutôt voir la page sur Sympa pour cela.
De même, cette page ne traite pas de comment obtenir ou utiliser le webmail autohébergé du ResEl, voir la page Adresse mail ResEl.

Contexte

Voici quelques points pour bien remettre en contexte cette page, et pour définir les limites entre ceux à quoi sert la stack.

Fournisseurs externes

La plupart des membres du ResEl utilisent des adresses mail @telecom-bretagne.eu, @imt-atlantique.net voire @gmail.com, ou bien d'autre. Ce sont des fournisseurs de mail externe, et en rien notre infrastructure n'intervient la dedans.

Mécanisme mail Linux

Linux fournit un mécanisme de mail natif, qui permet d'échanger des messages entre les utilisateurs d'un système (command mail). Cependant une machine Linux ne sait pas envoyer ce mail à l'extérieur. Pour ce faire, le système doit avoir un MTA : Mail Transfer Agent, plus de détails plus bas. C'est dans la configuration de ce MTA qu'apparait l'infrastructure mail du ResEl, pour que la machine sache comment envoyer un mail à une adresse.

Mailing-listes

Les mailing-listes sont un outil pratique pour grouper un message pour plusieurs destinataires. Bien entendu, les personnes d'une mailing-listes ont toutes un fournisseur de mail différents, gmail, laposte, ... Le rôle de l'outil de mailing-listes du ResEl (qui est Sympa, plus de détails dans l'article spécifique) est de centraliser et dispatcher les mails envoyer à une mailing-listes. Pour ça il définit des adresses mails reposant sur l'infrastructure mail du ResEl.

Infrastructure

Le petit rappel

Il faut, pour comprendre la mise en place, avoir une bonne idée de comment fonctionne le réseau mail, savoir ce qu'est un MTA, un LDA, les protocoles POP, IMAP et SMTP. On ne vas pas rentrer dans les détails, voir les cours pour cela, cependant voici un schéma résumé :

Il y a, comme vous le savez, deux concepts fondamentaux pour les mails : l'envoi de mail et leur routage par un MTA avec le protocole SMTP(S), et la réception et synchronisation des boîtes mails par un LDA avec les protocoles IMAP(S) ou POP(S) qui échange avec le MUA, càd le client mail de l'utilisateur (ou le webmail).

Entre deux clients "normaux" : Alice (chez orange) envoie un mail à Bob (chez Gmail)

{{{{{{ note left of Alice: Have a mail to send Alice->MTA Orange: Send mail [SMTP] MTA Orange->MTA Gmail: mail [SMTP] MTA Gmail->LDA Gmail: mail [SMTP] note right of Bob MUA: Want to check email Bob MUA->LDA Gmail: Get mail [IMAP] LDA Gmail->Bob MUA: Ok, here are your mails [IMAP] }}}}}}

Lorsqu'un MTA doit envoyer un mail, la plupart du temps il va récupérer le domaine de l'adresse (bob@orange.fr --> orange.fr) et faire une résolution du MX : c'est-à-dire, que pour un domaine domain.tld, le MTA va faire une résolution DNS pour obtenir le serveur mail (Mail eXchange) de ce nom de domaine (via la commande dig domain.tld MX) ; si le DNS est bien configuré, il va donner l'adresse en charge du serveur mail pour domaine. Dès lors le MTA saura à qui forwarder le mail.

Le MTA peut bien entendu être configuré autrement, en particulier lorsque le mail est pour son réseau, pour le distribuer au LDA. De même, le MTA peut-être configuré en simple relai, c'est-à-dire que sa seule tâche sera de tout forwardé vers un autre MTA, agissant comme un switch.

Ici le schéma explique bien ce qu'il se passe pour deux utilisateurs "humains", mais lorsque l'utilisateur qui envoie est une machine, elle n'utilise pas de client mail (MUA). Dans ce cas là, la machine possède son propre MTA, qui est configuré et qui lui suffit à elle même. Elle pourrait si elle le souhaite envoyer des mails directement à un autre MTA de fournisseur (gmail, ...) mais ça ne suffira pas dans la plupart des cas, car déjà il faudrait que cette machine possède un DNS qui résolve le MX de ce domaine vers cette machine... La plupart du temps le MTA est donc configuré pour relayer vers le MTA central à l'organisation (par exemple le ResEl...)..

Glossaire / Définitions

Dans cette article, on adopte les notations suivantes :

  • MTA : Mail Transfer Agent
  • LDA : Local Delivery Agent
  • MUA : Mail User Agent
  • Utilisateur : un utilisateur du service mail est quelqu'un avec une adresse mail en @ * .resel.fr. Cela peut être une personne physique ou une machine.

Au ResEl

Au ResEl, nous avons deux machines importantes dans la stack. Tout d'abord Toad agit comme serveur mail. C'est lui qui héberge le MTA principal : Postfix qui route les mails entrants et interne. Il héberge aussi Dovecot, le LDA des utilisateurs. Finalement il héberge aussi Roundcube, un webmail.
Le DNS est configuré pour résoudre le MX de resel.fr en mail.resel.fr qui pointe vers Toad.

Puis il y a Pégase, qui est configurée en relai mail interne. Elle héberge une instance de Postfix qui relaie tout les mails du domaine vers Toad.

Finalement, chaque serveur du ResEl à une instance Postfix, configurée pour contacter le MTA de Pégase en relai mail.

{{{{{{ note left of TheVM: Cron tasks logs error via mail to lcarr@resel.fr TheVM->MTA Local: Send mail [SMTP] MTA Local->MTA Pegase: mail [SMTP] MTA Pegase->MTA Toad: mail [SMTP] MTA Toad->LDA Toad: mail [SMTP] note right of lcarr MUA: Want to check email lcarr MUA->LDA Toad: Get mail [IMAP] LDA Toad->lcarr MUA: Ok, here are your mails [IMAP] }}}}}}

Utilisation

Côté utilisateur

En tant qu'utilisateur (càd machine ou autre), la première étape est de configurer le MTA local à la machine.

Configurer Postfix pour une machine

Il s'agit ici de configurer le MTA d'une machine, ici on choisit Postfix comme MTA, pour qu'il envoie les mails aux bon MTA relai. On configure aussi l'email destinataire de la machine. A noter qu'il n'y a pas d'authentification, une machine peut choisir l'adresse e-mail qu'elle souhaite.

Configuration initiale de postfix

En lançant un apt install postfix, une interface de configuration debconf se lance. S'il est déjà installé, utilisez dpkg-reconfigure postfix.

Suivez les étapes :
1. Sélectionner Internet with smarthost, ok.
2. Choisir le system mail name : <nom de la machine>.adm.resel.fr, ok.
3. Ajout du relais pegase.adm.resel.fr. ok.

Modification de main.cf

Il est maintenant nécessaire d'ajouter un alias pour transmettre les mails à @resel.fr au lieu de @<machine>.adm.resel.fr.

On va donc modifier le fichier indiqué /etc/postfix/main.cf. Normalement, dans le dernier bloc de texte, vous pouvez lire la ligne 

relayhost = pegase.adm.resel.fr

Par défaut, Postfix va résoudre le MX du relai. Or ce n'est pas souhaité, en effet, s'il résoud le MX, comme expliqué plus haut il enverrait le mail à Toad. On empêche ce comportement on met des crochets autour, voir la doc de postfix) : 

relayhost = [pegase.adm.resel.fr]

Modification des alias

Pour rediriger les mails vers les @resel.fr, on va maintenant modifier le fichier contenant les alias /etc/alias. Ce fichier spécifie que faire d'un mail envoyé à un alias précisés dans cette configuration. Par défaut on précise à qui envoyer le mail, mais on peut aussi faire des choses plus puissantes comme piper le mail à un programme...

On va modifier le fichier de sorte que tous les messages soient plutôt envoyés à root@resel.fr, et les mails de sécurité vers security@resel.fr. De cette manière, on a envoie tous les mails des machines aux heureux inscrits à la mailing-liste de flood. 

# /etc/aliases
mailer-daemon: postmaster
postmaster: root
nobody: root
hostmaster: root
usenet: root
news: root
webmaster: root
www: root
ftp: root
abuse: root
noc: root
security: security@resel.fr
root: root@resel.fr

Application des changements

Il faut regénérer la base de données des alias : 

newaliases

Puis recharger postifx.

/etc/init.d/postfix reload

Côté administrateur

Un adminstrateur aura besoin de gérer la stack mail pour plusieurs raisons :

  • Gérer les boîtes mails, notemment pour vider les boites trop pleines qui encombrent les disques
  • Diagnostiquer l'état de la stack
    • État des queues de mails en attente du MTA
    • Autres...

Gestion des boîtes mails Dovecot

Commandes utiles

  • doveadm user $username
  • doveadm mailbox list -u $username

Pour connaître la taille de la boite mail (potentiellement très long): doveadm -f table mailbox status -u $username "messages vsize" INBOX

Pour totalement vider la boite mail d'un utilisateur (attention, suppression non réversible) doveadm -v expunge -u $username mailbox INBOX all

Gestion de la file d'attente

La file d'attente des messages est gérée par postqueue.

Afficher le nombre de messages dans la queue: postqueue -p | tail -n 1. Afficher les messages dans la queue: postqueue -p. Retenter l'expédition des messages dans la queue: postqueue -f (déplace tous les messages dans la queue active).

Configuration

Postifx

postconf -n pour déboguer.

Liens utiles / Ressources internes