L’auto-hébergement de l’e-mail à la dure, en partant d’un bloc IPv4 routable en propre

• L’infrastructure mail de Recoil, exploitée depuis 1997, a été modernisée en une pile auto-hébergée qui gère directement la réception, l’envoi et l’accès en combinant un bloc IPv4 dédié /24, Postfix, Dovecot, rspamd, Roundcube, etc.
• Exploiter son propre service mail offre le contrôle d’accès aux données et une vraie valeur d’apprentissage, mais sur un SMTP fondé sur une confiance faible, il faut gérer soi-même la réputation IP, les enregistrements DNS et la défense anti-spam.
• Le chemin de réception passe par postscreen, DNSBL, le greylisting, ClamAV, le filtrage bayésien, LMTP et Sieve, dans une architecture qui réduit progressivement le trafic de bots et les mails malveillants.
• La fiabilité en émission dépend de SPF, DKIM, DMARC et SRS ; une mauvaise configuration peut faire classer les messages comme spam, voire les faire rejeter silencieusement, chez des destinataires comme Gmail ou Outlook.
• En 2026, l’auto-hébergement de l’e-mail reste possible, mais il exige une plage IPv4, plusieurs enregistrements DNS, des mises à jour de sécurité et une défense en profondeur face aux exploitations de vulnérabilités appuyées par l’IA.

---

Pourquoi exploiter son propre e-mail

• Faire tourner son propre serveur est une expérience formatrice pour apprendre les systèmes et les réseaux, ainsi qu’un moyen de comprendre le fonctionnement d’Internet et de participer à l’open source.
• Alors que le web se concentre autour d’un petit nombre d’acteurs, l’auto-hébergement est une façon de conserver un accès souverain à ses propres données.
• Une analyse de 2023 estimait que les acteurs capables de lire le trafic e-mail se résument en pratique surtout à Google et Microsoft.
• L’e-mail est lié à la réinitialisation de mot de passe de nombreux comptes en ligne ; une compromission de compte ou du phishing peut donc aussi mettre en péril l’accès à d’autres services.
• Exploiter son propre mail demande une maintenance au long cours, ainsi qu’un hébergement Internet plus stable qu’un réseau domestique et le temps de construire une réputation.

Architecture de réception des e-mails

• Un domaine Internet désigne le serveur SMTP qui reçoit les messages via des enregistrements DNS MX ; pour recoil.org, c’est pork.recoil.org qui traite le courrier.
• SMTP vient d’une conception des années 1980 fondée sur davantage de confiance et ne permet pas, par défaut, de prouver l’identité de l’expéditeur ; l’auteur apparent d’un message entrant est donc facile à usurper.
• La réponse de l’IETF a consisté à empiler plusieurs contrôles d’identité, mais si ces vérifications sont mal configurées, la fiabilité de la livraison baisse.
• Les listes de blocage fondées sur le DNS agrègent des informations sur les botnets, les hôtes compromis et les spammeurs ; un serveur mail peut interroger des RBL pour filtrer les IP suspectes.
• La réputation e-mail s’accumule sur l’adresse IP plutôt que sur le domaine ; dans le cloud, une adresse réutilisée ou des IP voisines du même bloc peuvent donc influer sur cette réputation.

• Obtenir et router un bloc IPv4 dédié

  • Recoil a obtenu son propre bloc d’adresses IPv4 185.33.27.0/24, ce qui lui permet de construire sa réputation mail indépendamment.
  • Le RIPE NCC a épuisé son espace IPv4 non alloué en novembre 2019 ; depuis, les attributions directes passent par une liste d’attente pour de petits blocs /24.
  • Le bloc /24 a été attribué après environ six mois d’attente ; pour faire une demande directe en Europe, il faut payer l’adhésion au RIPE NCC et ouvrir un compte LIR.
  • Une fois le bloc IPv4 attribué, un ROA RPKI permet de définir l’autorisation de routage, et le bloc de Recoil est annoncé via Mythic Beasts AS44684.
  • Le reverse DNS peut aussi être contrôlé directement ; 185.33.27.128 pointe vers pork.recoil.org, ce qui sert également de signal de réputation mail.

Défense contre les bots et le spam

