Set-OPS-Public/docs/courriel-conception.md

Conception — Service de courriel souverain (Chezlepro)

Statut : CONCEPTION (cadrage). Aucun rôle n'est encore écrit. Ce document fixe les décisions, les prérequis et la topologie avant toute implémentation.

1. Décisions arrêtées

Sujet	Décision
Périmètre	Vrai service de courriel (boîtes utilisateurs, réception publique, IMAP) — pas un simple relais sortant.
Modèle	Full self-host : MX entrant et sortant chez Chezlepro, réputation d'IP propre.
Suite	Stalwart Mail Server (binaire unique Rust, AGPL ; SMTP/IMAP/JMAP/POP3 + anti-spam + DKIM intégrés). Adoptée et enveloppée par un rôle Set-OPS mince — pas de réimplémentation.
Identité	Boîtes/utilisateurs dans l'OpenLDAP existant (annuaire Stalwart → LDAP). Pas de comptes en double.
DNS	Enregistrements publics dans la zone chezlepro.ca ; noms internes dans PowerDNS.
PKI	Deux CA distinctes (voir §6) : Let's Encrypt pour les faces publiques, step_ca pour l'interne.

Le rôle existant serveur_sendmail (relais sortant Postfix, sans boîtes) reste pour le courrier de notification système (via client_smtp/msmtp). Il ne fait pas partie de ce service et ne le remplace pas.

2. Prérequis BLOQUANT — l'IP publique

Le full self-host sortant est viable seulement si :

• IP publique fixe avec un PTR (reverse DNS) contrôlé pointant vers mail1.chezlepro.ca ;
• IP absente des listes noires (Spamhaus, etc.) ;
• ports 25 / 465 / 587 / 993 / 443 / 80 routables vers les nœuds mail ;
• SPF/DKIM/DMARC en place + réchauffement de réputation.

⚠️ Si l'IP de sortie ne peut pas avoir un PTR propre ou est sur une blocklist grand public, l'envoi vers Gmail/Outlook échouera — quelle que soit la suite. À vérifier AVANT toute implémentation.

Décision ouverte : quelle IP / quel hébergement portera le mail de prod ? (non tranché)

3. Topologie (2-3 nœuds)

                          INTERNET
                             │
        DNS public chezlepro.ca :  MX 10 → mail1 ,  MX 20 → mail2
                             │
             ┌───────────────┴───────────────┐
             ▼                                ▼
   ┌───────────────────┐            ┌───────────────────┐
   │ mail-01 (PRIMAIRE) │            │ mail-02 (MX secours)│
   │ Stalwart complet   │◄──relais──│ Stalwart mode relais│
   │ SMTP 25 / 587 / 465│  quand    │ SMTP 25 seulement   │
   │ IMAP 993 / JMAP 443│  mail-01  │ file d'attente puis │
   │ antispam + DKIM     │  est down │ transfert à mail-01 │
   │ BOÎTES stockées     │           └───────────────────┘
   └─────────┬──────────┘
             │ (réseau interne, mTLS step_ca)
     ┌───────┼─────────────┬──────────────┐
     ▼       ▼             ▼              ▼
  OpenLDAP  step_ca     PowerDNS      PostgreSQL
 (identité)(certs int.)(DNS interne)(métadonnées, option HA)

• mail-01 (primaire) — Stalwart complet : réception :25, soumission authentifiée :587/:465, accès client IMAP :993 + JMAP/web :443, anti-spam, signature DKIM, hébergement des boîtes.
• mail-02 (MX de secours) — Stalwart en mode relais, écoute seulement :25. Quand mail-01 est indisponible, accepte + met en file l'entrant, puis retransmet au rétablissement → zéro perte à l'entrée. À placer idéalement sur un lien/IP indépendant (autre site ou VPS), sinon la résilience est illusoire.

Décision ouverte : emplacement du MX secours (même cluster ? VPS ? autre site ?).

4. Stockage

