Exploiter son propre serveur e-mail comme en 1984

• Exploiter soi-même un serveur e-mail permet de gérer à faible coût des tâches d’automatisation et des mailing lists
• Il existe toutefois en pratique un problème de fiabilité de livraison, avec un risque d’échec d’envoi ou de réception avec les grands services
• La configuration de Postfix et d’OpenDKIM suffit pour mettre en place un système de base d’envoi SMTP et d’e-mails authentifiés
• La configuration de certificats SSL, DKIM, SPF et DMARC permet d’améliorer la fiabilité des e-mails et la sécurité du transport
• En configurant aussi un enregistrement PTR (DNS inverse), on peut espérer améliorer le taux de délivrabilité vers les grands services de messagerie

---

Vue d’ensemble

Exploiter son propre serveur e-mail est utile pour des tâches automatisées comme les mailing lists, newsletters, API de vérification par e-mail
Mais la principale difficulté concrète reste la fiabilité de livraison : il existe un risque que les messages n’arrivent pas correctement ou que leur réception échoue
L’auteur applique cette approche à des projets personnels en acceptant ce risque
L’avantage d’une exploitation en direct est qu’elle n’entraîne presque aucun coût supplémentaire : il suffit d’installer le logiciel sur un site web existant, et les besoins en stockage comme en énergie sont très faibles
Cela paraissait trop difficile au départ, mais en pratique ce n’est pas beaucoup plus complexe que la configuration d’un service e-mail de type SaaS
Pour faciliter la configuration et simplifier l’ensemble, le webmail et l’environnement multi-utilisateur sont laissés de côté dans un premier temps, ce qui évite d’avoir à mettre en place des comptes utilisateurs, une base de données et une interface web
Cette configuration convient à un usage avec un seul compte, et permet si besoin d’envoyer et de recevoir des e-mails via SSH avec mailx, sendmail, mutt, etc.
Il sera toujours possible d’étendre ensuite l’installation et d’ajouter un webmail selon les besoins

Postfix

En ouvrant simplement le port 25 puis en installant et configurant Postfix et OpenDKIM, il est possible de mettre en place un serveur SMTP de base
Pour délivrer les e-mails de façon fiable à la plupart des services de messagerie, comme Gmail, OpenDKIM (authentification des e-mails) est nécessaire
L’auteur a conservé les valeurs par défaut de master.cf, et l’exemple de configuration principal (main.cf) ne montre que les paramètres essentiels comme le chiffrement TLS et l’intégration de DKIM
POP3/IMAP n’est pas configuré, afin de rester simple, et en cas de besoin il suffit de se connecter directement au serveur en SSH pour envoyer et recevoir des e-mails avec des commandes comme mailx

TLS (chiffrement du transport)

Un certificat SSL est nécessaire pour chiffrer le transfert des données avec le serveur SMTP
Il n’est pas nécessaire d’émettre un certificat pour chaque domaine : un certificat pour l’hôte unique où se trouve le serveur de messagerie (celui de l’enregistrement MX) suffit
Par exemple, si l’enregistrement MX est mx.example.com, il suffit d’obtenir et d’appliquer un certificat gratuit Let’s Encrypt pour ce domaine
TLS ne chiffre que le transport entre serveurs et est distinct de l’authentification du véritable nom de domaine expéditeur
On peut donc définir librement la valeur souhaitée dans l’en-tête From de l’adresse e-mail

DKIM, SPF, DMARC

DKIM sert à prouver que l’e-mail provient bien de votre véritable domaine, afin d’améliorer sa fiabilité
Avec OpenDKIM, on crée une paire de clés pour chaque domaine, puis on publie la clé publique dans un enregistrement DNS TXT
Les clés n’expirent pas automatiquement, mais une rotation régulière est recommandée
Il faut aussi ajouter dans le DNS des enregistrements TXT SPF et DMARC pour définir quels hôtes sont autorisés à envoyer des e-mails et quelle politique DMARC appliquer, par exemple le rejet en cas d’échec d’authentification
Les exemples de fichiers de configuration (opendkim.conf, KeyTable, SigningTable, TrustedHosts) montrent clairement comment régler chaque élément
Côté DNS, il suffit d’ajouter les enregistrements liés à MX, SPF, DKIM et DMARC

