Comment sécuriser le courrier entre serveurs, de DNSSEC à DANE, et pourquoi chaque réglage doit être juste. Mis en œuvre avec Postfix, Microsoft 365 et Stalwart.
Le courrier entre deux serveurs a été conçu pour être livré, pas pour rester privé.
Par défaut, il part en clair, ou chiffré seulement si personne ne s’en mêle.
Les réglages qui corrigent cela se trouvent tous dans le DNS. Chacun ferme une brèche différente. Si l’un d’eux est faux, le courrier est livré quand même, et rien ne vous prévient.
Ces articles couvrent :
Ce que protège chaque réglage : SPF, DKIM, DMARC, MTA-STS, les rapports TLS et DANE.
Pourquoi DANE a besoin de DNSSEC en dessous, et ce qui se passe quand un certificat est renouvelé.
Comment tout mettre en place sur Postfix, et prouver que cela fonctionne.
Ce que Microsoft 365 vous laisse contrôler, et ce qu’il ne vous laisse pas.
Comment Stalwart gère les mêmes réglages, intégrés plutôt qu’ajoutés.
Chaque vérification de ces articles peut être faite sur n’importe quel domaine, le vôtre ou celui de quelqu’un d’autre.
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.
Postfix, DANE et chaque réglage fait correctement
Par défaut, Postfix envoie en clair quand l’autre bout n’offre pas de TLS et accepte du courrier de quiconque prétend être qui il veut. Voici l’autre installation : Postfix 3.10.13 avec Dovecot pour les logins, Rspamd pour SPF, DKIM et DMARC, et postfix-tlspol pour DANE et MTA-STS. Pas de clair en entrée ni en sortie, le port 25 ne relaie jamais, un login possède ses adresses dans l’enveloppe et l’en-tête From, les domaines expéditeurs qui n’existent pas sont refusés, et un message altéré ou usurpé ne passe jamais DATA. Chaque réponse a été capturée dans un labo en IPv4 et IPv6, ainsi que les cinq réglages qui ne font silencieusement rien tant qu’un autre n’est pas posé lui aussi, le défaut de certbot qui casse DANE au renouvellement, et ce que tout cela vous coûte en courrier réexpédié.
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.
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.
