Kanyro : site vitrine et messagerie auto-hébergée

Objectifs

• Diffuser un site statique en HTTPS depuis un serveur administré personnellement.
• Recevoir et émettre du courrier depuis une adresse du domaine, aujourd'hui bonjour@kanyro.fr.
• Faire accepter les messages sortants par les grands fournisseurs (SPF, DKIM, DMARC, reverse DNS).
• Garantir que le contenu reste lisible sans JavaScript et sans dépendance à un domaine tiers.
• Changer le domaine de production sans perdre une demande de devis ni casser un lien déjà publié.
• Encadrer les données personnelles collectées par le formulaire : finalité, base légale, durée de conservation réellement appliquée et exercice des droits.

Architecture

Le VPS héberge deux services distincts sur la même machine. Caddy sert le site statique en HTTPS sur les ports 80/443, obtient les certificats Let's Encrypt et redirige l'ancien domaine vers le nouveau. À côté, la chaîne de messagerie : un message entrant suit le trajet Internet → Postfix (port 25) → OpenDKIM (vérification) → LMTP → Dovecot → Maildir de la boîte bonjour@kanyro.fr ; un message sortant suit Postfix → OpenDKIM (signature) → Internet. Dovecot expose la boîte en IMAP (143) et IMAPS (993), Postfix accepte l'envoi authentifié sur les ports 465 et 587. Les deux domaines sont des domaines virtuels de Postfix et signent chacun avec sa propre clé DKIM. Un script déclenché par cron recopie les certificats obtenus par Caddy vers Postfix et Dovecot, qui présentent à chaque client le certificat du nom qu'il a demandé, par SNI.

Étapes de réalisation

Configurations

• OpenDKIM : identité du processus et fichier PID

  Le démon redémarrait en boucle avec le message « key data is not secure » : il s'exécutait sous root alors que les clés appartiennent à l'utilisateur opendkim. La correction tient en trois directives : UserID opendkim dans /etc/opendkim.conf (le paramètre s'appelle UserID et non User, ce qui est une source d'erreur classique), une directive PidFile, et un drop-in systemd déclarant RuntimeDirectory pour que le répertoire du socket existe au démarrage.

• Postfix : transport LMTP vers Dovecot

  Postfix ne délivre pas lui-même dans les boîtes : il passe le message à Dovecot par LMTP, qui écrit dans le Maildir. Les deux domaines sont déclarés en domaines virtuels et la liste des boîtes tenue dans /etc/postfix/vmailbox.

• Deux domaines sur le même serveur, deux clés DKIM et un renvoi

  Depuis la bascule, kanyro.fr et kanyro.tech sont tous deux des domaines virtuels de Postfix. Chacun a sa propre paire de clés dans /etc/opendkim/keys, déclarée dans le KeyTable et le SigningTable : une clé unique aurait obligé les deux zones à publier le même enregistrement, et un domaine ne signe correctement qu'avec une clé publiée sous son propre nom. contact@kanyro.tech n'est plus une boîte mais un renvoi posé dans /etc/postfix/virtual vers bonjour@kanyro.fr ; le Maildir d'origine est conservé, les messages reçus avant la bascule restent consultables.

• Un certificat par nom, présenté par SNI

  Caddy délivre un certificat par nom : celui de mail.kanyro.fr ne couvre pas mail.kanyro.tech. Comme les appareils configurés avant la bascule continuent de se connecter à l'ancien nom, le serveur doit présenter à chacun le certificat qu'il attend. C'est le rôle de l'extension SNI, gérée par Postfix (tls_server_sni_maps) et par Dovecot (local_name) : le client annonce le nom demandé pendant la poignée de main, le serveur répond avec le certificat correspondant. Sans elle, il aurait fallu choisir lequel des deux noms afficherait une alerte de sécurité à chaque relève de courrier.

• Partage du certificat TLS entre trois services

  Caddy renouvelle seul les certificats Let's Encrypt, mais Postfix et Dovecot lisent les leurs dans un autre répertoire et sous un autre utilisateur. Un script recopie les certificats vers /etc/mail-certs et alimente les tables SNI ; il lit le nom du serveur dans la configuration de Postfix au lieu de le connaître en dur, si bien qu'ajouter un nom au Caddyfile suffit. Il est déclenché toutes les quinze minutes par cron. Sans lui, les clients de messagerie afficheraient un avertissement de sécurité au premier renouvellement.

