J’ai effectué courant décembre 2020, une migration de mes services auto-hébergés vers une nouvelle machine. Ayant réorganisé en 2019 l’ensemble de mes roles Ansible, et passant d’une base Debian 9 à Debian 10, de nombreuses corrections ont une nouvelle fois été nécessaires avant que l’ensemble soit à nouveau déployé correctement de manière automatique. La majorité des adaptations provenaient du passage à php7.4, avec un test de la version 8 (encore trop récente pour plusieurs services). Le reste concernait l’envoi de mail depuis le serveur avec exim4.
En commençant l’aventure de l’auto-hébergement, la question de l’envoi des mails ne s’était pas posée, car, dans mes souvenirs en tout cas, WordPress arrivait à me notifier par mail sans avoir de modification à effectuer au niveau du système Debian fournit avec le serveur Kimsufi que j’utilisais à l’époque. En migrant par la suite sur un VPS et en auto-hébergeant certains services à mon domicile, l’envoi de mail avait cessé de fonctionner et j’avais choisi d’ignorer la question jusqu’à la mie 2019, où j’avais réussi à produire une configuration fonctionnelle, en utilisant les serveurs de mail de l’hébergeur. Une nouvelle migration d’Unicoda courant 2020 avait à nouveau rendu l’envoi de mail inopérant. Idem avec la récente migration de ma machine locale.
Afin de continuer de recevoir les notifications liées à l’exécution des sauvegardes journalières de l’ensemble des services, et de bénéficier à nouveau des notifications WordPress, comme celles des nouveaux commentaires, je me suis donc replonger dans les profondeurs de la configuration des services mails sous GNU/Linux, afin de corriger le rôle Ansible responsable de la configuration automatique des services mails.
Voici donc à la suite, le résultat de mes notes de 2019, adaptées et corrigées après les recherches de décembre l’an dernier. J’espère ne pas avoir oublié d’étapes, mais les essais successifs de paramètres différents conduisent parfois à des incohérences, lorsque les notes ne sont pas mises à jour avec les dernières modifications effectuées à l’issue d’une session éreintante de débogage :). Par ailleurs, si mon rôle Ansible a bien été mis à jour, il me reste néanmoins à le tester une nouvelle fois, sur un système vierge, dans l’idéal, afin de garantir son bon fonctionnement. Cela étant dit, voici la configuration qui permet à mes serveurs d’envoyer des mails.
Configuration
Commençons par installer les composants nécessaires:
sudo aptitude install exim4 openssl ca-certificates mailutils
Je modifie ensuite /etc/email-addresses pour lier utilisateurs locaux et adresses mails. Ici, le but est de renvoyer tout vers l’adresse example@unicoda.com (adresse fictive pour l’exemple):
root : example@unicoda.com monUtilisateur : example@unicoda.com * : example@unicoda.com
Manipulation similaire, cette fois dans /etc/aliases , puis j’exécute la commande newaliases :
root: monUtilisateur monUtilisateur : example@unicoda.com
Je modifie ensuite le fichier /etc/exim4/passwd.client, pour y ajouter une ligne contenant les informations de connexion au serveur mail choisi pour l’envoi, de la forme target.mail.server.example:login:password , et lui applique un masque 640 pour les autorisations d’accès.
Avant d’aller plus loin dans la configuration, je m’assure également que mon fichier /etc/hosts contient une ligne faisant pointer le hostname de la machine vers elle-même, soit la ligne 127.0.0.1 hostname. Par ailleurs, je modifie également /etc/mailname pour y ajouter le hostname, cette modification m’ayant été particulièrement utile pour le cas d’un message à destination d’un utilisateur de la machine, soit par exemple root@hostname.
Étape suivante, déploiement du fichier /etc/exim4/exim4.conf.localmacros avec le contenu suivant, pour l’utilisation de TLS et du port 465:
MAIN_TLS_ENABLE = 1
REMOTE_SMTP_SMARTHOST_HOSTS_REQUIRE_TLS = *
TLS_ON_CONNECT_PORTS = 465
REQUIRE_PROTOCOL = smtps
IGNORE_SMTP_LINE_LENGTH_LIMIT = true
Avant de continuer plus avant, il faut créer un certificat TLS pour exim4, on peut se baser pour cela sur l’étape 4 de ce tutoriel, qui donne la commande à exécuter. De mon côté, j’utilise les modules openssl_privatekey, openssl_csr et openssl_certificate dans ansible pour réaliser ces opérations.
J’apporte quelques modifications au fichier /etc/exim4/update-exim4.conf.conf, correspondant aux étapes 9 et 10 du tutoriel cité ci-dessus, à savoir, l’ajout du bloc suivant, juste avant la ligne .ifdef REMOTE_SMTP_HEADERS_REWRITE (étape 9):
.ifdef REQUIRE_PROTOCOL protocol = REQUIRE_PROTOCOL .endif
Ainsi que le bloc suivant, juste après la ligne (étape 10):
.ifdef TLS_ON_CONNECT_PORTS tls_on_connect_ports = TLS_ON_CONNECT_PORTS .endif
Enfin, édition du fichier /etc/exim4/update-exim4.conf.conf pour spécifier le comportement d’exim4, qui peut également être généré dynamiquement via sudo dpkg-reconfigure exim4-config. À noter, que le mode satellite ne prend pas en considération l’envoi local, et ne tient donc pas compte des alias configurés (comme précisé dans ce message). Pour être complet, je lui ai donc préféré le mode smarthost. J’ai pour ma part changé le dc_readhost par rapport au tutoriel dont je me suis inspiré, qui proposait localhost comme valeur. Je crois me souvenir que localhost ne fonctionnait pas dans mon cas, mais une nouvelle série de tests avec cette configuration ne serait pas inutile pour être fixé.
dc_eximconfig_configtype='smarthost' dc_other_hostnames='' dc_local_interfaces='127.0.0.1 ; ::1' dc_readhost='unicoda.com' dc_relay_domains='' dc_minimaldns='false' dc_relay_nets='' dc_smarthost='target.mail.server.example::465' CFILEMODE='644' dc_use_split_config='false' dc_hide_mailname='true' dc_mailname_in_oh='true' dc_localdelivery='mail_spool'
Nous y sommes presque, il suffit à présent de déployer la configuration exim4 via sudo update-exim4.conf, puis de redémarrer le service avec la commande sudo service exim4 restart. On peut ensuite essayer d’envoyer un mail depuis la machine avec echo "test" | mail -s "Test" example@unicoda.com. Si tout va bien, le mail arrive correctement à l’adresse fournie, sinon, il vous faudra, comme moi, parcourir les logs (sudo tail /var/log/exim4/mainlog) pour comprendre la nature du problème de configuration et parcourir les nombreux sujets et documentation autour d’exim4.
Pour finir, avant une liste d’article qui m’avait été utile lors de la configuration, voici encore quelques commandes utiles pour déboguer une configuration exim4 non fonctionnelle.
Commandes
Consulter la liste des messages gelés.
exim4 -bp
Supprimer tous les messages gelés.
exiqgrep -z -i | xargs exim -Mrm
Sources
- Gmail and Exim4 As MTA With Implicit TLS
- Configuration d’Exim sous Debian Jessie pour de l’envoi de mails
- exim4 with wildcard email aliases
- Exim – Debian Wiki
