RFC 3207 – Extension SMTP STARTTLS

Norme proposée Sécurité des transports Obsoletes RFC 2487 Published March 2026

ELI5: Imaginez que vous ayez une conversation dans une salle bondée. N'importe qui peut vous écouter. STARTTLS, c'est comme dire « allons discuter dans une salle privée » au milieu de la conversation. Vous commencez la session SMTP en texte clair, puis les deux côtés s'accordent à passer à une communication chiffrée avant l'échange de contenu sensible. Après cela, personne ne peut écouter furtivement le courrier électronique transféré.

Pourquoi cette RFC existe

Lorsque le SMTP a été conçu en 1982, le chiffrement n'était pas une considération. Les messages voyageaient sur Internet en texte clair, et quiconque ayant accès au chemin réseau pouvait les lire. À mesure qu'Internet est devenu plus hostile, le chiffrement des emails en transit est devenu essentiel.

La RFC 3207 définit l'extension STARTTLS pour SMTP, permettant à une connexion SMTP en texte clair d'être mise à niveau vers une connexion TLS chiffrée. Publiée en 2002, elle a remplacé la RFC 2487 avec des clarifications sur les considérations de sécurité et le comportement du serveur.

STARTTLS est le mécanisme dominant pour chiffrer le trafic email serveur-à-serveur (MTA-à-MTA) sur le port 25. Pour la soumission client-à-serveur, la RFC 8314 recommande désormais le TLS implicite sur le port 465, mais STARTTLS sur le port 587 reste largement utilisé.

Comment cela fonctionne

STARTTLS fonctionne comme une extension SMTP, négociée lors de l'échange EHLO :

Le client se connecte au serveur sur le port 25 (ou 587) en texte clair.
Le client envoie EHLO. Le serveur répond avec ses capacités, incluant 250-STARTTLS s'il prend en charge le chiffrement.
Le client envoie STARTTLS.
Le serveur répond avec 220 Ready to start TLS.
Les deux parties effectuent une poignée de main TLS, établissant un canal chiffré.
Le client envoie un nouveau EHLO sur la connexion chiffrée. La liste des capacités du serveur peut changer (par exemple, AUTH est maintenant annoncée).
La session SMTP se poursuit normalement, mais tout le trafic est désormais chiffré.

Exemple SMTP

Négociation STARTTLS lors d'un transfert serveur-à-serveur :

# Connexion en texte clair établie sur le port 25 S: 220 mx.example.com ESMTP C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-STARTTLS S: 250 ENHANCEDSTATUSCODES # Le client voit que STARTTLS est disponible, demande une mise à niveau C: STARTTLS S: 220 2.0.0 Ready to start TLS # --- La poignée de main TLS se produit ici --- # Tout le trafic ultérieur est chiffré # Le client DOIT ré-émettre EHLO après TLS C: EHLO sender.example.net S: 250-mx.example.com S: 250-SIZE 52428800 S: 250-AUTH PLAIN LOGIN S: 250 ENHANCEDSTATUSCODES # Note : STARTTLS n'est plus annoncée (déjà active) # Note : AUTH est maintenant annoncée (disponible uniquement après TLS) C: MAIL FROM:<alice@sender.example.net> S: 250 2.1.0 OK C: RCPT TO:<bob@example.com> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: [contenu du message...] C: . S: 250 2.0.0 OK

Détails techniques clés

TLS opportuniste vs obligatoire

La limitation critique de STARTTLS tel que défini dans la RFC 3207 est qu'il est opportuniste par défaut :

TLS opportuniste : Le client tente STARTTLS si le serveur l'annonce, mais revient à du texte clair s'il n'est pas disponible ou si la poignée de main TLS échoue. C'est le comportement par défaut pour les connexions MTA-à-MTA.
TLS obligatoire : Le client refuse d'envoyer le message à moins que TLS puisse être établi. Cela peut être configuré par domaine ou appliqué à l'aide de MTA-STS (RFC 8461) ou DANE (RFC 7672).

Le TLS opportuniste est vulnérable aux attaques par rétrogradation : un attaquant réseau peut supprimer la capacité STARTTLS de la réponse EHLO, forçant la connexion à rester en texte clair. Le client n'a aucun moyen de savoir que le serveur prend en charge TLS car la négociation initiale se produit en texte clair.

Vérification du certificat

La RFC 3207 ne nécessite pas une vérification stricte du certificat pour les connexions MTA-à-MTA. En pratique, de nombreux serveurs utilisent des certificats auto-signés ou des certificats qui ne correspondent pas au nom d'hôte MX. La justification : le chiffrement opportuniste sans vérification est toujours mieux que aucun chiffrement. Il protège contre la surveillance passive même s'il n'empêche pas les attaques actives de l'homme du milieu.

