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. Il existe aussi une configuration en smart host ce qui est équivalent à un relai à l'exception qu'en général les smart host identifie les clients qui s'y connectent.

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, Postfix est accompagné par plusieurs plugins (amavis, ...). 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.

Envoi d'un mail par une machine : TheVM à lcarr@resel.fr

{{{{{{ 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

Postfix maître

Serveur MTA Postfix principal sur Toad.

La configuration de Postfix est située dans plusieurs fichiers dans le dossier /etc/postfix :

  • master.cf : le fichier de configuration des plugins du daemon et autres programmes de traitement annexes.
  • main.cf : le fichier de configuration du coeur de Postfix.
  • aliases : contient les alias pour les listes de diffusion.
    Ce fichier contient des aliases, pour définir des aliases plus court pour des mails. Cela permet aussi de faire des mailing-listes. Le tout est fait en dur, et ne correspond pas aux mailing-listes utilisateurs avec Sympa.
    Syntaxe : partie_gauche_adresse_locale alias, par exemple nimag42 theo.jacquin@resel.fr indique qu'un envoie de mail à nimag42 doit être fait à theo.jacquin@resel.fr. Avec plusieurs destinataires : listmaster: lcarr, nimag42, morgan.robin@telecom-bretagne.eu.
    Après modification, il faut recharger les aliases avec postalias.
  • transport : règles particulières de transport pour certains domaines
    syntaxe : recipient_destination protocol:domain_a_envoyer. On peut utiliser les [ ] pour empêcher la résolution du MX. Par exemple : cyric.adm.resel.fr smtp:[cyric.adm.resel.fr], si le domaine de l'adresse mail du destinataire est cyric.adm.resel.fr, le mail sera envoyé par smtp directement à la machine, sans résolution du MX. Après modification, il faut recharger le mapping avec postmap /etc/postfix/transport.
  • recipient_canonical_pcre : permet de réécrire le destinataire par une regexp.
    Syntaxe : /regexp_email/ /regexp_capture_email/. Par exemple /^(.*)@tb$/ ${1}@telecom-bretagne.eu remplace tout les mails en @tb en mails en @telecom-bretagne.eu. Le ${1} est le paramètre de capture des Regexp Perl classique.
  • recipient_restrictions_pcre : permet de filtrer par destinataire par une regexp.
    Syntaxe : /regexp_email/ (REJECT|OK). Par exemple /^(.*)@(.+)\.maisel\.enst-bretagne\.fr$/ REJECT rejette les mails à destination d'un mail en @ * .maisel.enst-bretagne.fr. Les règles sont lises dans l'ordre, donc ajouter les exceptions avant une règle globales. On peut aussi préciser directement un code d'erreur et un message.
  • sender_restrictions_pcre : permet de filtrer par l'expéditaire par une regexp.
    La syntaxe est la même que pour recipient_restrictions_pcre.

On peut lire la configuration globale avec la commande postconf -n.

Postfix est contrôlé par un service SysVinit : service postfix (start|stop|reload).

Général

Voici des extraits importants de la configuration

D'abord, on définit les fichiers contenants les confs externes, commes les aliases, les pcre, etc.. : 

alias_database = hash:/etc/postfix/aliases, hash:/etc/mail/sympa/aliases, hash:/etc/mail/sympa_aliases
alias_maps = hash:/etc/postfix/aliases, hash:/etc/mail/sympa/aliases, hash:/etc/mail/sympa_aliases
recipient_canonical_maps = pcre:/etc/postfix/recipient_canonical_pcre
sender_canonical_maps = pcre:/etc/postfix/sender_canonical_pcre
smtp_header_checks = pcre:/etc/postfix/anonymize_headers.pcre
transport_map = /etc/postfix/transport

Ensuite une partie pour configurer le chiffrement TLS.

Puis la configuration pour l'acheminement des mails : 

myhostname = mail.resel.fr
mydomain = maisel.resel.fr
transport_maps = hash:/etc/postfix/transport
myorigin = resel.fr
mydestination = $myhostname, resel.enst-bretagne.fr, resel.fr, resel.eu,
        localhost, localhost.localdomain, localhost.resel.fr
relayhost =
address_verify_relayhost =

home_mailbox = Maildir/
mail_spool_directory = /srv/mail
mailbox_command = /usr/lib/dovecot/deliver
dovecot_destination_recipient_limit = 1
fallback_transport = dovecot
Tout d'abord on précise de la fichier de transport pour les exceptions de transports. Si aucune exception n'est levée, on vérifie le domaine du mail. La variable mydestination contient les domaines qui vont êtres forwardé vers le MDA pour être délivrés.
Les mails délivrés sont configurés ensuites avec toutes les variables suivantes.

Si les mails ne sont pas pour le domaine local, la variable relayhost indique le relai vers qui vont être envoyer les mails. Ici il est vide, indiquant qu'une résolution du MX doit être fait sur le domaine du destinataire.

Enfin diverses configuration permettent de récuperer les utilisateurs de mails resel depuis le LDAP : 

ldap_virtual_redirection_server_host = ldap.resel.fr
ldap_virtual_redirection_search_base = dc=maisel,dc=enst-bretagne,dc=fr
ldap_virtual_redirection_timeout = 15
ldap_virtual_redirection_query_filter = (&(objectClass=mailPerson)(mailLocalAddress=%s)(mailRoutingAdd$
ldap_virtual_redirection_result_attribute = mailRoutingAddress
ldap_virtual_redirection_bind = no

ldap_virtual_uid_resolution_server_host = ldap.resel.fr
ldap_virtual_uid_resolution_search_base = dc=maisel,dc=enst-bretagne,dc=fr
ldap_virtual_uid_resolution_timeout = 15
ldap_virtual_uid_resolution_query_filter = (&(objectClass=mailPerson)(uid=%s))
ldap_virtual_uid_resolution_result_attribute = mailLocalAddress
ldap_virtual_uid_resolution_bind = no

ldap_mailbox_maps_server_host = ldap.resel.fr
ldap_mailbox_maps_search_base = dc=maisel,dc=enst-bretagne,dc=fr
ldap_mailbox_maps_timeout = 15
ldap_mailbox_maps_query_filter = (&(objectClass=mailPerson)(mailLocalAddress=%s))
ldap_mailbox_maps_result_attribute = mailDir
ldap_mailbox_maps_bind = no
Le premier bloc permet les envoie de mail par adresse prenom.nom@resel.fr, le second les uid@resel.fr et le dernier donne le chemin vers la boite mail pour un utilisateur.

Filtres

On peut utiliser des filtres pour par exemple filtrer les spams.

Amavis

Amavis est un plugin qui sert à filtrer les spams.

Pour la configurer, dans /etc/postfix/master.cf, on définit un client smtp qui va se connecter au pseudo serveur mail d'AmavisdNew pour lui transférer les mails à traiter. 

# La suite de la configuration est utilisee pour la communication entre
# Postfix et Amavisd-new. Voir la documentation de Amavisd-new
# Guillaume D.

# ============================================================================
# service 	type	private	unpriv	chroot	wakeup	maxproc	command + args
# 			(yes)	(yes)	(yes)	(never)	(50)
# ============================================================================
smtp-amavis 	unix	-	-	n	-	5	smtp
	-o smtp_data_done_timeout=1200
	-o disable_dns_lookups=yes

Puis on définit un démon smtpd sur le port 10025 qui va récupérer les mails une fois qu'ils auront été filtrés par AmavisdNew. Le -o content_filter= est extrêmement important car sinon les mails repasseraient en boucle infinie dans le filtre.

127.0.0.1:10025	inet	n	-	n	-	-	smtpd
	-o content_filter=
	-o local_recipient_maps=
	-o relay_recipient_maps=
	-o smtpd_restriction_classes=
	-o smtpd_client_restrictions=
	-o smtpd_helo_restrictions=
	-o smtpd_sender_restrictions=
	-o smtpd_recipient_restrictions=permit_mynetworks,reject
	-o mynetworks=127.0.0.0/8
	-o smtpd_error_sleep_time=0
	-o smtpd_soft_error_limit=1001
	-o smtpd_hard_error_limit=1000

Dovecot maître

Le serveur LDA Dovecot principal est sur Toad.

La configuration de Dovecot est située dans plusieurs fichiers dans le dossier /etc/dovecot :

  • dovecot.conf : fichier de configuration globale qui inclut les autres fichiers de conf
  • conf.d/ : dossier dont tout les fichiers *.conf sont inclues.
    Dedans, la plupart des fichiers sont la configuration classiques.
  • dovecot-ldap.conf.ext : configure la connexion LDAP. 
    uris = ldap://ldap.resel.fr/
base = dc=maisel,dc=enst-bretagne,dc=fr
scope = subtree

user_attrs = homeDirectory=home, Homedirectory=mail=%$/Maildir, homeDirectory=mail=maildir:%$/Maildir
user_filter = (&(objectClass=mailPerson)(|(Maillocaladdress=%u)(uid=%u)))

pass_attrs = uid=user
pass_filter = (&(objectClass=mailPerson)(|(Maillocaladdress=%u)(uid=%u)))
default_pass_scheme = SSH
    Cette configuration précise l'adresse du ldap, la branche de base ainsi que l'exploration autorisée à tout le sous-arbre.
    Puis on indique à dovecot dans user_attrs sous la forme LDAP-name=dovecot-internal-name les attributs qui vont être récupérés dans le LDAP. Il peut y avoir uid, gid, home et mail. On note que le code %$ indique le répertoire physique sur le serveur où sont situés les mails de l'utilisateur. Ensuite on utilise user_filter pour filtrer les utilisateurs qui ont un compte mails.
    Finalement on indique comment récuperer le mot de passe pour le compte utilisateur.

On peut lire la configuration globale avec la commande postconf -n.

Tout d'abord des configurations globales pour définir des comportement, la location de stockage des mails mail_location = maildir:/var/mail/virtual/%n/Maildir, les compatibilités, la définitions des dossiers par défaut des boîtes (Inbbox, Drafts, ...).
Puis on définit le passdb pour contacter le ldap : 

passdb {
  args = /etc/dovecot/dovecot-ldap.conf.ext
  driver = ldap
}
Puis on définit le plugin Sieve, Sieve est une RFC pour un langage de filtrage de mails : 
plugin {
  sieve = ~/.dovecot.sieve
  sieve_dir = /var/mail/virtual/%u/sieve
  sieve_global_dir = /var/mail/virtual/%d/sieve
}
Enfin on définit des paramètres pour les certificats SSL, les chemins de logs, et on configure LMTP qui un protocole Linux d'envoi de mail (avec la commande mail).

Webmail

Le webmail est Rainloop, sur Toad, plus de détails sur l'article les mails @resel.

Serveur postfix relai

Serveur MTA Postfix relai sur Pégase.

Un extrait intéressant de la configuration générale dans main.cf indique: 

myhostname = pegase.adm.resel.fr
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = pegase.adm.resel.fr, localhost.adm.resel.fr, localhost
relayhost = smtp.resel.fr

On indique d'abord les aliases des mails locaux, puis on définit le hostname et l'origine à pegase.adm.resel.fr. Les domaines de mydestination sont ceux classsiques pour n'importe quel machines.
Le paramètre important est le relayhost, qui vaut smtp.resel.fr dont la résolution du MX va joindre Toad.

Serveur postfix "client"

MTA Postfix client sur toute les autres machines.

Cf les étapes pour l'utilisation côté utilisateur.

Liens utiles

Articles connexes

Ressources externes

TODO (rédacteur)

  • Points de configuration
  • Détailler des cas d'utilisation