• Obtenir un bloc IPv4 propre ne suffit pas : la majorité des connexions TCP entrantes sur le port 25 servent à relayer du spam, chercher des open relays, deviner des identifiants ou collecter des données d’entraînement pour l’IA.
• Le postscreen de Postfix effectue en amont du port 25 des requêtes DNSBL en parallèle, un délai pre-greet, ainsi que des vérifications de pipelining et de commandes non SMTP.
• postscreen ne transmet au vrai smtpd que les clients qui paraissent légitimes ; les clients incorrects reçoivent un échec temporaire, ce qui leur permet de réessayer en cas de faux positif.
• Les listes Spamhaus, Spamcop et Barracuda sont combinées avec pondération ; la configuration rejette un message si Spamhaus le signale à lui seul, ou si deux listes plus faibles convergent.
• Le pool MX expéditeur d’Apple iCloud ne réessaie pas depuis la même IP, ce qui s’accorde mal avec la liste d’autorisation de postscreen ; la solution a donc été de laisser passer en priorité l’ensemble de 17.0.0.0/8.

• Greylisting et inspection du contenu

  • Le greylisting renvoie un échec temporaire à une source inconnue lors du premier envoi ; si un MTA légitime réessaie quelques minutes plus tard, le message passe.
  • Les botnets à usage unique passent souvent à la cible suivante après un échec, ce qui les distingue des expéditeurs légitimes qui maintiennent une file de réessai.
  • Une fois postscreen et le greylisting franchis, plus de 99 % du trafic de bots d’origine est bloqué avec un coût CPU faible.
  • rspamd inspecte tous les messages via le protocole milter ; les messages suspects ne sont pas acceptés puis renvoyés, mais refusés ou retardés tant que le serveur expéditeur est encore connecté.
  • ClamAV analyse les pièces jointes contenant des virus connus et rejette immédiatement les messages infectés ; le classificateur bayésien de rspamd attribue un score aux messages à partir d’un corpus spam/ham stocké dans Redis.

Livraison locale, stockage et filtrage

• Les messages reçus sont remis à Dovecot après être passés par postscreen, le greylisting, rspamd, ClamAV et le classificateur bayésien.
• Au lieu de faire écrire Postfix directement dans les répertoires personnels, les messages sont envoyés à Dovecot via LMTP, qui prend en charge l’indexation, les quotas, la recherche plein texte et le filtrage Sieve.
• virtual_alias_maps convertit des adresses comme [e-mail] en adresses distribuables localement.
• Le format de stockage est Maildir, utilisé depuis 1998, qui enregistre chaque e-mail comme un fichier unique sous ~/Maildir.
• Maildir utilise trois sous-répertoires, tmp/, new/ et cur/, ainsi que le renommage atomique POSIX, afin de livrer de nouveaux messages sans verrou global sur toute la boîte aux lettres.

• Index de recherche et Sieve

  • Des serveurs mail plus modernes comme Stalwart ont aussi été évalués, mais ils ne prennent pas en charge Maildir et imposent un stockage dans une base spécifique comme RocksDB, ce qui a écarté une migration.
  • Dovecot sépare le stockage Maildir des performances de recherche grâce à Flatcurve, un index plein texte distinct.
  • Flatcurve est un wrapper de Xapian ; il place un index Xapian par boîte aux lettres sous ~/Maildir/fts-flatcurve et le met à jour automatiquement à l’arrivée de nouveaux messages.
  • Sieve est un langage déclaratif dédié au filtrage des e-mails, et le plugin Pigeonhole Sieve de Dovecot exécute les filtres utilisateur au moment de la distribution.
  • Un script Sieve global déplace dans Junk les messages marqués par rspamd, tandis que les scripts par utilisateur gèrent le classement dans des dossiers, les règles d’absence, la priorité ou encore la modification des en-têtes.

Envoyer des e-mails de manière fiable

• Pour envoyer des messages de façon fiable, l’authentification en émission est aussi importante que la défense en réception ; si une seule vérification échoue chez un grand destinataire, le message peut finir dans les spams ou être rejeté silencieusement.
• SPF est un enregistrement DNS TXT au sommet du domaine qui déclare quelles adresses IP sont autorisées à revendiquer l’envoi depuis @recoil.org.
• Le SPF de Recoil est v=spf1 a mx -all, ce qui signifie que seul pork.recoil.org, vers lequel pointent les MX de recoil.org, est considéré comme expéditeur valide.
• Sur un hôte disposant de plusieurs IP, Postfix est lié à des adresses d’émission précises via smtp_bind_address et smtp_bind_address6, afin d’empêcher le noyau d’en choisir une arbitrairement.
• DKIM ajoute une signature cryptographique sur une forme canonisée du corps du message et de certains en-têtes ; la clé publique de vérification est publiée dans le DNS sous <selector>._domainkey.<domain>.

