RFC 8689 : Option SMTP Require TLS

Piste normalisée Sécurité des transports Published March 2026

ELI5: Le chiffrement e-mail normal, c'est comme demander à un coursier « s'il te plaît, utilise le camion blindé s'il est disponible ». Si le camion blindé est occupé, le coursier hausse les épaules et utilise une camionnette ordinaire. REQUIRETLS est un timbre sur l'enveloppe qui dit « camion blindé ou ne le livre pas du tout ». Le message préférerait rebondir plutôt que de voyager non chiffré.

Pourquoi cela existe

Le chiffrement du courrier électronique serveur à serveur (via STARTTLS) est opportuniste par défaut. Si le serveur destinataire ne supporte pas TLS, ou si un intermédiaire supprime la capacité STARTTLS, la plupart des serveurs d'envoi basculeront vers une livraison en texte clair. Le message est livré, mais sans chiffrement.

Les technologies comme MTA-STS et DANE abordent cela au niveau du domaine — elles permettent à un domaine destinataire de déclarer « tout courrier vers nous doit utiliser TLS ». Mais ce sont des politiques côté destinataire. L'expéditeur n'avait aucun moyen de dire « ce message spécifique nécessite TLS à chaque saut ».

RFC 8689 comble cette lacune avec deux mécanismes complémentaires :

L'extension SMTP REQUIRETLS : Un drapeau par message dans l'enveloppe SMTP qui indique à chaque serveur relais « ne livrez pas ce message à moins que le prochain saut ne supporte TLS avec certificats vérifiés ».
L'en-tête TLS-Required : Un en-tête de message qui signale la même intention, utilisable quand l'expéditeur n'a pas de contrôle direct sur l'enveloppe SMTP (par exemple, lors de la soumission via un MSA).

Comment cela fonctionne

L'extension SMTP REQUIRETLS

L'expéditeur annonce son intention lors de la transaction SMTP en ajoutant REQUIRETLS comme paramètre de la commande MAIL FROM :

# Le serveur annonce le support REQUIRETLS dans EHLO S: 220 mx.example.com ESMTP C: EHLO sender.example.org S: 250-mx.example.com S: 250-STARTTLS S: 250-REQUIRETLS S: 250 OK # Passer à TLS en premier C: STARTTLS S: 220 Go ahead # ... Handshake TLS avec vérification de certificat ... C: EHLO sender.example.org S: 250-mx.example.com S: 250-REQUIRETLS S: 250 OK # Soumettre avec le drapeau REQUIRETLS C: MAIL FROM:<alice@example.org> REQUIRETLS S: 250 OK C: RCPT TO:<bob@example.com> S: 250 OK

Ce qui se passe à chaque saut

Quand un serveur relais traite un message avec le drapeau REQUIRETLS, il doit appliquer ces règles avant de relayer :

TLS est obligatoire. La connexion au prochain saut doit utiliser TLS. Si le serveur suivant ne supporte pas STARTTLS, le message ne doit pas être livré — il revient.
La vérification du certificat est requise. Le certificat TLS du prochain saut doit être valide et correspondre au nom d'hôte du serveur (via DANE/TLSA ou Web PKI). Les certificats auto-signés ou mal appairés causent un retour.
Le drapeau REQUIRETLS se propage. Le relais doit passer le paramètre REQUIRETLS au prochain saut s'il supporte aussi l'extension. Si le prochain saut ne supporte pas REQUIRETLS, le relais peut quand même livrer s'il peut vérifier TLS via DANE ou MTA-STS.

L'en-tête TLS-Required

Pour les expéditeurs qui soumettent via un MSA et ne contrôlent pas directement les paramètres SMTP, l'en-tête TLS-Required fournit le même signal :

TLS-Required: No ; Attendre — « Non » signifie « ne pas exiger TLS » ? ; C'est exact. L'en-tête a deux valeurs : ; TLS-Required: No → explicitement refuser REQUIRETLS ; (utiliser TLS opportuniste normal) ; L'absence de l'en-tête signifie un comportement normal. ; Le drapeau d'enveloppe REQUIRETLS est le signal positif.

L'en-tête TLS-Required: No est spécifiquement conçu comme un mécanisme de refus. Il indique au MTA d'envoi : « même si REQUIRETLS s'appliquerait normalement à ce message (par exemple, à cause d'une politique à l'échelle du domaine), ne l'appliquez pas à ce message particulier ». C'est utile pour des messages comme les réinitialisations de mot de passe ou les notifications où la livraison est plus importante que le chiffrement garanti.

Comportement des retours

