Chapitre 16 / 39

Mail

Statut : Bloqué — en attente du Framework Desktop et du ticket opérateur de Jack pour obtenir une adresse IPv4 statique avec accès au port 25. Le ticket opérateur est le seul chemin possible.

Les 33 boîtes mail Sodimo tournent sur le Framework Desktop dans la salle serveur de Gennevilliers. Postfix remet les messages, Dovecot les stocke, rspamd les filtre et les signe, Piler les archive. Chaque service est un quadlet Podman sur le harness Fedora (chapitre 35), de sorte qu’une coupure de courant ou un redémarrage remet le mail en route sans aucune intervention.

Aujourd’hui : 33 boîtes mail sur quatre domaines chez Strato. Strato n’offre aucun contrôle sur l’archive, aucune garantie de suppression et aucune souveraineté sur la correspondance de Sodimo.

Cible : mail self-hosted sur le harness Fedora. Chaque message — entrant et sortant — vit sur du matériel que Sodimo contrôle. Zéro coût d’hébergement. Pas de prestataire d’archive externe.

Ce que l’équipe doit faire :

Jack : faire avancer le ticket opérateur — adresse IPv4 statique et accès au port 25. C’est l’action la plus importante avant de pouvoir démarrer la migration mail.
Paul : valider la liste d’exclusion des boîtes (un petit ensemble de comptes de service legacy qui ne seront pas migrés). La notice de transparence CNIL pour les salariés est reportée à la remise de fin de mission du chapitre 6 ; toute l’équipe la lit ensemble à ce moment-là.
Tout le monde : rien pendant la migration. Le mail continue de circuler normalement sur Strato pendant que chaque domaine bascule en arrière-plan.

Ordre de migration (domaines de test en premier, sodimo.eu en dernier) :

yallafood.eu → cavisteduliban.fr → sodimonet.fr → sodimo.eu

sodimo.eu bascule en dernier car c’est le domaine le plus important. Strato reste actif quatre semaines après chaque bascule comme filet de sécurité — protection supplémentaire pour le delta imapsync qui rattrape les messages arrivant encore sur l’ancien serveur. En cas de problème, les enregistrements MX reviennent en arrière en quelques minutes.

Rampe DMARC. Chaque domaine démarre à p=none pendant que les signatures DKIM sont validées chez Gmail et Outlook. Une fois les signatures propres chez les deux fournisseurs, le domaine passe directement à p=reject. L’étape quarantaine est sautée — elle ajoute du délai sans apporter d’information supplémentaire.

Conservation : conserver tous les emails, indéfiniment.

Chaque email — entrant et sortant — est conservé indéfiniment, avec un plafond de travail d’environ 100 Go sur l’archive. Rien n’est purgé. Rien n’est supprimé selon un calendrier. Si un message a jamais été remis à ou envoyé depuis une boîte Sodimo, il est dans Piler.

Piler est l’archive : un index en écriture seule et à recherche plein texte qui se place derrière Postfix et Dovecot. Quand le plafond de 100 Go est atteint, l’opérateur provisionne plus de stockage — Piler n’est pas un buffer rotatif.

Les personnes consultent l’archive via l’interface admin de Piler, accessible via Tailscale (chapitre 31) — pas de compte par personne, pas de modèle de permissions par boîte.
Claude consulte l’archive via un token de service sur le serveur MCP (chapitre 42). Le token est la façon dont les outils IA retrouvent les fils et pièces jointes d’un client sans avoir besoin d’identifiants individuels.

Le comptable confirme la durée minimale de conservation requise par les codes commercial et fiscal français. L’indéfini couvre ce besoin.

Boîtes partagées. info@, contact@, business@, exports@, commandes@ fonctionnent comme des dossiers partagés dans le client mail de chaque participant. Les alias sodimo.eu existants sont conservés à l’identique — les outils MCP parlent anglais en interne (orders@ est l’alias anglais de commandes@), mais les adresses email que les clients connaissent ne changent pas. L’équipe ajoute et supprime des alias directement.

Envoi d’email depuis la couche IA

Chaque email que la stack IA envoie — un brouillon de lettre de Recouvrement approuvé par Paul, un accusé de réception de commande, une relance, n’importe quoi — suit le même circuit. L’IA ne touche pas Postfix directement ; elle appelle un outil MCP sur le Cloudflare Worker, et un petit service sur le harness Fedora récupère le message depuis une queue et le remet à sendmail. C’est une application délibérée du Principe 3 (chapitre 15) : une politique d’autorisation d’expéditeur unique, un registre d’exécution unifié, un seul endroit pour le rate-limiting.

Le harness Fedora n’expose aucun port entrant pour ce chemin. cloudflared n’est pas impliqué. Si la machine est hors ligne, les messages sont mis en queue jusqu’à quatre jours (durée de conservation par défaut des Cloudflare Queues) et se vident à son retour. Les envois échoués retentent avec backoff jusqu’à trois fois, puis atterrissent dans email_dlq pour inspection manuelle.

Pourquoi cette forme, et pas un appel direct de l’agent à sendmail. Quatre propriétés que le circuit préserve — chacune définitivement perdue si un producteur contourne le Worker :

Registre d’exécution unifié. Chaque envoi d’email est une ligne dans run_ledger (chapitre 15, Principe 2). Un raccourci vers le sendmail local produit un envoi invisible et casse l’étude des économies.
Politique d’autorisation d’expéditeur unique. Le contrôle ALLOWED_SENDERS du Worker est la source de vérité pour qui envoie en tant qui. Deux politiques dérivent ; une seule ne dérive pas.
Observabilité uniforme. Un outil, un schéma, un endroit. « Tous les emails envoyés par la stack IA cette semaine » est une seule requête SQL contre run_ledger.
Rate-limiting et gestion de la dead-letter queue. Une boucle d’agent incontrôlée frappe une queue avec contre-pression et une DLQ, pas Postfix à pleine vitesse — c’est ainsi qu’on perd sa réputation IP pour des semaines.

Rollback. Si DKIM échoue chez Gmail ou Outlook après une bascule, les enregistrements MX reviennent immédiatement en arrière. La bascule de chaque domaine a un responsable de décision désigné et une fenêtre de décision de 15 minutes.