• v1 : stockage embarqué (RocksDB) sur mail-01 + sauvegardes rigoureuses. Simple et souverain. Le MX secours protège l'entrée, pas les boîtes → la résilience des données repose sur les sauvegardes.
• HA ultérieure : métadonnées dans PostgreSQL (pilier existant) + blobs sur stockage partagé, pour un primaire plus stateless.

5. Flux

• Entrant : expéditeur → MX DNS → mail-01 :25 (ou mail-02 si down) → contrôles SPF/DKIM/DMARC + anti-spam → livraison à la boîte (utilisateur résolu via LDAP).
• Sortant : client authentifié (LDAP) → soumission :587 → signature DKIM → remise directe MX vers le serveur destinataire :25 (← PTR + réputation décisifs).
• Accès client : client mail → IMAP :993 / JMAP :443 → auth LDAP → boîte.

6. TLS — deux CA distinctes (à ne pas confondre)

Face	CA	Pourquoi
Publique (25/465/587/993/443 vers le monde)	Let's Encrypt (ACME intégré à Stalwart)	Les serveurs et clients distants valident contre les racines publiques ; ils ne connaissent pas l'AC interne.
Interne (mail ↔ LDAP, ↔ PostgreSQL, ↔ MX secours)	step_ca	Le mTLS souverain déjà en place pour les liaisons internes.

7. Pare-feu (nftables)

Le socle installe nftables désactivé. Les nœuds mail sont un des endroits où on l'active avec des règles adaptées au rôle :

• Ouvert au monde : 25, 465, 587, 993, 443, 80 (ACME).
• Interne seulement : LDAP, PostgreSQL, interface d'admin Stalwart.

8. Enregistrements DNS publics (chezlepro.ca)

mail1                 A     <IP publique mail-01>
mail2                 A     <IP publique mail-02>
@                     MX 10 mail1.chezlepro.ca.
@                     MX 20 mail2.chezlepro.ca.
@                     TXT   "v=spf1 mx -all"
default._domainkey    TXT   "v=DKIM1; k=rsa; p=<clé publique DKIM Stalwart>"
_dmarc                TXT   "v=DMARC1; p=quarantine; rua=mailto:dmarc@chezlepro.ca"

• PTR (reverse) : <IP mail-01> → mail1.chezlepro.ca (chez le propriétaire de l'IP).
• MTA-STS / TLS-RPT : optionnels, recommandés.

9. Traduction Set-OPS

• Nomenclature : 2 fonctions, p. ex. comm-mail (primaire) + comm-mx2 (secours) ; VMID / IP / VLAN dérivés comme le reste.
• Rôles :
  • serveur_stalwart — mince : installe le binaire Stalwart, dépose la config (annuaire LDAP, ACME public, DKIM, certs internes step_ca), unité systemd, règles nftables mail.
  • variante « relais » (ou paramètre du même rôle) pour le MX de secours.
• Intégrations des nœuds mail : client_ldap (auth), client_pki (certs internes), client_dns.
• Secrets (voûte) : clé/mots de passe d'admin Stalwart, éventuel secret ACME, clé privée DKIM — via vault_*, câblés au rôle (comme les autres secrets).

10. Décisions ouvertes (à trancher avant l'implémentation)

1. IP publique + PTR de prod — le make-or-break (§2).
2. Emplacement du MX de secours (§3).
3. Stockage : embarqué v1 vs PostgreSQL dès le départ (§4).
4. Domaine(s) desservi(s) : chezlepro.ca seul, ou multi-domaines (tenants) ?

11. Phasage proposé

1. Vérifier l'IP/PTR (prérequis bloquant). Sans ça, rien.
2. Écrire serveur_stalwart + le déployer sur mail-01 dans le bac à sable (interne d'abord, ACME en mode staging/interne).
3. Brancher LDAP (auth), step_ca (interne), DKIM.
4. Ajouter mail-02 (MX secours).
5. Poser les enregistrements DNS publics + basculer l'ACME en production.
6. Tests de bout en bout : réception, envoi vers Gmail/Outlook, SPF/DKIM/DMARC verts, bascule MX secours.

---

Ce document est un cadrage vivant : il évolue à mesure que les décisions ouvertes se tranchent. Il ne décrit pas encore de code livré.