• DMARC et SRS

  • DMARC vérifie que le domaine authentifié par SPF et DKIM correspond bien à l’en-tête From: vu par l’utilisateur, et indique au destinataire quoi faire en cas d’échec.
  • La politique DMARC de Recoil est p=quarantine, avec réception de rapports agrégés via une adresse rua= pour déboguer les problèmes de délivrabilité.
  • Les grands destinataires envoient en général une fois par jour un rapport XML récapitulatif des messages qui revendiquaient provenir de recoil.org, notamment Google, Microsoft, Yahoo et Fastmail.
  • Un message transféré peut sembler provenir du domaine d’origine tout en étant envoyé depuis une IP de Recoil, ce qui peut faire échouer SPF.
  • SRS réécrit alors l’adresse d’enveloppe expéditrice sous une forme comme SRS0=…=example.com=[e-mail], afin que la vérification SPF du destinataire s’évalue sur le domaine de Recoil.

Accès utilisateur et webmail

• Les utilisateurs accèdent à leurs messages soit via un client IMAP classique connecté au serveur Dovecot, soit via un webmail auto-hébergé ouvert dans le navigateur.
• Dovecot gère l’accès aux boîtes aux lettres sur pork et chiffre ses points d’écoute avec TLS, afin que ni les e-mails ni les mots de passe en clair ne transitent sur les réseaux publics.
• Les certificats proviennent de LetsEncrypt, et plusieurs alias d’hôte comme imap.recoil.org ou smtp.recoil.org sont servis via SNI.
• Dovecot sert aussi de backend SASL pour Postfix, ce qui permet aux utilisateurs d’employer le même mot de passe pour l’accès IMAP et l’envoi SMTP.
• Roundcube s’exécute comme service Docker Compose derrière un reverse proxy TLS Caddy et se connecte à pork en TLS/IMAP comme n’importe quel autre client.

• Plugins Roundcube

  • Le plugin managesieve de Roundcube utilise le protocole ManageSieve pour permettre l’édition des filtres Sieve depuis le navigateur.
  • Le plugin markasjunk transforme le bouton « Junk » du webmail en déplacement vers le dossier Junk, ce qui permet de déclencher l’apprentissage ham/spam sans exposition visible pour l’utilisateur.
  • L’interface ManageSieve de Roundcube n’expose pas directement le DSL Sieve brut.

Travail restant et sens de l’auto-hébergement

• La configuration actuelle s’est montrée assez robuste au quotidien ces dernières semaines, mais il reste du travail à faire.
• recoil.org combine des enregistrements DNS MX, A/AAAA, PTR, SPF TXT, DKIM TXT et DMARC TXT pour assurer la réception, l’envoi et la vérification des e-mails.
• MTA-STS indique aux autres serveurs mail de ne communiquer qu’en TLS avec un certificat valide, ce qui atténue les attaques de downgrade STARTTLS.
• DANE/TLSA utilise des empreintes de certificats TLS ancrées dans le DNS plutôt que dans HTTPS, mais exige une zone DNS signée avec DNSSEC et n’est pas encore déployé.
• SRS a été partiellement déployé, mais n’est pas encore validé sur tous les chemins de transfert ; les échecs liés à INRIA inquiètent en raison de possibles échecs DMARC et d’un impact sur la réputation du domaine.

• JMAP, sécurité et avenir de l’auto-hébergement

  • JMAP est un protocole d’accès au courrier fondé sur HTTPS et JSON, mieux adapté que l’IMAP aux clients modernes et aux réseaux actuels.
  • Dovecot ne prend pas nativement en charge JMAP, et les serveurs JMAP indépendants évalués imposaient d’abandonner Maildir au profit de leur propre stockage de boîtes aux lettres.
  • Une piste envisagée consiste à placer devant Dovecot une implémentation JMAP en OCaml faisant office de proxy de traduction, qui mapperait les requêtes JMAP vers des appels IMAP avant de renvoyer des réponses JSON.
  • En 2026, exploiter un serveur mail impose de configurer correctement au moins six enregistrements DNS, et l’obtention d’un bloc IPv4 via le RIPE prend presque un an.
  • Le délai entre la publication d’une CVE et l’arrivée de véritables exploits contre les écouteurs SMTP/IMAP pourrait désormais se mesurer en heures plutôt qu’en semaines ; il faut donc une défense en profondeur avec adresses fixées explicitement, isolation du conteneur webmail, greylisting et DNSBL.

[GN⁺]

Avis sur Lobste.rs