• En-têtes de sécurité et politique de sécurité de contenu

  La configuration de Caddy est versionnée dans le dépôt et validée avant rechargement. Elle pose HSTS pour un an, sans preload ni includeSubDomains pour ne pas couper un futur sous-domaine servi en HTTP, une politique de sécurité de contenu identique à celle de la balise meta du site mais portant en plus frame-ancestors et upgrade-insecure-requests, une Permissions-Policy qui refuse huit API du navigateur, et retire la signature du serveur. La page 404 reçoit les mêmes en-têtes que les autres, ce qui n'était pas le cas au départ.

• Traitement des données personnelles et durée réellement appliquée

  Le formulaire de contact est le premier traitement de données à caractère personnel du site : il collecte un nom, une entreprise, une adresse électronique, un téléphone et un message. La politique de confidentialité recense six traitements, chacun avec sa base légale, sa durée et les personnes qui y ont accès ; celui du formulaire relève des mesures précontractuelles prises à la demande de la personne, article 6.1.b du RGPD. Le site ne dépose aucun cookie et n'utilise aucun outil de mesure d'audience tiers. La durée de conservation de trois ans est appliquée par un service de purge déclenché par un timer systemd, qui supprime les messages au-delà du délai dans les deux boîtes, brouillons, envoyés, corbeilles et indésirables compris : une durée annoncée que rien n'applique est exactement ce qu'un contrôle relève en premier.

Procédures

• Politique anti-abus du formulaire de devis

  Le formulaire renvoie un accusé de réception au visiteur, ce qui en fait une arme si on ne le borde pas : il suffit de soumettre l'adresse d'un tiers en boucle pour la noyer, et c'est le domaine expéditeur qui finit sur les listes noires. L'envoi est donc limité à cinq soumissions par heure et par adresse IP, l'accusé de réception est générique et le compteur est salé par un secret qui ne vit pas dans le dépôt. En cas d'échec, le visiteur est renvoyé sur une URL portant le motif (saisie, limite ou envoi), et le message correspondant est affiché avec restitution de ce qu'il avait tapé.

• Ordre d'une bascule de nom de domaine

  La bascule suit un ordre qui ne se prend pas à l'envers. Le DNS d'abord : tant que le nouveau nom ne pointe pas sur le serveur, Caddy ne peut pas obtenir son certificat. Le site ensuite, adresses canoniques, plan de site, données structurées et pages légales basculant ensemble, l'ancien domaine se mettant à rediriger au même moment. Le courrier en dernier, et jamais en même temps que le reste : une migration de messagerie ratée, ce sont des demandes de devis perdues sans que personne ne s'en aperçoive. L'ancienne adresse reste en renvoi.

• Reverse DNS et nom annoncé, dans cet ordre

  Le reverse DNS de l'adresse IP se change chez l'hébergeur, pas dans la zone du domaine : il reste donc à faire après la bascule. Tant qu'il n'a pas changé, le nom annoncé par Postfix ne doit pas changer non plus. Gmail et Outlook comparent trois choses : le nom annoncé à la connexion, le reverse DNS de l'adresse, et le domaine de l'expéditeur. Annoncer le nouveau nom avec un reverse qui désigne encore l'ancien casserait l'accord entre les deux premiers pour préparer celui du troisième : on y perd plus qu'on n'y gagne.

• Protection du domaine de production pendant la phase de test

  Pendant la période où le site tournait sur un sous-domaine de test, un unique objet de configuration basculait ensemble l'URL canonique, les balises og:url, le sitemap, le noindex de toutes les pages et le contenu du robots.txt. Si le moteur de recherche avait indexé la version de test, c'est elle qui serait ressortie dans les résultats, et le domaine définitif aurait publié un contenu déjà connu ailleurs. C'est le même objet qui a porté la bascule vers kanyro.fr.

Environnement

