Architecture de référence messagerie¶

Vue d'ensemble¶

L'architecture cible repose sur Stalwart Mail Server comme composant central, avec un reverse proxy TLS en frontal, un backend d'authentification LDAP/OIDC et un DNS correctement configure.

graph TD
    subgraph Internet["Internet / DMZ"]
        Exp["Expediteurs externes"]
        Clients["Clients email<br/>(Thunderbird, etc.)"]
        Web["Clients web<br/>(navigateur)"]
    end
    Exp -->|SMTP:25| Proxy
    Clients -->|IMAP:993 / JMAP:443| Proxy
    Web -->|HTTPS:443| Proxy
    Proxy["Reverse Proxy (Caddy / Nginx)<br/>Terminaison TLS, Let's Encrypt<br/>mail.company.io"]
    Proxy -->|SMTP:25| Stalwart
    Proxy -->|IMAP:993 / JMAP:8080| Stalwart
    Proxy -->|HTTPS:8080 admin UI| Stalwart
    subgraph Stalwart["Stalwart Mail Server"]
        SMTP["SMTP<br/>MTA/MDA"]
        IMAP["IMAP<br/>serveur"]
        JMAP["JMAP<br/>serveur"]
        CalDAV["CalDAV<br/>CardDAV"]
        subgraph Core["Core Engine"]
            AntiSpam["Anti-spam"]
            DKIM["DKIM<br/>SPF/DMARC"]
            Sieve["Sieve<br/>filtres"]
            Queue["Queue<br/>manager"]
        end
        Storage["Storage Layer<br/>RocksDB | PostgreSQL | S3"]
    end
    Stalwart --> Keycloak["Keycloak<br/>LDAP/OIDC"]
    Stalwart --> DNS["CoreDNS<br/>MX/SPF/DKIM/DMARC"]
    Stalwart --> Monitoring["Prometheus<br/>+ Grafana"]

Composants Stalwart¶

Binaire unique, multi-protocoles¶

Stalwart est compile en un seul binaire Rust qui expose tous les protocoles nécessaires :

Moteur anti-spam integre¶

Stalwart integre un filtre anti-spam compatible avec les regles rspamd. Il effectue les verifications suivantes a la reception de chaque email :

1. Vérification SPF : l'IP de l'expéditeur est-elle autorisee ?
2. Vérification DKIM : la signature cryptographique est-elle valide ?
3. Vérification DMARC : SPF et/ou DKIM sont-ils alignes avec le domaine From ?
4. ARC : si l'email a ete relaye, la chaîne ARC est-elle valide ?
5. DNS blocklists : l'IP de l'expéditeur est-elle listee dans des RBL ?
6. Analyse du contenu : scoring bayesien, patterns de spam
7. Rate limiting : limitation du débit par expéditeur

Couche de stockage¶

Stalwart supporte plusieurs backends de stockage, choisis en fonction du volume :

Configuration DNS pour la messagerie¶

Ensemble complet des enregistrements¶

Un domaine de messagerie correctement configure necessite les enregistrements DNS suivants :

; === Enregistrements MX ===
company.io.    300  IN  MX  10  mail.company.io.
company.io.    300  IN  MX  20  mail-backup.company.io.

; === Enregistrements A/AAAA du serveur mail ===
mail.company.io.         300  IN  A     203.0.113.10
mail.company.io.         300  IN  AAAA  2001:db8::10
mail-backup.company.io.  300  IN  A     203.0.113.11

; === SPF — IP autorisees a envoyer ===
company.io.  300  IN  TXT  "v=spf1 mx a:mail.company.io -all"

; === DKIM — cle publique de signature ===
default._domainkey.company.io.  300  IN  TXT  (
    "v=DKIM1; k=ed25519; p=<base64-public-key>"
)

; === DMARC — politique d'authentification ===
_dmarc.company.io.  300  IN  TXT  (
    "v=DMARC1; p=reject; "
    "rua=mailto:dmarc-reports@company.io; "
    "ruf=mailto:dmarc-forensic@company.io; "
    "adkim=s; aspf=s; pct=100"
)

; === MTA-STS — forcer TLS pour les connexions SMTP entrantes ===
_mta-sts.company.io.     300  IN  TXT  "v=STSv1; id=20260416"
mta-sts.company.io.      300  IN  A    203.0.113.10

; === TLSRPT — rapports TLS ===
_smtp._tls.company.io.   300  IN  TXT  (
    "v=TLSRPTv1; rua=mailto:tls-reports@company.io"
)

; === Autoconfig / Autodiscover ===
autoconfig.company.io.   300  IN  CNAME  mail.company.io.
_autodiscover._tcp.company.io.  300  IN  SRV  0 0 443 mail.company.io.

; === Reverse DNS (PTR) — critique pour la deliverabilite ===
; Configure chez le fournisseur d'hebergement/IP
10.113.0.203.in-addr.arpa.  300  IN  PTR  mail.company.io.

Vérification des enregistrements¶

# Verifier MX
dig company.io MX +short
# Attendu : 10 mail.company.io.

# Verifier SPF
dig company.io TXT +short | grep spf
# Attendu : "v=spf1 mx a:mail.company.io -all"

# Verifier DKIM
dig default._domainkey.company.io TXT +short
# Attendu : "v=DKIM1; k=ed25519; p=..."

# Verifier DMARC
dig _dmarc.company.io TXT +short
# Attendu : "v=DMARC1; p=reject; ..."

# Verifier reverse DNS
dig -x 203.0.113.10 +short
# Attendu : mail.company.io.

Reverse proxy et terminaison TLS¶

Pourquoi un reverse proxy ?¶

Le reverse proxy assure la terminaison TLS et la distribution du trafic vers Stalwart :

Configuration Caddy¶

# Caddyfile
mail.company.io {
    # JMAP, CalDAV/CardDAV, Admin UI
    reverse_proxy localhost:8080
}

Pour les protocoles mail (SMTP, IMAP), utiliser un load balancer TCP (HAProxy, Caddy L4) ou exposer directement les ports de Stalwart.

Dimensionnement¶

Guide de sizing¶

Estimation du stockage¶

# Estimation pour 200 utilisateurs, 5 ans de retention
200 users x 17.5 Go/an x 5 ans = 17.5 To
+ 30% overhead (index, logs) = ~23 To

Flux réseau¶

Ports a ouvrir¶

Zones réseau¶

graph LR
    subgraph DMZ
        Proxy["Reverse proxy<br/>(SMTP in, HTTPS)"]
    end
    subgraph Interne["Reseau interne"]
        Stalwart["Stalwart<br/>(tous ports)"]
        Services["Keycloak,<br/>PostgreSQL,<br/>CoreDNS"]
        Stalwart --> Services
    end
    Proxy --> Stalwart

Synthese¶

L'architecture Stalwart se distingue par sa simplicité : un seul binaire qui expose SMTP, IMAP, JMAP, CalDAV et l'administration. Le reverse proxy assure la terminaison TLS pour le trafic HTTP, tandis que Stalwart gère lui-même le TLS pour les protocoles mail. Le dimensionnement depend principalement du nombre d'utilisateurs et de la politique de retention. Le chapitre suivant detaille l'installation et la configuration.