Quand REQUIRETLS empêche la livraison, le serveur d'envoi génère un rapport de non-livraison (retour). Le retour lui-même doit aussi être envoyé sur TLS — REQUIRETLS s'applique aussi aux messages DSN (Delivery Status Notification). Si le retour ne peut pas être livré de manière sécurisée, il est silencieusement supprimé plutôt que d'être envoyé en texte clair (pour éviter de fuir des informations sur le message original).

# Le prochain saut ne supporte pas TLS — REQUIRETLS empêche la livraison C: EHLO relay.example.org S: 250-mx.recipient.com S: 250 OK # Pas de STARTTLS annoncé — impossible de livrer avec REQUIRETLS # Le relais génère un retour vers alice@example.org : # 550 5.7.30 REQUIRETLS support required but not available

Détails techniques clés

Relation avec MTA-STS et DANE

Mécanisme	Qui définit la politique	Étendue	Méthode de vérification
MTA-STS	Domaine destinataire	Tout courrier vers le domaine	Web PKI (récupération HTTPS)
DANE	Domaine destinataire	Tout courrier vers le domaine	DNSSEC + enregistrements TLSA
REQUIRETLS	Serveur d'envoi/utilisateur	Par message	DANE ou MTA-STS à chaque saut

REQUIRETLS est complémentaire, pas concurrent. MTA-STS et DANE protègent le courrier entrant du domaine destinataire. REQUIRETLS protège un message sortant spécifique. Un message avec REQUIRETLS est validé en utilisant DANE ou MTA-STS à chaque saut — si ni l'un ni l'autre n'est disponible pour un saut, la livraison échoue.

Exigences de version TLS

REQUIRETLS nécessite TLS 1.2 ou ultérieur. Les connexions utilisant TLS 1.0 ou 1.1 ne satisfont pas l'exigence, conformément à RFC 8996 qui déprécie les anciennes versions de TLS.

Codes d'état améliorés

Code	Signification
`5.7.30`	Support REQUIRETLS requis mais non disponible au prochain saut
`5.7.31`	REQUIRETLS ne peut pas être honoré (par exemple, certificat du prochain saut invalide)

Erreurs courantes

Supposer que REQUIRETLS est largement déployé. L'adoption est encore limitée. La plupart des MTA ne supportent pas encore l'extension REQUIRETLS. L'utiliser pour tout courrier entraînera des retours vers de nombreux destinataires.
Confondre REQUIRETLS avec STARTTLS. STARTTLS est le mécanisme pour mettre à niveau une connexion vers TLS. REQUIRETLS est une politique qui oblige STARTTLS à réussir et les certificats à être validés. STARTTLS sans REQUIRETLS est opportuniste ; REQUIRETLS le rend obligatoire.
S'attendre à un chiffrement de bout en bout. REQUIRETLS assure TLS à chaque saut, mais le message est déchiffré et rechiffré à chaque serveur relais. C'est du chiffrement saut par saut, pas de bout en bout. Pour un vrai chiffrement de bout en bout, utilisez S/MIME ou PGP.
Ne pas gérer les retours. REQUIRETLS provoquera des échecs de livraison légitimes quand le serveur du destinataire ne supporte pas TLS ou a des problèmes de certificat. Votre application doit gérer ces retours et potentiellement réessayer sans REQUIRETLS ou notifier l'utilisateur.
Utiliser TLS-Required: Yes. Il n'y a pas de valeur TLS-Required: Yes. L'en-tête n'a qu'une valeur No pour le refus. Le signal positif est le paramètre SMTP REQUIRETLS, pas une valeur d'en-tête.
Oublier les retours. REQUIRETLS s'applique aussi aux messages DSN. Si le retour ne peut pas être livré sur TLS, il est silencieusement supprimé. L'expéditeur original ne saura peut-être jamais que la livraison a échoué.

Impact sur la livraison

Réduit le taux de livraison. Activer REQUIRETLS pour tous les messages causera des échecs de livraison vers les serveurs qui ne supportent pas TLS ou ont des problèmes de certificat. Utilisez-le sélectivement pour les messages où la sécurité prime sur la certitude de livraison.
Protège les messages de haute valeur. Pour les notifications financières, documents juridiques, données de santé, ou tout message soumis à la conformité réglementaire, REQUIRETLS assure que le message n'est jamais transmis en texte clair.
Complète MTA-STS. Si votre domaine publie MTA-STS et les domaines de vos destinataires ont aussi MTA-STS ou DANE, REQUIRETLS ajoute une assurance par message en plus des politiques au niveau du domaine. La combinaison fournit la meilleure sécurité de transport disponible dans SMTP.
Les messages de retour sont aussi protégés. Parce que REQUIRETLS s'applique aux DSN, les informations sensibles dans les messages de retour (qui peuvent inclure des parties du message original) sont aussi protégées de la transmission en texte clair.