• VPS Hostinger sous Linux, administré en SSH
• Deux noms de domaine : kanyro.fr chez OVH, domaine de production, et kanyro.tech chez Hostinger, redirigé
• Astro 7 en sortie statique, Tailwind 4, Node 22+
• Postfix, Dovecot et OpenDKIM pour la messagerie, en domaines virtuels
• Caddy pour la diffusion HTTPS et les certificats Let's Encrypt
• PHP-FPM 8.3 pour le formulaire de demande de devis

Technologies

• Linux
• DNS
• Caddy
• Postfix
• Dovecot
• OpenDKIM
• Git

Tests réalisés

• Chaîne de messagerie de bout en bout

  Envoi d'un message vers la boîte puis vérification de son arrivée dans le Maildir ; lecture des en-têtes du message pour vérifier la présence de la signature DKIM ; connexion IMAP avec STARTTLS et lecture de la boîte de réception depuis un client de messagerie. Vérification de la publication de la clé DKIM avec opendkim-testkey, qui doit répondre « record found » pour chacun des deux domaines.

• Écoute effective des ports de service

  Le port 587 était déclaré dans master.cf mais n'apparaissait pas dans les ports en écoute. Le contrôle a consisté à lister les sockets ouverts sur la machine plutôt qu'à se fier au fichier de configuration : un service configuré et un service en écoute sont deux choses différentes.

• Audit de la zone DNS depuis l'extérieur

  Interrogation de chaque enregistrement de messagerie depuis trois résolveurs publics indépendants, plutôt que depuis le serveur lui-même : un serveur se croit toujours joignable. Vérification de la concordance entre clé privée locale et clé publiée avec opendkim-testkey, et lecture du certificat réellement présenté par Postfix et Dovecot avec openssl. C'est cet audit qui a révélé l'absence d'enregistrement MX, puis la couverture IPv6 incomplète du SPF.

• Validation de bout en bout par un opérateur tiers

  Un serveur qui se déclare conforme ne prouve rien : le seul juge utile est le destinataire. Envoi d'un message depuis la boîte du domaine vers une boîte Gmail, puis relecture des en-têtes ajoutés par Google via « Afficher l'original ». Les trois mécanismes sont constatés en réussite, et l'en-tête Received montre que le message est parti en IPv6, soit exactement le cas qui échouait avant l'ajout de l'enregistrement AAAA.

• Contrôle de la bascule depuis l'extérieur

  Le jour de la bascule, le même protocole a été rejoué depuis une autre machine que le serveur : en-têtes HTTP de kanyro.fr et code de redirection de kanyro.tech, enregistrements MX, SPF, DKIM et DMARC de la nouvelle zone interrogés sur trois résolveurs publics, et certificat présenté sur le port 993 pour chacun des deux noms de serveur, chaque connexion annonçant le nom qu'elle demande. Les deux répondent « does match certificate », ce qui vérifie la configuration SNI autrement qu'en relisant le fichier.

• Répétition de la purge avant de l'armer

  Un service qui supprime des messages se regarde tourner à vide avant d'être laissé seul. La commande de recherche de Dovecot liste les messages qui seraient supprimés sans rien toucher : elle a été passée sur chaque dossier des deux boîtes, avant d'armer le timer, puis le service a été déclenché à la main et ses journaux relus.

• Recette du site sur le build de production

  Contrôles passés sur le site généré, politique de sécurité de contenu active : une seule balise h1 par page, aucun script ni style en ligne, aucun lien mort, contenu intégralement lisible sans exécuter de JavaScript, URL canoniques alignées sur le sitemap, aucun débordement horizontal, contrastes conformes au niveau AA de 360 à 2 560 px, cibles tactiles d'au moins 44 px, et aucune violation de la politique de sécurité de contenu au chargement des polices, images et vidéo.

Résultats obtenus

