← RFC Reference

RFC 8314 : Le texte en clair considéré comme obsolète

Pourquoi cela existe

L'email a historiquement utilisé trois ports en texte clair pour la communication client-serveur :

Les quatre commencent comme des connexions en texte clair. STARTTLS a été ajouté pour mettre à niveau ces connexions vers TLS en milieu de flux. Mais STARTTLS présente des faiblesses systémiques :

• Attaques de rétrogradation. Un attaquant peut supprimer la capacité STARTTLS de la réponse du serveur, et de nombreux clients reviendront silencieusement au texte clair.
• Injection de commande pré-TLS. La phase en texte clair avant la fin de STARTTLS permet à un attaquant d'injecter des commandes SMTP que le serveur traite après la négociation TLS.
• Exposition des identifiants. Si STARTTLS échoue ou est supprimé, le client peut envoyer les identifiants AUTH (nom d'utilisateur et mot de passe) en texte clair.

RFC 8314 déclare ces connexions en texte clair obsolètes pour la soumission d'email et l'accès à la boîte aux lettres, et mandate le TLS implicite comme remplacement.

Comment cela fonctionne

TLS implicite vs STARTTLS

STARTTLS (l'ancienne façon) : Se connecter sur un port en texte clair, échanger des salutations en texte brut, envoyer une commande STARTTLS, négocier TLS, puis poursuivre la session chiffrée.

-- STARTTLS sur le port 587 (submission) --
220 mail.example.com ESMTP          ← salutation en texte clair
EHLO client.example.com             ← texte clair
250-mail.example.com                ← texte clair
250-STARTTLS                        ← l'attaquant peut supprimer cette ligne
250 OK
STARTTLS                            ← texte clair
220 Go ahead                        ← texte clair
-- La négociation TLS se produit ici --
EHLO client.example.com             ← maintenant chiffré
AUTH PLAIN dXNlcjpwYXNz            ← chiffré (sûr)

TLS implicite (la façon RFC 8314) : Se connecter à un port TLS dédié. La négociation TLS est la première chose qui se produit. Pas de phase en texte clair du tout.

-- TLS implicite sur le port 465 (submissions) --
-- La négociation TLS se produit immédiatement à la connexion --
220 mail.example.com ESMTP          ← chiffré dès le premier octet
EHLO client.example.com             ← chiffré
AUTH PLAIN dXNlcjpwYXNz            ← chiffré

Les nouvelles assignations de port

Le port 465 a un historique compliqué. Il a d'abord été assigné pour « SMTPS » à la fin des années 1990, puis révoqué au profit de STARTTLS sur 587. RFC 8314 le réattribue comme submissions (notez le 's') pour la soumission TLS implicite. Cette fois, c'est officiel et permanent.

Et le port 25 ?

Le port 25 est pour le relais serveur à serveur, pas la soumission client. RFC 8314 ne change pas le comportement du port 25. Le SMTP serveur à serveur utilise toujours STARTTLS opportuniste, avec MTA-STS ou DANE fournissant l'application. La distinction est importante : les clients s'authentifient avec des identifiants (qui doivent être protégés), tandis que les serveurs s'authentifient via DNS, DKIM et SPF.

Détails techniques clés

Exigences de version TLS

RFC 8314 nécessite TLS 1.2 ou ultérieur. TLS 1.0 et 1.1 sont déconseillés par RFC 8996. En pratique, vous devriez exiger TLS 1.2 au minimum et préférer TLS 1.3.

Validation du certificat

Avec le TLS implicite, les clients doivent valider le certificat du serveur par rapport au nom d'hôte attendu en utilisant les règles Web PKI standard. Cela représente un changement important par rapport à l'ère STARTTLS où de nombreux clients acceptaient n'importe quel certificat. Le certificat doit :

• Être émis par une autorité de certification de confiance.
• Correspondre au nom d'hôte du serveur (le nom auquel le client se connecte, pas nécessairement le nom d'hôte MX).
• Ne pas être expiré ou révoqué.

Enregistrements SRV pour la découverte de service

RFC 8314 fonctionne aux côtés de RFC 6186 pour la configuration client automatique via les enregistrements SRV :

Configuration client

Pour les développeurs d'applications intégrant la soumission SMTP :

# Exemple Python : TLS implicite sur le port 465
import smtplib

# Correct : SMTP_SSL se connecte avec TLS immédiatement
with smtplib.SMTP_SSL('mail.example.com', 465) as smtp:
    smtp.login('user', 'password')
    smtp.send_message(msg)

# À éviter : STARTTLS sur le port 587 (héritage)
# with smtplib.SMTP('mail.example.com', 587) as smtp:
#     smtp.starttls()
#     smtp.login('user', 'password')

Erreurs courantes

• Confondre le port 465 avec le port 25. Le port 465 est pour la soumission client avec TLS implicite. Le port 25 est pour le relais serveur à serveur. N'utilisez jamais le port 465 pour la livraison MX.
• Toujours offrir du texte clair sur le port 587 sans application de STARTTLS. Si vous devez supporter le port 587, exigez STARTTLS avant AUTH. N'autorisez jamais les identifiants sur une connexion en texte clair.
• Désactiver la vérification du certificat. Le TLS implicite nécessite une validation appropriée du certificat. Définir verify=False ou équivalent annule complètement le but. Corrigez plutôt le certificat.
• Utiliser TLS 1.0 ou 1.1. Ces derniers sont officiellement déconseillés. Configurez votre serveur pour n'accepter que TLS 1.2+ .
• Traiter le port 465 comme « SMTPS » (la version des années 1990). L'ancien SMTPS a été révoqué. Le port 465 est maintenant submissions selon RFC 8314 — le même comportement sous-jacent (TLS implicite), mais officiellement standardisé avec une enregistrement IANA appropriée.
• Ne pas publier d'enregistrements SRV. Sans enregistrements SRV _submissions._tcp, les clients ne peuvent pas découvrir automatiquement votre point de terminaison TLS implicite. Beaucoup optent toujours par défaut pour STARTTLS sur 587.

Impact sur la livraison

• Protège les identifiants de l'expéditeur. Pour les applications utilisant la soumission SMTP (votre application se connectant à Mailer To Go, par exemple), le TLS implicite sur le port 465 garantit que vos identifiants API ne traversent jamais le réseau en texte clair — pas même brièvement lors d'une mise à niveau STARTTLS.
• Établissement de connexion plus rapide. Le TLS implicite économise un aller-retour par rapport à STARTTLS (aucun échange EHLO en texte clair + STARTTLS). Pour les expéditeurs à haut volume, cela s'accumule.
• Requis par les principaux fournisseurs. Google Workspace et Microsoft 365 supportent tous deux le TLS implicite sur le port 465. C'est la méthode de soumission recommandée pour les nouvelles intégrations.
• Élimine une classe d'attaques. L'effondrement STARTTLS, l'injection de commandes et l'interception d'identifiants sont tous impossibles avec le TLS implicite. Pour les environnements sensibles à la conformité, cela importe.

Related RFCs