Pour des garanties plus fortes, utilisez :

DANE (RFC 7672) — publie le certificat TLS du serveur dans DNS via les enregistrements TLSA, sécurisé par DNSSEC.
MTA-STS (RFC 8461) — publie une politique nécessitant TLS avec validation de certificat, mise en cache par les serveurs d'envoi.

Re-EHLO après STARTTLS

Après la fin de la poignée de main TLS, le client DOIT émettre une nouvelle commande EHLO. La liste des capacités du serveur d'avant TLS doit être abandonnée. C'est important car :

Le serveur peut annoncer différentes capacités après l'établissement du chiffrement (par exemple, AUTH).
Le serveur ne doit plus annoncer STARTTLS puisque le chiffrement est déjà actif.
Un attaquant aurait pu modifier la réponse EHLO avant TLS.

STARTTLS sur différents ports

Port	Protocole	Comportement TLS
25	Relais SMTP	STARTTLS (opportuniste pour MTA-à-MTA)
587	Soumission	STARTTLS (effectivement obligatoire — AUTH le nécessite)
465	Soumission	TLS implicite (poignée de main TLS avant toute commande SMTP)

Rapport TLS

La RFC 8460 définit le rapport SMTP TLS (TLSRPT), qui permet aux propriétaires de domaine de recevoir des rapports sur les échecs de connexion TLS. C'est l'équivalent STARTTLS des rapports agrégés DMARC — cela vous indique quand les connexions à vos serveurs échouent la négociation TLS.

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"

Erreurs courantes

Supposer que STARTTLS signifie que le message est chiffré de bout en bout. STARTTLS chiffre uniquement la connexion entre deux serveurs adjacents. Si un message passe par plusieurs sauts, chaque saut négocie TLS indépendamment. Un message pourrait être chiffré pour un saut et en texte clair pour le suivant.
Ne pas ré-émettre EHLO après STARTTLS. Ne pas envoyer un nouveau EHLO après la poignée de main TLS est une violation du protocole. Vous travaillerez avec des données de capacité obsolètes et pourriez manquer des fonctionnalités nouvellement disponibles comme AUTH.
Traiter l'échec de STARTTLS comme une erreur permanente. Si la négociation STARTTLS échoue, la connexion est dans un état indéfini. Fermez la connexion et en démarrez une nouvelle. N'essayez pas de continuer en texte clair sur la même connexion.
Annoncer STARTTLS mais en utilisant un certificat expiré ou mal configuré. Bien que de nombreux clients procèderont malgré les erreurs de certificat, certains clients de plus en plus stricts (et les politiques MTA-STS/DANE) refuseront. Gardez vos certificats TLS valides et correctement configurés.
S'appuyer uniquement sur STARTTLS pour la sécurité. Parce que STARTTLS est opportuniste et vulnérable aux attaques par rétrogradation, il doit être complété par MTA-STS ou DANE pour les domaines où le chiffrement est critique.
Oublier STARTTLS sur le port 587. Pour la soumission, les clients doivent toujours STARTTLS avant authentification. Envoyer les identifiants AUTH en texte clair expose votre mot de passe SMTP à quiconque surveille la connexion.

Impact sur la délivrabilité

Google et les principaux fournisseurs signalent les emails non chiffrés. Gmail affiche une icône de cadenas rouge ouvert pour les messages reçus sans chiffrement TLS. Cela signale aux destinataires que le message a peut-être été intercepté en transit, réduisant la confiance.
L'adoption de TLS est quasi universelle. En 2025, plus de 95 % des emails envoyés à Gmail sont chiffrés avec TLS. Ne pas prendre en charge STARTTLS sur votre infrastructure d'envoi vous rend hors de la norme et peut affecter négativement votre réputation d'expéditeur.
L'application de MTA-STS augmente. Les principaux fournisseurs publient des politiques MTA-STS qui nécessitent TLS avec validation de certificat. Si votre serveur d'envoi ne peut pas négocier avec succès TLS avec un certificat valide, la livraison à ces domaines échouera.
Le rapport TLS expose les problèmes. Si vous publiez un enregistrement TLSRPT et que votre serveur a des problèmes TLS, vous recevrez des rapports. Si vous ne publiez pas TLSRPT, vous naviguez à l'aveugle concernant les échecs de connexion.
Exigences de conformité. HIPAA, GDPR, PCI-DSS et autres réglementations exigent de plus en plus le chiffrement en transit pour les emails. STARTTLS est le mécanisme de base qui satisfait cette exigence pour les emails serveur-à-serveur.