• Site en production sur https://kanyro.fr, diffusé en HTTPS par un serveur administré personnellement ; kanyro.tech redirige vers lui, en 308 sur les envois de formulaire pour qu'une demande de devis ne soit jamais rejouée à vide.
• Boîte bonjour@kanyro.fr fonctionnelle : réception vérifiée, lecture en IMAP sur TLS, messages sortants signés par la clé DKIM du domaine.
• Continuité assurée sur l'ancienne adresse : contact@kanyro.tech est devenue un renvoi, et les messages reçus avant la bascule restent consultables sur leur compte d'origine.
• Deux noms de serveur servis par la même machine, chacun avec son certificat : vérifié depuis l'extérieur, mail.kanyro.fr et mail.kanyro.tech répondent tous deux « does match certificate » sur le port 993.
• MX, SPF, DKIM et DMARC de kanyro.fr publiés et concordants, vérifiés depuis trois résolveurs publics indépendants.
• Audit DNS d'août 2026 : trois défauts identifiés puis corrigés, à savoir un MX absent, un hôte mail sans AAAA et un reverse IPv6 incohérent avec le HELO.
• Chaîne validée par un tiers : Gmail constate dkim=pass, spf=pass et dmarc=pass sur un message réel parti en IPv6, en TLS 1.3.
• Durée de conservation de trois ans réellement appliquée : un service de purge la fait respecter dans les deux boîtes, corbeilles et brouillons compris, et a été répété à vide avant d'être armé.
• Audit externe du site noté 42/100 le 11 septembre 2026, puis corrigé : page d'accueil passée de 10 Mo à 164 Ko au chargement, LCP de 22,6 s à 2,1 s en 4G lente simulée, décalage cumulé nul.
• Contrastes AA sur les quatorze pages générées à cette date, de 360 à 2 560 px, aucun texte sous 12 px, cibles tactiles d'au moins 44 px, aucun débordement horizontal.
• Configuration Caddy versionnée dans le dépôt : HSTS, politique de sécurité de contenu en en-tête, Permissions-Policy fermant huit API, signature du serveur retirée, mêmes en-têtes sur la page 404.
• Trois pages légales publiées, dont la génération échoue si l'une est incomplète : mentions légales, conditions générales de vente entre professionnels et politique de confidentialité recensant six traitements avec leur base légale.
• Site entièrement lisible sans JavaScript, sans cookie, sans outil de mesure d'audience tiers et sans requête vers un domaine tiers.
• Documentation d'exploitation rédigée : architecture de la messagerie, fichiers de configuration, enregistrements DNS, procédure de bascule de domaine et procédures de vérification.

Difficultés rencontrées et solutions apportées

• Le service tourne mais rien n'est livré

  Postfix acceptait les messages sans que rien n'arrive dans la boîte. Le socket LMTP de Dovecot n'existait pas : le service avait été configuré mais pas redémarré depuis. La leçon retenue est de vérifier l'existence du socket côté récepteur avant de chercher l'erreur côté émetteur, en remontant le trajet du message brique par brique plutôt qu'en relisant les fichiers de configuration.

• Aucune connexion possible à la boîte

  Le fichier d'utilisateurs référencé dans la configuration de Dovecot n'existait tout simplement pas : la configuration pointait vers un chemin valide en apparence, sans que rien ne signale son absence. Le compte a été créé avec un mot de passe chiffré, et la lecture des journaux du service s'est révélée plus rapide que la relecture de la configuration.

• Un formulaire qui postait dans le vide

  Le formulaire reposait au départ sur le service de formulaires de la plateforme d'hébergement d'origine, dont la détection se fait au moment du déploiement chez cet hébergeur. Déployé ailleurs, le formulaire s'affichait normalement, acceptait la saisie, et ne transmettait rien, sans la moindre erreur. Il a été réécrit en PHP autonome. Une panne silencieuse sur l'unique chemin de contact est le pire des scénarios : elle ne se voit pas.

• Ce qui marche en développement et casse en production

  Deux pièges de même nature ont été rencontrés. Le script d'effets, inséré en ligne par le générateur, était bloqué par la politique de sécurité de contenu, absente en développement, et les pages sortaient vides ; il est désormais servi comme fichier séparé. De même, la directive upgrade-insecure-requests est portée par l'en-tête HTTP et jamais par une balise meta : dans le HTML, elle s'appliquerait aussi aux environnements sans HTTPS, où la page se chargerait sans style. Dans les deux cas, le symptôme n'apparaît qu'une fois déployé.