• J’observe sans cesse des gardiens du temple affirmer qu’il est impossible de faire quelque chose que l’on fait pourtant depuis des décennies
  En réalité, je continue de dire qu’il suffit de configurer le reverse DNS, SPF, DMARC et MTA-STS, que cela ne coûte pas très cher et que ce n’est pas si difficile
  Exemple de serveur mail : https://poofydoof.zia.io/

  • J’administre moi-même du mail auto-hébergé depuis vers 2008, et je suis toujours surpris de voir autant de gens dire que c’est impossible
    Aujourd’hui, j’utilise Debian + Postfix, Dovecot et rspamd, et j’ai plus souvent des problèmes avec Google Workspace au travail qu’avec ma propre configuration
  • À mon avis, le point clé est la partie « quelque chose que l’on fait depuis des décennies »
    Dire qu’il suffit de configurer le reverse DNS, SPF, DMARC et MTA-STS est exact à 100 % pour des domaines et adresses IP qui ont déjà une bonne réputation
    Si l’on ajoute un nouveau domaine à un serveur mail déjà jugé fiable par les grands fournisseurs, la réputation se construit vite, et si l’on déplace un domaine existant vers une nouvelle IP de serveur mail avec DKIM configuré, ça passe aussi
    En revanche, si l’on démarre de zéro avec un nouveau domaine et une nouvelle IP de serveur mail, j’ai entendu dire que la situation est très différente, et qu’il y a de fortes chances d’être automatiquement classé comme spam jusqu’à ce que les systèmes de machine learning des grands fournisseurs soient satisfaits
    Le comportement qui semble souvent fonctionner, c’est que des utilisateurs de ces systèmes envoient des mails à mon domaine puis récupèrent la réponse dans leur dossier spam
  • Après environ 3 ans à faire tourner un serveur mail, la difficulté n’est pas de configurer DNS, SPF, DMARC ou MTA-STS, mais d’éviter de se faire frapper par les blocklists lors de l’envoi de mails transactionnels, ainsi que l’impossibilité de se faire inscrire sur liste blanche chez certains fournisseurs d’email
    Plutôt que de passer son temps à courir après ce genre de problèmes, je pense qu’il vaut mieux payer environ 5 dollars par mois et confier ça à quelqu’un
  • L’exemple de serveur mail est sympa, et ceci l’est aussi
    https://dmesgd.nycbug.org/dmesgd?do=view&id=8929
    J’aimerais bien en savoir plus sur les détails de cette configuration
    Le Mango Pi MQ-Pro a l’air difficile à trouver, et je me demande s’il existe d’autres appareils ultra-économiques avec un bon support NetBSD/Linux

• Une autre raison d’exploiter son propre serveur mail, c’est qu’on peut découvrir que quelqu’un envoie déjà du spam avec son domaine
  Quand l’un de mes domaines a été transféré vers Squarespace à cause de la vente de Google Domains, Squarespace a automatiquement ajouté des enregistrements DNS MX/SPF/DKIM pour Mailgun alors que je n’avais pas de compte Mailgun
  Quelqu’un a récupéré ce compte chez Mailgun et m’a envoyé du spam en le faisant passer pour un envoi depuis mon domaine
  Merci, Google

• La partie sur l’allocation IPv4 est particulièrement intéressante
  Il est indiqué que pour le faire soi-même en Europe, il faut payer la cotisation annuelle du RIPE NCC et ouvrir un compte de registre Internet local (LIR), ce qui, d’après https://www.ripe.net/membership/payment/ , revient à 1800 euros par an
  C’est assez rude, mais si c’était moins cher, les spammeurs en abuseraient probablement plus facilement

  • Ce n’est pas donné, mais cela revient à environ 12 livres par an par adresse, donc si on partage cela pour des services locaux entre amis et famille, ce n’est pas si mal
    Le plaisir d’écrire un serveur BGP en OCaml n’a pas de prix :-)

• Je me demande s’il est réaliste d’utiliser IPv6 pour l’envoi et la réception d’emails

  • Bonne question
    J’ai regardé cela au moment d’écrire l’article, mais comme IPv6 est désactivé sur mon serveur mail depuis quelques années, j’ai décidé d’attendre d’avoir plus d’expérience
    D’après https://dn.org/ipv6-and-domain-reputation-in-anti-spam-filters , des fournisseurs d’email comme Gmail, Microsoft et Yahoo utilisent des filtres anti-spam propriétaires qui pondèrent différemment la réputation du domaine et celle de l’IP, et la prise en charge d’IPv6 continue aussi de mûrir
    Gmail exige pour les mails en IPv6 un enregistrement PTR valide, SPF, DKIM, et recommande fortement l’usage de DMARC
    Sans ces éléments, les mails envoyés en IPv6 finissent souvent dans le dossier spam ou subissent des retards
    Le système de filtrage de Microsoft inclut IPv6 dans ses programmes SNDS et JMRP, mais peut limiter ou retarder les mails IPv6 si la réputation de l’expéditeur n’est pas connue
    En fin de compte, IPv6 est un point de défaillance supplémentaire, et configurer au départ un domaine d’envoi mixte IPv4/IPv6 n’est probablement pas une bonne idée
    Je n’ai pas encore trouvé de point de terminaison SMTP IPv6-only