DNS inverse (PTR)

Un enregistrement PTR (DNS inverse) renforce la crédibilité du serveur e-mail et augmente les chances que les messages ne soient pas bloqués par les grands services comme Gmail
Il faut contacter son FAI pour demander la configuration d’un enregistrement PTR pour le serveur e-mail
Dans l’environnement réellement déployé, même sans enregistrement PTR, les e-mails ont bien été reçus par Gmail, GMX et Outlook, et mail-tester.com a attribué une note de 10/10
L’absence de PTR entraînait une pénalité, mais elle a été compensée par un bonus de « trusted relay »
L’adresse IP d’envoi n’était pas non plus sur liste noire, ce qui indique une bonne réputation

Test d’envoi vers Gmail

Un e-mail de test (message HTML) a été envoyé vers Gmail avec la commande sendmail
Le message est arrivé immédiatement dans Gmail, et le chiffrement TLS a bien été confirmé
Dans « Show original », on peut voir que les vérifications SPF, DKIM et DMARC sont validées
Il est aussi possible de consulter les e-mails reçus en local (sur le serveur) avec mailx
En cas de problème de configuration, il faut revérifier le DNS, les certificats et les droits d’accès à la clé DKIM ; les fichiers de configuration d’OpenDKIM sont particulièrement sensibles aux fautes de frappe

Étapes suivantes

Le prochain article expliquera comment créer une application e-mail en Python
Pour toute question ou remarque, il est possible de contacter [e-mail]

[GN⁺]

Commentaires Hacker News

• Je suis fier d’héberger moi-même mon e-mail depuis plus de 20 ans, et je compte continuer. Pendant ce temps, les gouvernements et administrations concernés ne font même pas tourner leurs propres systèmes de messagerie, à l’exception des services nationaux de sécurité qui, eux, auto-hébergent. J’ai sans doute eu de la chance, car j’ai eu très peu de problèmes d’envoi. Le seul cas récent dont je me souvienne, c’est Microsoft qui avalait mes mails, à cause d’un vieux Exim et d’un cafouillage de certification TLS côté Outlook. J’ai réglé ça avec un simple ajustement de configuration. La maintenance ne demande pas tant d’efforts que ça, et j’en profite pour apprendre quelque chose de nouveau à chaque fois que j’y touche. Cette année, j’ai remplacé Debian jessie par Arch Linux et migré complètement mes tâches cron vers des timers systemd. Quand j’envoie des mails importants, je vérifie toujours les logs du serveur, mais je considère aussi que c’est une bonne habitude de regarder soi-même les journaux. Mon conseil, c’est de voir l’auto-hébergement comme un hobby et d’y prendre plaisir. Enfin, la personne qui a conçu la configuration Exim sur Debian m’a fait perdre un temps fou. Si vous déployez Exim sur Debian, le mieux est de repartir de la configuration officielle upstream et de la personnaliser selon vos besoins

  • Les réseaux sociaux actuels se vantent de leur côté « décentralisé » ou « ouvert », mais en réalité nous avons déjà des outils qui permettent d’être totalement indépendants. À force de vouloir améliorer l’UX, on oublie que le contrôle de l’utilisateur disparaît. Et si on s’habitue à des systèmes excessivement simplifiés, on finira dans un monde où l’on ne pourra même plus installer une appli sans que quelqu’un, à l’autre bout du pays, n’« autorise » la transaction

  • J’ai utilisé l’e-mail pour la première fois à l’université, avant le WWW, puis avec un compte ISP qui n’offrait qu’un espace de stockage minuscule et uniquement du POP, ce qui m’a poussé à faire tourner mon propre serveur mail. Comme je n’étais pas toujours connecté à Internet, je recevais les mails via un relais et du DNS dynamique. Aujourd’hui, je passe par un VPS qui transmet les messages à mon serveur domestique pour les stocker. Au fil des ans, il m’est arrivé de devoir demander à Outlook et à d’autres grands services de lever un blocage d’IP ou de domaine, mais ce n’était pas si fréquent. Je n’ai pas envie de vivre dans un monde où deux ou trois entreprises dominent l’e-mail mondial, donc je vois cet auto-hébergement comme une petite forme de résistance

  • J’aimerais qu’il me reste ne serait-ce que 1 % de la motivation que j’avais il y a 20 ans. Aujourd’hui, entre le travail à temps plein et la famille — ma femme et mes enfants — je n’ai plus du tout le temps pour ce genre de choses

  • Moi aussi, à une époque, je me suis éloigné de l’auto-hébergement, mais je me demande si ça ne redeviendrait pas intéressant maintenant que l’équilibre temps/coût a changé. Ce qui me fait le plus hésiter pour l’hébergement mail, c’est la gestion du spam. Comment ça se passe aujourd’hui ? Si vous avez des conseils, je suis preneur

  • Pour moi, l’e-mail est un service critique. Après 15 ans d’auto-hébergement, j’ai arrêté pour trois raisons : 1) je ne gérais pas correctement les sauvegardes/restaurations régulières et la supervision, 2) sans plan de reprise après sinistre, ça me coûtait plus cher que d’autres services, 3) je n’étais pas capable de rester constamment vigilant sur la sécurité. Le serveur d’un ami a été frappé par un ransomware et il a tout perdu, alors que moi j’étais sur FreeBSD et j’ai été épargné, simplement parce que ce n’était pas une cible. En général, la maintenance n’est pas si compliquée, mais quand ça part de travers, ça peut devenir vraiment pénible, voire critique

