Skip to content
Sept réglages de messagerie le long du chemin entre deux serveurs, avec DNSSEC et IPv6 en dessous

Pourquoi chaque réglage de messagerie doit être correct

Chaque couche de la sécurité du courrier est conçue pour retomber sur du fonctionnel plutôt que d’échouer proprement. Retirez la ligne STARTTLS d’une salutation et un émetteur opportuniste continue en clair, ce que la RFC 3207 décrit à la fois comme une attaque et, sur un serveur public, vous interdit de combattre. Cet article capture cet homme du milieu en labo, puis parcourt les sept réglages qui protègent un message en transit, en montrant pour chacun ce qu’il protège, ce qu’il ne protège pas, et comment il échoue en laissant passer quand il est mauvais. De là jusqu’à DANE : pourquoi un enregistrement TLSA ne vaut rien sans DNSSEC en dessous, pourquoi 3 1 1 et la réutilisation de la clé comptent, et comment un enregistrement périmé est le seul échec qui bloque au lieu de laisser passer. Puis un recensement en lecture seule des banques britanniques, des grands fournisseurs de messagerie et des autorités de certification, comptant combien en font réellement quoi que ce soit.

22 octobre 2026 Â· 21 min Â· 4677 mots Â· Damien Dye
Un partage entre les réglages que Microsoft 365 contrôle pour vous et les quelques-uns qu'il vous laisse configurer, avec les règles qu'il ne peut pas tenir marquées

Microsoft 365 : l'édition Fisher-Price de l'informatique

La plupart des organisations n’exploitent pas leur propre serveur de courrier. Elles paient Microsoft, et Exchange Online fait le travail. Cet article tient donc Microsoft 365 aux règles maison exactes que les montages Postfix et Stalwart ont satisfaites, en n’utilisant que la documentation de Microsoft et le DNS en lecture seule contre de vrais tenants. Certaines règles sont bien tenues : DANE et MTA-STS sortants sont actifs par défaut, et le DANE entrant avec DNSSEC est enfin disponible. Plusieurs ne peuvent pas être tenues du tout. Il n’existe aucun moyen documenté d’exiger le TLS entrant de chaque expéditeur, aucun moyen de rejeter un échec SPF à la porte, rien qui rejette sur une signature DKIM seule défaillante, et aucun contrôle qui jette le courrier d’un domaine expéditeur qui n’existe pas. DNSSEC n’est explicitement pas prévu pour l’hôte de courrier que tout tenant utilise vraiment. Le déploiement d’IPv6 qui devait prendre six mois a laissé la boîte du NCSC injoignable en IPv6 deux ans plus tard. Et la documentation se contredit sur les wildcards, sur SPF et sur DNSSEC. C’est la plateforme sur laquelle tourne la quasi-totalité du courrier du pays, et voici ce qu’elle vous laisse faire, et ce qu’elle ne vous laisse pas faire.

22 octobre 2026 Â· 13 min Â· 3078 mots Â· Damien Dye
Stalwart en un seul binaire contenant toute la pile de courrier, face au montage Postfix en quatre paquets

Stalwart : DANE et le reste, tout est intégré

Stalwart est un serveur de courrier entier dans un seul binaire : SMTP et IMAP et JMAP, SPF, DKIM, DMARC, ARC, DANE, MTA-STS, les rapports TLS, un filtre antispam et le magasin de courrier, sans milter à câbler ni démon de politique à faire tourner à côté. Cet article le soumet aux mêmes règles maison que le montage Postfix et capture chaque réponse au labo. Toutes les règles finissent par s’activer, mais tout se joue dans le détail : les réglages vivent dans une base de données plutôt que dans un fichier, les valeurs par défaut telles que livrées acceptent le clair et une facture falsifiée, chaque règle atterrit dans l’un des quatre mécanismes de configuration, le rejet sur échec DKIM a besoin d’un script Sieve parce que le contrôle intégré signale un corps falsifié comme neutre, le contrôle de l’expéditeur inconnu ne s’exécute qu’une fois le message entier reçu et reste en fail-open sur une erreur DNS, et l’émetteur MTA-STS rebondit dès la première tentative là où la norme dit qu’il devrait différer. L’intégré, c’est réellement moins de choses à câbler ensemble. Ce n’est pas la même chose que sûr par défaut.

22 octobre 2026 Â· 14 min Â· 2930 mots Â· Damien Dye