MTA-STS — imposer le chiffrement des e-mails entrants

MTA-STS force les serveurs expéditeurs à chiffrer et à vérifier le certificat de vos serveurs de réception. Mal configuré, il bloque la remise sans le moindre signe visible.

Le problème que MTA-STS résout

Le chiffrement entre serveurs de messagerie est par défaut opportuniste : si le serveur destinataire propose TLS, on chiffre, sinon on envoie en clair. Un attaquant placé sur le chemin peut donc simplement supprimer l’annonce TLS pour que tout passe en clair, sans que personne ne s’en aperçoive.

MTA-STS permet à un domaine de déclarer : « mes serveurs de réception supportent TLS, avec un certificat valide, et vous devez refuser de livrer autrement ».

Comment ça se met en place

Deux morceaux sont nécessaires, et il faut les deux.

Un enregistrement TXT sur _mta-sts.exemple.fr :

v=STSv1; id=20260910120000

Un fichier servi en HTTPS sur un sous-domaine dédié, https://mta-sts.exemple.fr/.well-known/mta-sts.txt :

version: STSv1
mode: enforce
mx: mx1.exemple.fr
mx: mx2.exemple.fr
max_age: 604800

Le sous-domaine mta-sts. doit avoir son propre certificat TLS valide. C’est souvent l’étape qui coince.

Les trois modes

• none : la politique est publiée mais désactivée. Sert à sortir proprement de MTA-STS.
• testing : les échecs sont rapportés via TLS-RPT mais la remise se fait quand même.
• enforce : les échecs bloquent la remise.

Le piège : la panne différée

C’est le risque propre à MTA-STS, et il mérite d’être compris avant de déployer.

Les serveurs expéditeurs mettent la politique en cache pour la durée indiquée par max_age, souvent une semaine. Si vous changez de messagerie et que vos nouveaux serveurs MX ne figurent pas dans la politique, les expéditeurs qui ont l’ancienne version en cache refusent de vous livrer — et continuent pendant des jours.

Le symptôme est déroutant : certains expéditeurs vous joignent, d’autres non, sans logique apparente, et votre propre serveur ne voit rien puisque les messages n’arrivent jamais.

La règle est donc : mettre la politique à jour avant de changer les MX, et vérifier que chaque MX déclaré dans le DNS est bien couvert par la politique.

L’ordre de déploiement

1. Publiez le fichier de politique en mode: testing et l’enregistrement TXT.
2. Activez TLS-RPT pour recevoir les rapports d’échec.
3. Attendez deux semaines et vérifiez que les rapports sont propres.
4. Passez en mode: enforce et incrémentez l’id du TXT.

Ne commencez jamais par enforce.