• Avant, j’hébergeais moi-même mon e-mail, mais j’ai abandonné non pas à cause de la réputation, mais parce qu’il est impossible d’échapper à l’exigence de disponibilité à 100 %, avec le risque de perdre des mails ou de finir sur liste noire. En théorie, le protocole e-mail est censé bien tolérer les pannes, mais en pratique les grands fournisseurs rejettent souvent immédiatement après un seul problème et ne réessayent pas. GitHub, autrefois, marquait même une adresse comme « impossible à joindre » après un seul bounce et n’envoyait plus rien ensuite. Ça s’est amélioré depuis, mais les systèmes e-mail modernes partent du principe qu’on est « toujours en ligne »

  • Mon serveur mail utilise volontairement une fonction de greylisting qui rejette le premier message reçu. J’ai reçu énormément de mails et je n’ai jamais vu un seul message légitime perdu à cause de ça. La retransmission est prévue par les standards de l’e-mail ; si ça vous inquiète, vous pouvez ajouter un serveur de réception de secours et faire un backhaul en LMTP. Le système e-mail lui-même a été conçu à une époque où les machines n’étaient pas connectées 24 h/24

  • C’est exagéré. Dans mon cas, quand un mail n’arrive pas, il finit par réapparaître quelques heures ou un jour plus tard, et il n’y a généralement aucun moyen de savoir où le problème s’est produit. Si l’authentification est correctement configurée — par exemple dkim, spf — l’auto-hébergement permet d’obtenir une délivrabilité supérieure à 99 %. Pas besoin d’avoir peur de la complexité. Et au passage, on peut aussi utiliser caldav en privé

  • Je me demande pourquoi on parle de « perte de mails » si le serveur est indisponible pendant quelques heures. Le mien tourne depuis 219 jours sans interruption. Comparé à ce qu’on fait habituellement, gérer un serveur mail est vraiment facile

  • Quand on regarde les systèmes e-mail d’aujourd’hui, on a vraiment envie de dire : « qu’est-ce qu’ils ont fait à mon fils ? »