• Deux enregistrements SPF valent moins qu'un seul

  La zone du nouveau domaine était déjà servie par son registraire, avec ses propres enregistrements de messagerie. Pendant une heure, elle a porté deux SPF : le nouveau et celui du registraire. Deux SPF sur le même nom ne se cumulent pas, ils produisent une erreur permanente que beaucoup de serveurs traitent comme un échec, donc un résultat pire qu'un SPF unique et faux. Celui du registraire refusait de surcroît tout envoi venant d'ailleurs, ce qui aurait fait rejeter chaque message parti du VPS. Même piège du côté des MX : les trois du registraire, en priorité 1, 5 et 100, passaient avant celui du serveur en priorité 10 et captaient donc la totalité du courrier entrant. Migrer une zone, c'est retirer autant qu'ajouter.

• Une purge qui s'arrêtait à la deuxième ligne

  Le service de purge parcourt les dossiers un par un. Hors boîte de réception, les dossiers sont créés par le client de messagerie et non par le serveur : sur une boîte neuve, ils n'existent pas, et la commande sort en erreur. Sans tolérance sur ces lignes, le service s'arrêtait au deuxième dossier et la corbeille, dernière de la liste, n'était jamais vidée. Le problème est apparu le jour de la création de la nouvelle boîte. Une purge qui échoue à mi-parcours ne se voit pas : elle rend simplement fausse, en silence, la durée annoncée sur le site.

• Un client cherche un dossier par son rôle, pas par son nom

  La boîte a été créée depuis un client qui nomme ses dossiers « Deleted Messages » et « Sent Messages », quand la configuration livrée par Dovecot déclarait « Trash » et « Sent ». Un client de messagerie ne cherche pas un dossier par son nom mais par son rôle : ne trouvant pas de corbeille déclarée comme telle, le premier autre client à se connecter s'en serait créé une seconde, que la purge n'aurait pas vue. Les rôles ont donc été attribués aux dossiers existants et les noms concurrents désarmés, la purge couvrant malgré tout les deux conventions.

Bilan

Ce projet est celui où j'ai le plus appris sur l'exploitation, parce que rien n'y est simulé : un serveur mal configuré ne délivre pas de courrier, et un enregistrement DNS oublié envoie les messages en indésirables. Il m'a surtout appris à distinguer « configuré » de « fonctionnel ». Les quatre pannes levées sur la messagerie l'ont toutes été en lisant les journaux et en vérifiant l'état réel des services, jamais en relisant les fichiers de configuration. La partie DNS a été la plus instructive, parce que c'est là que l'audit a trouvé ce que le fonctionnement apparent cachait : le domaine ne publiait aucun enregistrement MX. Le courrier entrant arrivait quand même, par le repli sur l'enregistrement A prévu par la norme, si bien que rien ne signalait le manque. L'effet réel était ailleurs. Le SPF publié, « v=spf1 mx ~all », autorise les hôtes listés dans les MX : sans MX, il n'autorisait personne, et les messages sortants échouaient au SPF depuis le serveur légitime lui-même. Une fois le MX posé, le même raisonnement a fait apparaître un second trou : l'hôte mail n'avait pas d'enregistrement AAAA, alors que Postfix émet indifféremment en IPv4 et en IPv6, et le SPF ne couvrait donc qu'une famille d'adresses sur deux. Après correction, le SPF est évalué PASS dans les deux familles et le reverse IPv6 se confirme. La vérification finale ne vient pas de moi : un message envoyé vers Gmail revient avec dkim=pass, spf=pass et dmarc=pass, et l'en-tête de Google montre qu'il est parti en IPv6, le cas même qui échouait avant la correction. La bascule vers kanyro.fr a prolongé cette leçon sur un autre terrain. Changer de domaine ne consiste pas à remplacer un nom dans des fichiers : il faut décider dans quel ordre les morceaux bougent, garder l'ancien chemin ouvert pour ceux qui l'ont déjà noté, et accepter qu'une partie de la chaîne, le reverse DNS, ne se change pas depuis le serveur et impose donc d'attendre avant de modifier ce qui en dépend. Je retiens de ce projet qu'un service peut fonctionner tout en ayant perdu ses garanties, que seule une vérification menée depuis l'extérieur le montre, et qu'un serveur qui se déclare conforme ne prouve rien tant qu'un destinataire réel ne l'a pas confirmé.

Documents rattachés

• Schéma du trajet d'un message (kanyro.fr) : disponible
• Relevé de vérification de la chaîne de messagerie (kanyro.fr) : disponible

Voir le registre documentaire →

Liens