Le service Mail se présente comme une plateforme web sur laquelle une personne authentifiée peut créer des boîtes email et des alias email (une adresse email qui redirige vers une autre adresse email). Trois noms de domaine, pris en charge par l’association, sont mis à disposition : 42l.fr, courrier.dev et kittens.army. Le service supporte également l’ajout de noms de domaine personnalisés sur demande.
Ce service est réservé à nos membres afin d’éviter qu’il explose l’espace disque disponible de nos serveurs.
Le service Mail est le premier service mis en place par l’association, le 10 mai 2019. Pas sans challenge : le développement de l’interface web pour créer des emails et des alias a demandé plusieurs mois de développement, avec tout le reste de la version 1.0 de notre site web.
Nous avons choisi d’héberger ce service car il nous semblait indispensable pour nous et pour les autres, malgré les potentielles difficultés que l’hébergement de ce service pourraient entraîner. Notre choix de la stack logicielle docker-mailserver nous semblait pertinente pour faciliter la maintenance de ce service, puisqu’elle englobe de nombreux logiciels nécessaires à l’hébergement mail.
Le 14 mai 2023, avec la nouvelle version 12.1.0 de l’image parente, nous migrons de la stack logicielle OpenDKIM + OpenDMARC + policyd_spf + Amavis + SpamAssassin vers Rspamd, ce qui dote le service d’une nouvelle interface d’administration des emails et intègre la gestion des filtres Sieve à l’aide du programme ManageSieve.
Nous utilisons l’image docker-mailserver pour faire fonctionner ce service. Cette image contient un ensemble de logiciels : Postfix, Dovecot, OpenDKIM, OpenDMARC, ClamAV, SpamAssassin/Rspamd, Postscreen et d’autres utilitaires essentiels.
Son déploiement requiert l’ouverture d’un certain nombre de ports selon les besoins :
| Protocole | TLS explicite | TLS implicite | Utilisation |
|---|---|---|---|
| SMTP | 25 | N/A | Transfert |
| ESMTP | 587 | 465 | Envoi |
| POP3 | 110 | 995 | Lecture |
| IMAP4 | 143 | 993 | Lecture |
La documentation complète de l’image est disponible ici.
Notre configuration de déploiement (fichiers docker-compose et Dockerfile) se situe sur notre dépôt Core.
Nous avons apporté de nombreuses modifications à l’image originale dans notre Dockerfile. Par ailleurs, certaines de ces modifications peuvent désormais être mises en place avec le fichier user-patches.sh (voir la documentation officielle), qui n’existait pas au moment de la création de cette image.
Notre image contient les particularités suivantes :
Une configuration DNS irréprochable quant aux paramètres SPF, DKIM et DMARC est requise. Pour la configuration des noms de domaine des utilisateur·ices (sur lesquels nous n’avons aucun contrôle), nous utilisons le script mailserver-moulinette pour vérifier la validité de la configuration DNS.
L’installation de cette image est couplée avec le logiciel autodiscover, un petit outil développé en interne qui sert des pages web pour configurer automatiquement les clients mail lors de l’ajout d’une nouvelle boîte mail.
L’ajout d’un nom de domaine passe nécessairement par l’utilisation du script mailserver-moulinette, puis d’une vérification extérieure avec Mail-Tester. Il est possible que le résultat du test n’atteigne pas 10/10 en raison de la réécriture de l’expéditeur, c’est normal.
L’utilisation des tests de configuration de MX Toolbox peut également s’avérer pertinente.
Concernant autodiscover, tenter d’accéder à la page web https://autoconfig.example.org/mail/config-v1.1.xml suffit pour tester le logiciel.
Des boucles de rétroaction ont été mises en place afin de recevoir une alerte si les mails envoyés par notre serveur basculent dans les spams ou passent en liste de blocage auprès de certains fournisseurs. En date de février 2023, ces boucles de rétroaction ne se sont révélées que très rarement utiles.
À plus large échelle, l’utilisation de Google Postmaster est envisageable pour vérifier la bonne recevabilité des emails envoyés vers Google. Son utilisation requiert toutefois un compte Google, et son service ne pourra pas être utilisé tant que le serveur mail n’envoie pas plusieurs centaines de mails par jour vers les serveurs de Google.
En date de février 2023, ce service propose 3 noms de domaine en libre utilisation et 8 autres noms de domaine sont enregistrés par nos utilisateur·ices. Parmi ces 8 noms de domaine, 2 ont expiré (n’ont pas été renouvelés).
Il héberge à ce jour un total de 1051 alias et 211 boîtes mail.
Voici une moyenne journalière du trafic sur ce service :
| Date | Emails reçus | Emails envoyés |
|---|---|---|
| Décembre 2020 | 220 | 221 |
| Décembre 2021 | 355 | 374 |
| Décembre 2022 | 154 | 310 |
Le volume total d’emails hébergés sur ce service atteint 11.09 GB pour plus de 49 000 emails stockés.
Les 10 boîtes mail les plus volumineuses pèsent entre 250 MB et 800 MB chacune. La limite de stockage par boîte mail est de 1 GB, mais personne n’a encore atteint cette limite jusqu’à présent.
Il est important de souligner le poids important du stockage sur ce service après quatre ans de fonctionnement : nos utilisateur·ices utilisent presque systématiquement le protocole IMAP4 (plutôt que POP3) pour accéder à leurs boîtes mail. Par conséquent, les emails sont téléchargés par leurs clients mais laissés sur les serveurs.
Sur nos 147 bénéficiaires de nos services membres (personnes physiques ou morales ayant adhéré au moins une fois), 85 personnes (57 %) possèdent au moins une boîte mail sur notre service mail et 51 personnes (34 %) ont créé au moins un alias.
En production, le conteneur mail consomme environ 600 MB de RAM (ClamAV et fail2ban désactivés, Rspamd actif) et 200 PID (sans doute un par session IMAP ouverte a minima). Sa consommation en RAM a graduellement augmenté au fil des années.
Bien qu’il repose sur un protocole historiquement plus vieux que le Web lui-même, l’email est encore aujourd’hui un service absolument fondamental pour tout le monde : il est nécessaire pour communiquer, demandé pour l’inscription sur n’importe quel site, utilisé pour récupérer l’accès à des comptes dont le mot de passe a été perdu, parfois même demandé lors de la connexion à un compte. C’est la clé de voûte de nos vies numériques.
Les attentes vis-à-vis de ce service sont donc très élevées : il est implicitement demandé une qualité de service irréprochable (bonne réception, très peu d’interruption de service…).
Paradoxalement, c’est un protocole où la bonne réception d’un mail est incertaine : Google (GMail) et Microsoft (Outlook) ont la main sur la grande majorité de l’écosystème mail dans le monde, et n’hésitent pas à classer « malencontreusement » les mails d’un service mail alternatif en spam, en particulier s’il génère peu de trafic. On retrouve également ce comportement chez les grands FAI.
Il est de la responsabilité de l’administrateur·ice système d’assurer une bonne réception des emails chez ces grands fournisseurs. À plus grande échelle, la maintenance d’un tel service nécessiterait sans doute a minima un temps partiel pour entretenir régulièrement des relations avec ces grands fournisseurs et sortir ce service mail des listes de blocage. (Fort heureusement, nous n’en sommes pas là.)
Pour que le service mail ne soit pas recensé dans des listes de blocage, il est absolument indispensable de protéger ce service d’une personne malintentionnée qui pourrait envoyer des mails depuis notre serveur.
C’est notamment pour cette raison que notre service mail est réservé à nos adhérent·es : une personne qui nous a soutenu financièrement nous semble moins susceptible d’utiliser notre service à des fins malveillantes. De ce que nous sachons, nous n’avons jamais eu de problème avec l’un·e de nos membres à ce jour.
Prévenir l’envoi de mails malveillants n’est pas suffisant : il faut également éviter que des personnes qui reçoivent nos mails chez les grands fournisseurs soient trop nombreux·ses à signaler nos mails comme indésirables (ce qui arrive même s’ils ne le sont pas).
Pour cela, il faut s’assurer que les personnes destinataires des emails aient bien consenti à les recevoir, en particulier lorsqu’il s’agit de listes de diffusion. Concrètement, il est difficile de connaître les usages de notre service mail parmi nos utilisateur·ices, mais une certaine vigilance doit être portée sur l’envoi de mails à un grand nombre de personnes.
Enfin, pour que le service mail soit reconnu comme tel par les autres fournisseurs, il doit traiter un volume suffisamment conséquent d’emails par jour.
Les statistiques d’utilisation du service le démontrent : sur le long terme, les emails s’accumulent et la taille des dossiers (ainsi que sa RAM utilisée) ne cessent d’augmenter, ce qui complique l’hébergement du service, en particulier si des contraintes extérieures (financières, techniques, structurelles…) poussent l’organisation à diminuer de taille après plusieurs annéesde fonctionnement.
Raison de plus de limiter ce service à un public restreint (adhérent·es, famille, ami·es…). Définir un quota d’espace disque par boîte mail peut également aider, mais comme notre service offre la possibilité de créer des boîtes mail à volonté, il est théoriquement possible pour nos membres de consommer de l’espace disque à volonté.
La consommation d’espace disque de ce service reste donc un point de vigilance important lors de sa mise en place et de son entretien réguler.
En particulier dans le cadre de la maintenance de l’infrastructure, il est recommandé d’avoir une adresse mail de « backup » chez un autre fournisseur qui serve en cas de problème avec le service mail.
Par exemple, à La Contre-Voie, notre adresse mail de backup nous sert à recevoir des notifications lorsque notre système de supervision externe détecte que l’un de nos services est en panne. En effet, si le service mail fait partie des services indisponibles, nous ne pourrons pas recevoir de notification.
Les efforts d’entretien de ce service sont généralement proportionnels à son utilisation. Il va de soi que si ce service était en libre accès (sans nécessité d’adhésion), il s’agirait d’une toute autre histoire.
L’image mailserver/docker-mailserver incorpore l’outil pflogsumm, qui peut être paramétré pour envoyer un rapport par semaine. C’est la configuration choisie pour La Contre-Voie.
Ce rapport détaille des statistiques importantes pour s’assurer du bon fonctionnement du service : le nombre de mails envoyés et reçus, mais aussi le nombre de mails retardés, rejetés à la réception, rejetés à l’envoi (bounced), les emails annulés ou retenus…
Il affiche également un bref aperçu de chaque message d’erreur pour les mails qui auraient rencontré des problèmes. Ces problèmes ne concernent généralement pas plus de 2% des mails et proviennent généralement de causes extérieures (serveur mail tiers mal configuré, erreur humaine de la part de nos utilisateur·ices, rate limit atteint…).
Toutefois, si notre service mail est bloqué par un autre serveur mail, ce rapport permettra de le savoir rapidement et d’agir en conséquence (en contactant le service pour débannir notre IP).
Si un message relevé par pflogsumm semble indiquer un blocage de notre service, il est possible de consulter le message complet en recherchant dans les logs du service mail.
Pour ajouter un nouveau nom de domaine appartenant à nos utilisateur·ices, il faut suivre la procédure ci-dessous.
Attention : les droits sur ce nom de domaine ne doivent pas nous être cédés, c’est à la personne d’ajouter elle-même les entrées DNS nécessaires pour la validation de son domaine, quitte à organiser une visio pour l’aider si besoin.
docker-mailserver. Exemple : ./setup.sh config dkim keysize 2048 domain example.org. Transmettre cette clé à la personne concernée.
mailserver-moulinette en autonomie jusqu’à ce que toutes les entrées soient ajoutées.
autodiscover sur autoconfig.example.org et autodiscover.example.org, puis recharger le daemon.https://autoconfig.example.org/mail/config-v1.1.xml et https://autodiscover.example.org/mail/config-v1.1.xml sont bien accessibles dans un navigateur sans erreur de certificat.postmaster@example.org, abuse@example.org et dmarc@example.org vers des adresses d’administration. En informer l’utilisateur·ice et lui proposer de créer des alias supplémentaires sur ces adresses vers une adresse qui lui appartient (aucun problème tant que nous recevons les mails qui passent par ces adresses).Rspamd offre une interface web pour visualiser en temps réel les statistiques de réception des emails, connaître la part des emails rejetés et afficher des informations détaillées sur les emails considérés comme spam. Cette interface est configurée pour être servie derrière notre reverse-proxy avec une authentification basique.
Il arrive parfois que les noms de domaine des utilisateur·ices ne soient pas renouvelés, par inadvertance ou de manière délibérée. Lorsque cela arrive, les certificats ne parviennent plus à se renouveler. Une alerte est envoyée par uptime-kuma sur Matrix si le problème n’est pas rapidement résolu.
Il convient de contacter læ propriétaire du nom de domaine pour vérifier si ce non-renouvellement est souhaité, puis de procéder au retrait du nom de domaine de la liste des domaines à certifier. À terme, il sera nécessaire de voir comment bloquer l’usage des noms de domaine abandonnés.
Notre service propose de créer des adresses mail et des alias à volonté, mais par défaut, une personne ne peut créer que 5 boîtes mail et 60 alias. Cette limite initiale vise à empêcher un usage potentiellement abusif de notre service.
Il est toutefois écrit dans notre FAQ qu’il suffit de nous demander pour augmenter cette limite, bien que peu de personnes ne soient au courant.
Lorsqu’on reçoit une telle demande, il suffit d’utiliser adhvalidator pour naviguer vers le compte de l’utilisateur·ice, vérifier que la personne a bien atteint sa limite et augmenter cette limite (Manage users -> User panel -> Edit max aliases / Edit max emails).
Une limite de stockage est mise en place pour éviter que les boîtes mail saturent l’espace disque disponible sur le serveur. Ce quota, très généreux, est fixé à 1 Go.
Le plugin imap-quota de Dovecot est intégré à l’image docker-mailserver et envoie automatiquement des emails de notification lorsque le quota utilisé est à 80%, puis 95% et enfin 100%.
Si le quota est atteint, la boîte mail ne peut plus recevoir d’emails. Il est préférable de contacter les utilisateur·ices avant que cela n’arrive.
Le programme adhvalidator permet de connaître les boîtes mail qui occupent le plus d’espace disque (Manage email accounts -> List the biggest mailboxes).
Si le rapport hebdomadaire indique des erreurs inhabituelles ou si des membres signalent des problèmes de réception, le premier réflexe dans cette situation est de regarder les journaux du service. Les informations suivantes peuvent aider à identifier la récurrence du problème dans les journaux :
Si le problème ne vient pas du client de messagerie utilisé ou d’un serveur tiers, il est nécessaire d’investiguer, chose qui se révèle souvent très chronophage.
Si le problème affecte tout le monde, il doit être traité en priorité critique. Les causes peuvent être multiples et assez imprévisibles.
Comme décrit plus haut, il est possible que notre service mail soit ajouté à une liste de blocage pour une raison quelconque. Dans ce cas-là, l’opérateur qui a listé notre service dispose sans doute d’un formulaire pour demander à le délister, ou une adresse de contact à solliciter pour diagnostiquer le problème.
Par le passé, nous avons rencontré des problèmes à plusieurs reprises avec les listes de blocage intégrées par défaut à docker-mailserver : spamcop, spamhaus… soit faute de résolution DNS, soit d’indisponibilité du service de listes, soit de changement bloquant en amont, soit de problèmes de configuration… Ces incidents menaient au rejet systématique de tous les mails reçus par notre serveur.
Depuis, des mesures ont été prises pour éviter que l’utilisation de ces listes soit une condition absolue pour recevoir des emails.
« Le DNS » peut être une source de si nombreux problèmes.
envelope_sender) lorsque notre serveur est utilisé avec d’autres domaines que notre domaine principal.Toute modification de nos entrées DNS en rapport avec le service mail nécessitent plusieurs jours de supervision pour s’assurer qu’elles ne perturbent pas le fonctionnement du sercice.
Le support d’IPv6 dans l’écosystème des serveurs mail est assez variable. Nous avions initialement paramétré IPv6 sur notre serveur mail, mais un problème logiciel nous a poussé à désactiver IPv6 par la suite dans l’attente que ce bug soit résolu.
Le serveur se heurte souvent à des rate limits de la part de différents opérateurs, dont Google. Cela ne pose théoriquement aucun problème, mis à part que l’envoi des emails est légèrement retardé. De plus, il semblerait que ces rate limits se lèvent progressivement en fonction de la capacité de traitement de notre serveur.
Bien que le service mail soit considéré comme critique, une panne n’est pas grave car dans la majorité des cas, les serveurs mail qui ne parviennent pas à envoyer d’emails à cause d’une panne réessayent dans les 24 heures.
Pour que la panne affecte sérieusement la réception des emails, il faudrait que cette panne s’étende sur plus de 24 heures.
Mettre à jour ce service n’est souvent pas une tâche facile car il y a un risque de briser la compatibilité avec la plateforme web ou de provoquer des changements inattendus.
Voici le procédé habituel :
Actuellement, la plateforme web ajoute des boîtes mail et des alias en se connectant au conteneur mail via SSH. Ce n’est pas du tout standard ni optimal, il nous faudrait un outil modulaire qui se connecte sur une API via HTTP. Un dépôt a été créé en amont pour travailler sur une interface d’administration pour docker-mailserver, mais il semblerait que ce projet n’ait jamais abouti.
Une chose est sûre : avec ou sans API, nous ne pouvons plus utiliser les scripts de la famille de addmailuser pour interagir avec la base de données des comptes. Les daemons postfix et dovecot redémarrent à chaque ajout de nouveau compte, ce qui a pour conséquence d’interrompre toutes les sessions IMAP en cours. À petite échelle, ce n’est pas bien grave car le redémarrage n’est pas assez intempestifpour nuire au service (10 à 20 fois par semaine), mais cette contrainte majeure empêche le service de grandir.
Une fonctionnalité doit être développée pour « désactiver » les boîtes mail dont les noms de domaine ont expiré et empêcher l’usage d’un nom de domaine expiré sur notre service.
Il pourrait être envisageable d’héberger un serveur mail secondaire pour recevoir les emails même lorsque notre serveur principal est inaccessible. Ce mécanisme est possible grâce aux entrées DNS MX. La mise en place d’une telle architecture doit être mûrement réfléchie.
… Et tant d’acronymes qui garantissent théoriquement la bonne réception de nos emails.
Pour le moment, ces dispositifs sont en « bonus » (les plus importants sont DKIM et SPF, éventuellement DMARC), mais la FAQ de Google nous suggère de déployer ARC pour effectuer du forwarding.
Le support que fournit autodiscover est très basique et prend seulement en charge quelques méthode de découverte : celle de Thunderbird, d’anciennes versions de Outlook et de iOS (option cachée qui n’a jamais été présentée dans l’interface web).
Ce logiciel pourrait être amélioré pour couvrir de nouveaux clients.
Actuellement, les certificats TLS de ce service sont générés avec un script dédié qui utilise une image Certbot. L’image docker-mailserver propose toutefois de nombreuses manières de générer un certificat TLS pour ce service.
Par exemple, il est possible d’utiliser Caddy pour générer le certificat plutôt que d’utiliser une cron et son script dédié. Utiliser ce genre de méthode pourrait peut-être diminuer la complexité de notre stack technique.