• Mon conseil à ceux qui veulent se lancer dans l’auto-hébergement de leur messagerie : commencez par utiliser votre adresse auto-hébergée uniquement pour vous inscrire à des comptes. Pas besoin de s’en servir dès le départ pour les échanges personnels. Avec “Mail-in-a-box” https://mailinabox.email./, il suffit de suivre le guide d’installation pour mettre en place quelque chose de fonctionnel en quelques heures. Utilisez-le un ou deux ans, et quand vous serez vraiment à l’aise, vous pourrez alors migrer vos échanges personnels dessus

  • Je recommande Stalwart https://github.com/stalwartlabs/stalwart. C’est un service mail complet dans un seul binaire, sans dépendances, donc l’installation et les mises à jour sont très simples. J’ai essayé beaucoup d’autres projets, mais Stalwart a été de loin le plus facile, et il tourne sans le moindre problème

  • J’exploite MIAB dans le cloud depuis plusieurs années. Tant que la réputation de l’IP est propre, l’envoi ne pose pas de problème ; mais quand les mails n’arrivent pas chez Outlook, je contacte directement le postmaster de Microsoft pour régler la situation. C’est instructif, notamment pour apprendre à configurer DKIM/SPF/DMARC, donc je le recommande pour l’apprentissage. En revanche, recevoir les e-mails d’inscription est vraiment difficile. Le greylisting de MIAB rejette les nouveaux expéditeurs et attend une nouvelle tentative, mais beaucoup de sites pourtant légitimes ne réessayent même pas. Les mails d’authentification ou les codes de 2FA finissent par arriver avec beaucoup de retard, et il n’y a pas de moyen simple de désactiver temporairement le filtre anti-spam

• De nos jours, même les adresses mail fournies par les ISP, et même Google Gmail, rencontrent parfois des problèmes de filtrage anti-spam. Par exemple, quand on passe une commande via Shopify, les mails de Shopify sont systématiquement classés comme spam dans Gmail. Pourtant, DMARC, SPF et DKIM passent tous correctement. L’envoi et la réception d’e-mails ne sont pas techniquement si difficiles, et quel que soit le service utilisé, rien n’est parfait à 100 %. Vu le nombre d’acteurs malveillants — les spammeurs — c’est presque étonnant que le système fonctionne aussi bien

  • DMARC, SPF, DKIM et consorts ne sont que des paramètres d’authentification ; ils n’ont pas de lien direct avec le fait qu’un message soit du spam ou non. On trouve des mails pourris parfaitement authentifiés, comme des mails précieux non authentifiés

  • Si les mails Shopify finissent en spam, c’est parce que beaucoup de gens les signalent comme indésirables, ou parce que Shopify partage des serveurs mail avec des utilisateurs à mauvaise réputation. Même si je continue à les marquer comme non-spam, si la réputation globale de l’expéditeur est trop mauvaise, ils ne sortiront jamais du dossier spam

  • J’auto-héberge mon e-mail depuis environ 20 ans. Pendant 10 à 15 ans, je transférais tous mes messages vers Gmail, mais j’en ai eu assez des filtres anti-spam qui faisaient disparaître même des mails importants, et j’ai fini par faire tourner mon propre imapd. À condition de bien configurer SPF et le reste, je trouve l’auto-hébergement bien meilleur

  • Ce sont précisément ces politiques de filtrage qui posent problème. Quand on auto-héberge ou qu’on utilise un petit service mail, on risque beaucoup moins de voir ses messages bloqués, surtout par les filtres stricts de Gmail et consorts. Google héberge pourtant énormément d’utilisateurs Gmail qui sont une source majeure de spam, tout en maintenant des politiques de filtrage agressives

  • En ce moment, le filtre anti-spam de Gmail réagit beaucoup trop agressivement aux mails marketing. Il y a 10 ans, c’était plutôt l’inverse, mais aujourd’hui trop de messages finissent dans le dossier spam, au point d’en devenir pénible. Une bonne partie du spam actuel vient plutôt de cold mails envoyés depuis de petites adresses récentes. La fonction « se désabonner » de Gmail marche bien pour les e-mails marketing, mais elle ne sert à rien contre ce type de messages

• Si vous voulez une installation complète avec un serveur IMAP capable de s’intégrer à divers clients, le guide https://workaround.org/ispmail-bookworm/ est plus adapté. De mon côté, j’utilise une configuration simple avec des fichiers texte au lieu d’une base de données. Si vous êtes le seul utilisateur, ça fonctionne très bien, et le guide peut aussi monter en charge jusqu’à un usage en grande entreprise

  • J’utilise aussi ce guide, mais en remplaçant la base de données par PostgreSQL. Après une récente mise à niveau vers Trixie, la configuration de Dovecot a beaucoup changé et ça m’a donné du fil à retordre, mais maintenant tout fonctionne parfaitement

