Fondamentaux de la messagerie¶

Architecture d'un système de messagerie¶

Un système de messagerie repose sur trois composants distincts :

graph LR
    MUA1["MUA<br/>(client)<br/>Expediteur"] -->|SMTP| MTA["MTA<br/>(relais)"]
    MTA -->|SMTP| MDA["MDA<br/>(livraison)"]
    MUA2["MUA<br/>(client)<br/>Destinataire"] -->|IMAP/JMAP| MDA

Protocoles de messagerie¶

SMTP — Simple Mail Transfer Protocol¶

SMTP est le protocole de transport des emails entre serveurs. C'est le seul protocole utilise pour envoyer et relayer les messages.

sequenceDiagram
    participant C as Client MUA
    participant S as Serveur SMTP
    C->>S: EHLO client.example.com
    S->>C: 250 STARTTLS
    C->>S: STARTTLS
    Note over C,S: Negociation TLS
    C->>S: AUTH LOGIN
    C->>S: MAIL FROM:<alice@co.io>
    C->>S: RCPT TO:<bob@dest.io>
    C->>S: DATA (contenu du message)
    C->>S: .
    S->>C: 250 OK

IMAP — Internet Message Access Protocol¶

IMAP est le protocole de consultation des emails. Les messages restent sur le serveur, le client se synchronise.

JMAP — JSON Meta Application Protocol¶

JMAP est le successeur moderne d'IMAP. Il utilise HTTP/JSON au lieu d'un protocole binaire proprietaire.

POP3 — Post Office Protocol¶

POP3 est un protocole de consultation ancien qui telecharge et supprime les emails du serveur. Il est deconseille pour un usage moderne (pas de synchronisation multi-appareils).

DNS pour la messagerie¶

Le DNS est fondamental pour le routage et la sécurité des emails. Plusieurs types d'enregistrements sont nécessaires.

Enregistrement MX¶

L'enregistrement MX (Mail eXchanger) indique quel serveur reçoit les emails pour un domaine :

; Zone DNS pour company.io
company.io.    300  IN  MX  10  mail.company.io.
company.io.    300  IN  MX  20  mail-backup.company.io.

mail.company.io.         300  IN  A  203.0.113.10
mail-backup.company.io.  300  IN  A  203.0.113.11

La priorité (10, 20) determine l'ordre de tentative : le serveur de priorité la plus basse est contacte en premier. Le serveur de priorité 20 sert de backup.

Enregistrement SPF¶

SPF (Sender Policy Framework) declare quelles adresses IP sont autorisees a envoyer des emails pour un domaine :

; Seul le serveur mail.company.io peut envoyer pour company.io
company.io.  300  IN  TXT  "v=spf1 mx a:mail.company.io -all"

Enregistrement DKIM¶

DKIM (DomainKeys Identified Mail) signe cryptographiquement chaque email sortant. Le serveur destinataire verifie la signature via un enregistrement DNS TXT :

; Cle publique DKIM
default._domainkey.company.io.  300  IN  TXT  (
    "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
)

Le serveur d'envoi signe l'email avec la cle privee correspondante. Le récepteur récupère la cle publique via DNS et verifie la signature.

Enregistrement DMARC¶

DMARC (Domain-based Message Authentication, Reporting & Conformance) définit la politique a appliquer quand SPF et DKIM échouent :

; Politique DMARC : rejeter les emails non authentifies
_dmarc.company.io.  300  IN  TXT  (
    "v=DMARC1; p=reject; rua=mailto:dmarc-reports@company.io; "
    "ruf=mailto:dmarc-forensic@company.io; pct=100"
)

Autoconfig et Autodiscover¶

Pour simplifier la configuration des clients email, deux mécanismes de découverte automatique existent :

; Mozilla Autoconfig (Thunderbird)
autoconfig.company.io.  300  IN  CNAME  mail.company.io.

; Microsoft Autodiscover (Outlook)
_autodiscover._tcp.company.io.  300  IN  SRV  0  0  443  mail.company.io.

Le serveur mail doit exposer un fichier XML de configuration sur ces endpoints :

• https://autoconfig.company.io/mail/config-v1.1.xml (Mozilla)
• https://mail.company.io/autodiscover/autodiscover.xml (Microsoft)

Chaîne d'authentification email¶

Les quatre mécanismes d'authentification s'empilent pour former une chaîne de confiance :

graph TD
    Email["Email entrant"] --> SPF
    SPF["SPF<br/>IP autorisee ?"] -->|pass / fail / softfail| DKIM
    DKIM["DKIM<br/>Signature valide ?"] -->|pass / fail / temperror| DMARC
    DMARC["DMARC<br/>SPF ou DKIM alignes<br/>avec le domaine From: ?"] -->|pass: none / quarantine / reject| ARC
    ARC["ARC<br/>Chaine de relais<br/>intermediaires verifiee ?"] -->|Preserve l authentification<br/>apres forwarding| Done["Resultat"]

ARC — Authenticated Received Chain¶

ARC résout un problème fondamental : quand un email est relaye (mailing list, redirect), les signatures DKIM et SPF d'origine échouent. ARC cree une chaîne de confiance entre les intermédiaires :

Filtrage anti-spam¶

rspamd¶

rspamd est le filtre anti-spam moderne de référence. Il utilise une combinaison de techniques :

SpamAssassin¶

SpamAssassin est l'alternative historique, écrite en Perl. Moins performant que rspamd mais avec une base de regles tres mature :

Listes de diffusion¶

Les listes de diffusion (mailing lists) permettent d'envoyer un email a un groupe d'adresses. Deux modes de fonctionnement :

Stalwart supporte les listes de diffusion nativement. Pour des besoins avances (archives web, moderation, abonnement), un outil dedie comme Sympa ou GNU Mailman peut etre ajoute.

Integration calendrier (CalDAV)¶

CalDAV est le protocole standard pour la synchronisation des calendriers, des contacts (CardDAV) et des tâches. Il est complementaire de la messagerie car :

• Les invitations de calendrier transitent par email (format iCalendar/iMIP)
• Le serveur de messagerie peut traiter les réponses aux invitations automatiquement
• Un point d'accès unique (même serveur, même authentification) simplifie l'expérience utilisateur

Stalwart integre un serveur CalDAV/CardDAV natif, ce qui evite le déploiement d'un serveur de calendrier separe (Radicale, Baical).

Synthese¶

La messagerie est un ecosysteme complexe qui repose sur de multiples protocoles et standards. La bonne comprehension de la chaîne SMTP→IMAP, des enregistrements DNS et de la chaîne d'authentification SPF→DKIM→DMARC→ARC est un prerequis avant de choisir et déployer une solution. Le chapitre suivant compare les solutions disponibles.