Aller au contenu

Le chiffrement des e-mails qui vous sont envoyés peut être désactivé à votre insu

Avertissement Tout le domaine Délivrabilité des e-mails

Instructions générales. Ouvrez cet article depuis votre rapport PageCheck pour le voir rempli avec les serveurs de messagerie de votre domaine et les étapes exactes de votre hébergeur DNS.

De quoi s’agit-il

Les e-mails entre serveurs sont en général chiffrés, mais seulement si les deux côtés s’accordent en chemin, et un attaquant placé entre les deux peut supprimer cette offre : l’e-mail est alors livré en clair sans que personne ne s’en aperçoive. MTA-STS est une petite politique publique qui indique aux serveurs expéditeurs que vos serveurs de messagerie prennent toujours en charge le chiffrement, et qu’ils ne doivent donc pas livrer sans lui.

Ce qui ne va pas

example.com n’a pas de politique MTA-STS : le chiffrement des e-mails qui lui sont envoyés peut être désactivé discrètement. Sa politique DMARC bloque déjà les e-mails falsifiés en son nom ; c’est l’étape suivante.

Comment corriger

Commencez en mode testing : les serveurs expéditeurs se contentent alors de signaler les problèmes et livrent toujours chaque message, rien ne peut donc mal tourner pendant que vous vérifiez la configuration.

1. Écrire le fichier de politique. Enregistrez ceci dans un fichier texte brut nommé mta-sts.txt. Il doit citer chaque serveur de messagerie (MX) du domaine :

mta-sts.txt

version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400

2. Le publier à sa propre adresse. Le fichier doit s’ouvrir à l’adresse https://mta-sts.example.com/.well-known/mta-sts.txt en HTTPS, avec un certificat valide et sans aucune redirection – une redirection vers www ou vers le site principal le fait ignorer par les expéditeurs.

Si votre DNS est chez Cloudflare, le plus simple est un Cloudflare Worker (gratuit) : Workers & Pages → Create → Create Worker, nommez-le mta-sts, remplacez son code par le code ci-dessous et cliquez sur Deploy. Puis dans les Settings du Worker → Domains & Routes → Add → Custom domain : mta-sts.example.com. Cloudflare crée l’enregistrement DNS et le certificat correspondants.

Cloudflare Worker

export default {
  async fetch() {
    const policy = [
      'version: STSv1',
      'mode: testing',
      'mx: mail.example.com',
      'max_age: 86400',
    ].join('\r\n') + '\r\n';
    return new Response(policy, { headers: { 'content-type': 'text/plain; charset=utf-8' } });
  },
};

Chez votre hébergeur web : ajoutez le sous-domaine mta-sts.example.com avec un certificat SSL, créez-y un dossier nommé .well-known et déposez-y mta-sts.txt.

  • Plesk : Websites & Domains → Add Subdomain, puis SSL/TLS Certificates → Let's Encrypt, puis File Manager.
  • cPanel : Domains → Create A New Domain, puis SSL/TLS Status → Run AutoSSL, puis File Manager.

3. Annoncer la politique dans le DNS.

  • Ouvrez les enregistrements DNS de votre domaine là où son DNS est géré : en général chez le registraire du domaine, l’hébergeur du site ou Cloudflare.
  • Ajoutez un enregistrement TXT avec le nom _mta-sts et la valeur v=STSv1; id=1, puis enregistrez.

4. Demander des rapports. Les serveurs expéditeurs envoient alors chaque jour par e-mail un rapport de toute livraison chiffrée qui a échoué. Créez d’abord la boîte tls-reports@example.com (ou utilisez une autre adresse que vous lisez).

  • Ouvrez les enregistrements DNS de votre domaine là où son DNS est géré : en général chez le registraire du domaine, l’hébergeur du site ou Cloudflare.
  • Ajoutez un enregistrement TXT avec le nom _smtp._tls et la valeur v=TLSRPTv1; rua=mailto:tls-reports@example.com, puis enregistrez.

5. Vérifier. Ouvrez https://mta-sts.example.com/.well-known/mta-sts.txt : le fichier doit s’afficher en texte brut. Relancez ensuite ce contrôle : il lit le fichier et compare ses lignes mx avec vos serveurs de messagerie.

6. Environ deux semaines plus tard : l’appliquer. Quand les rapports ne montrent aucune livraison échouée, passez le fichier en mode enforce avec un max_age d’une semaine :

mta-sts.txt

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

Modifiez ensuite l’enregistrement TXT _mta-sts en v=STSv1; id=2, pour que les expéditeurs récupèrent le nouveau fichier. Chaque modification ultérieure du fichier demande un nouvel id, et quand vos serveurs de messagerie changent, mettez d’abord à jour les lignes mx. 

Set up MTA-STS (RFC 8461) for the mail domain example.com, starting in testing mode, and TLS-RPT (RFC 8460) reporting.
Its MX hosts (look them up first; this is a placeholder): mail.example.com.

Steps:
1. Serve this policy at https://mta-sts.example.com/.well-known/mta-sts.txt over HTTPS with a valid certificate for mta-sts.example.com, status 200, Content-Type text/plain, no redirect:
   version: STSv1
   mode: testing
   mx: mail.example.com
   max_age: 86400
   Use the web host (a subdomain with its own certificate) or a static host.
2. Add the TXT record _mta-sts.example.com = "v=STSv1; id=1".
3. Add the TXT record _smtp._tls.example.com = "v=TLSRPTv1; rua=mailto:tls-reports@example.com" (make sure that mailbox exists).
4. Verify: curl -sv https://mta-sts.example.com/.well-known/mta-sts.txt (200, no redirect, the policy text) and dig TXT _mta-sts.example.com +short.
5. Tell me to come back in two weeks: if the TLS reports show no failures, switch to mode: enforce with max_age: 604800 and change the TXT record to "v=STSv1; id=2".
Every mx line must match an MX host exactly or by a one-label wildcard (*.example.com); a missing one makes enforcing senders refuse mail.

Resources:
- MTA-STS, RFC 8461 (IETF): https://datatracker.ietf.org/doc/html/rfc8461
- TLS-RPT, RFC 8460 (IETF): https://datatracker.ietf.org/doc/html/rfc8460

Analysez votre site pour savoir s’il a ce problème. Analyser un site