• Petit autopromo : nous testons en bêta Hyvor Relay https://github.com/hyvor/relay, une alternative auto-hébergée. Nous mettons l’accent sur la visibilité avec la supervision DKIM/SPF et l’automatisation DNS. Un simple docker compose up suffit pour le mettre en service https://relay.hyvor.com/hosting/deploy-easy

• Depuis 10 à 15 ans, j’auto-héberge mon e-mail sur un petit serveur kimsufi avec opensmtp, dovecot et rspamd. Je n’ai pas eu de problème particulier ; une seule fois, mon serveur a été bloqué par telekom.de, mais après une explication formelle par e-mail, ils l’ont immédiatement mis en liste blanche. Peut-être parce que je possède cette IP depuis longtemps, mais personnellement je n’ai pas rencontré tous les soucis dont parlent les autres. Cela dit, le serveur et l’IP sont bien à mon nom

• Je partage à https://krei.se/Doc un article en allemand sur l’auto-hébergement mail basé sur Debian trixie. Quand on le met correctement en place soi-même, c’est vraiment très satisfaisant. J’ai configuré les mises à jour automatiques et les redémarrages, ainsi que des unités systemd personnalisées qui m’envoient chaque jour un rapport d’état par e-mail. Ensuite, plus besoin d’y toucher pendant 2 à 3 ans — jusqu’à 5 ans avec trixie. Les logiciels de serveur mail sont déjà suffisamment matures. Je recommande l’auto-hébergement. L’autonomie, la tranquillité et le contrôle direct ont une vraie valeur

• J’administre mon propre e-mail depuis plus de 10 ans et j’ai déjà laissé des commentaires HN à ce sujet avec des liens à l’appui (par ex. 39891262, 38471262). Comme les IP de Digital Ocean étaient cataloguées comme malveillantes, j’ai délégué l’envoi à Amazon SES, et j’utilise Gmail comme outil gratuit d’entraînement anti-spam pour mon propre filtrage (38843288). Comme beaucoup l’ont signalé, le greylisting aide énormément. Un serveur mail légitime réessaiera toujours, donc même si c’est gênant pour la 2FA, c’est fiable d’un point de vue système. Même plusieurs jours d’indisponibilité ne sont pas forcément problématiques, et séparer les serveurs de réception et de stockage facilite aussi les sauvegardes (38512732). Pour les mails de 2FA, j’utilise aussi https://github.com/stevejenkins/postwhite, mais en réalité je ne recommanderais pas l’e-mail pour la 2FA — c’est un autre débat

  • Récemment, je n’ai pas reçu un e-mail important envoyé via Amazon SES à cause d’une liste de blocage anti-spam (bl.spamcop.net). Amazon a réessayé depuis plusieurs IP, a fini par tomber sur le greylisting, et l’une des tentatives a finalement été rejetée. Entre gros acteurs, en envoi MX vers MX, ça pose peut-être moins de problèmes, mais ce genre d’architecture n’est pas non plus une solution parfaite à 100 %

  • Au fond, à vous lire, on a l’impression que la conclusion est simplement qu’il vaut mieux utiliser Gmail ou un autre grand service mail

• Où est UUCP, pourquoi l’adresse n’est-elle pas en bang path, et qu’est devenu sendmail.cf ?

  • Exactement. Si on veut vraiment faire de l’auto-hébergement « à la 1984 » — de l’e-mail à l’ancienne — on finit avec un open relay qui transmet tout et une surface d’attaque pleine de vulnérabilités

  • En parlant de cette époque, je me souviens du laboratoire informatique de l’université, avec ses six stations de travail Unix, où l’on entendait physiquement les disques travailler quand les e-mails passaient d’un serveur à l’autre

  • Moi aussi, en voyant le titre, j’ai tout de suite pensé aux bang paths et aux adresses du type « killer!jolet! ». Quelle époque regrettée

  • Pareil. Je suis entré à cause du titre « 1984 », et j’ai été déçu de tomber finalement sur une discussion sur la configuration de postfix