MTA-STS et TLS-RPT brièvement expliqués
MTA-STS et TLS-RPT sont deux paramètres pour votre domaine qui concernent le chiffrement des e-mails qui arrivent chez vous. Vous les rencontrez dans des tests comme internet.nl ou dans un rapport d'analyse de sécurité. Cet article explique ce qu'ils font, à quoi ils ressemblent et si vous en avez besoin. Réponse courte d'emblée : pour la plupart des clients, ce n'est pas nécessaire.
Quel problème cela résout-il ?
Lorsqu'un serveur de messagerie délivre un e-mail au serveur de messagerie du destinataire, la connexion est chiffrée si possible (STARTTLS). Si ce n'est pas possible, l'e-mail part généralement simplement sans chiffrement. De plus, le certificat du serveur destinataire n'est souvent pas vérifié de manière stricte. Quelqu'un capable de modifier le trafic en chemin peut ainsi désactiver le chiffrement ou rediriger l'e-mail vers son propre serveur.
Avec MTA-STS, vous indiquez en tant que destinataire : les e-mails vers mon domaine doivent toujours être chiffrés, et uniquement envoyés vers ces serveurs de messagerie avec un certificat valide. Un expéditeur qui prend en charge MTA-STS s'y conforme.
Les deux composants de MTA-STS
1. Un enregistrement TXT sur le nom _mta-sts, qui indique qu'une politique existe :
_mta-sts.jouwdomein.nl. TXT "v=STSv1; id=20261108T120000;"
L'id est un numéro de version que vous choisissez vous-même. Si vous modifiez la politique, changez également l'id, afin que les expéditeurs récupèrent la nouvelle politique.
2. Un fichier de politique à exactement cette adresse, via https avec un certificat valide :
https://mta-sts.jouwdomein.nl/.well-known/mta-sts.txt version: STSv1 mode: testing mx: linux2023.webawere.nl max_age: 604800
| Ligne | Signification |
|---|---|
mode: testing | Les expéditeurs livrent comme d'habitude, mais signalent les problèmes via TLS-RPT. C'est par là que vous commencez. |
mode: enforce | Les expéditeurs livrent uniquement via une connexion chiffrée avec un certificat valide, vers l'un des serveurs de messagerie mentionnés. Si cela échoue, l'e-mail reste dans la file d'attente chez l'expéditeur. |
mode: none | Il n'y a (plus) de politique. |
mx: | Le nom de votre serveur de messagerie, exactement comme dans votre enregistrement MX. Si vous avez plusieurs enregistrements MX, indiquez chaque nom sur une ligne séparée. Pour un pack WebOké, il s'agit généralement du nom de serveur de votre pack, comme dans l'exemple ; le certificat de notre serveur de messagerie correspond à ce nom. Si votre MX pointe vers votre propre nom de domaine, le certificat pourrait ne pas correspondre et vous ne devez pas utiliser enforce. |
max_age: | Durée pendant laquelle un expéditeur peut mémoriser la politique, en secondes. 604800 correspond à une semaine. |
Un expéditeur mémorise la politique. MTA-STS ne protège donc pas lors de la toute première fois qu'un expéditeur vous envoie un e-mail, mais bien par la suite.
TLS-RPT : des rapports sur le chiffrement
Avec TLS-RPT, vous demandez aux expéditeurs un rapport quotidien sur les échecs de chiffrement, par exemple en raison d'un certificat expiré ou d'un nom de serveur de messagerie qui ne figure pas dans votre politique. Il s'agit d'un seul enregistrement TXT sur le nom _smtp._tls :
_smtp._tls.jouwdomein.nl. TXT "v=TLSRPTv1; rua=mailto:tlsrapport@jouwdomein.nl"
Les rapports sont des fichiers techniques (JSON). Utilisez, comme pour les rapports DMARC, une boîte mail distincte. Voir Lire un rapport DMARC.
L'ordre à suivre : d'abord TLS-RPT, puis MTA-STS en testing, lire les rapports pendant quelques semaines, et seulement ensuite passer en enforce.
MTA-STS ou DANE ?
DANE fait la même chose d'une autre manière : l'empreinte du certificat de votre serveur de messagerie est inscrite dans le DNS (un enregistrement TLSA), sécurisée par DNSSEC. DANE protège également la toute première connexion, mais ne fonctionne que si DNSSEC est activé. MTA-STS n'a pas besoin de DNSSEC, mais nécessite un site web avec un certificat. Vous pouvez utiliser les deux en parallèle ; un expéditeur qui prend en charge DANE donnera alors la priorité à DANE.
Si votre messagerie est hébergée chez WebOké, vous pouvez activer DANE dans Mon WebOké, au même endroit que DNSSEC. WebOké gère ensuite lui-même les enregistrements TLSA. Lisez DNSSEC et DANE et Checklist Internet.nl : obtenir 100% pour votre site web et votre messagerie.
En avez-vous besoin ?
Pour la plupart des clients, non. Les e-mails entre grands serveurs de messagerie sont aujourd'hui presque toujours chiffrés, et si vous souhaitez protéger davantage votre messagerie chez WebOké, DANE est l'étape la plus simple. MTA-STS est surtout utile si votre organisation l'impose, ou si vous attendez des destinataires utilisant MTA-STS mais pas DANE. Pour vos propres e-mails sortants, vous n'avez rien à configurer : c'est le serveur qui envoie votre e-mail qui s'en charge.
Configurer vous-même avec un pack d'hébergement
Les deux enregistrements TXT se configurent dans Gestion DNS dans DirectAdmin ou dans l'onglet DNS de Mon WebOké. Voir Gérer les enregistrements DNS dans Mon WebOké (avec exemples pour CNAME, TXT et services externes).
Le fichier de politique doit se trouver sur le sous-domaine mta-sts. Dans votre pack, vous pouvez créer ce sous-domaine dans Gestion des sous-domaines ; DirectAdmin demandera alors automatiquement un certificat SSL pour celui-ci. Voir Créer et supprimer des sous-domaines et Certificat pour www, sous-domaines et wildcard. Dans le dossier du sous-domaine, créez un dossier .well-known contenant le fichier mta-sts.txt.
enforce à la légère. Si un nom de serveur de messagerie est incorrect, ou si le certificat du serveur de messagerie ne correspond pas à ce nom, les expéditeurs qui respectent MTA-STS ne pourront plus vous envoyer d'e-mails. Le fichier de politique doit en outre être accessible directement : les expéditeurs ne suivent pas de redirection vers une autre adresse. Commencez par testing, lisez les rapports TLS-RPT, et contactez-nous d'abord en cas de doute.Documentation technique : RFC 8461 (MTA-STS) et RFC 8460 (TLS-RPT).