Cette chronologie présente les RFC structurantes du protocole. Elle ne cherche pas à répertorier chaque extension spécialisée.
Du protocole original à ESMTP
Le dialogue SMTP est stabilisé, puis rendu extensible sans casser les serveurs existants.
RFC 821
Simple Mail Transfer Protocol
Établit le modèle de relais de courrier, les commandes HELO, MAIL, RCPT, DATA et QUIT, ainsi que les réponses numériques à trois chiffres.
Consulter le texte officielRFC 1869
SMTP Service Extensions
Crée ESMTP et la commande EHLO. Un serveur peut désormais annoncer ses capacités et accepter des paramètres d’extension sans modifier le cœur du dialogue SMTP.
Consulter le texte officielRFC 2821
Simple Mail Transfer Protocol
Réunit SMTP et son mécanisme d’extensions, clarifie le routage par enregistrements MX, les files d’attente, les délais et les règles de relais sur l’Internet moderne.
Consulter le texte officielRFC 5321
Simple Mail Transfer Protocol
Consolide et corrige la RFC 2821, retire plusieurs pratiques obsolètes et précise les responsabilités des agents de transport, des relais et des passerelles.
Consulter le texte officielRFC 7504
SMTP 521 and 556 Reply Codes
Ajoute des réponses explicites pour indiquer qu’un domaine n’accepte aucun courrier ou qu’un destinataire appartient à un domaine sans service SMTP, notamment avec un enregistrement Null MX.
Consulter le texte officiel
Soumission, identité et internationalisation
Le transport entre serveurs est séparé de la soumission par les utilisateurs et enrichi de mécanismes d’authentification.
RFC 4954
SMTP Service Extension for Authentication
Normalise l’extension AUTH basée sur SASL. Un client peut prouver son identité au serveur de soumission avant d’envoyer un message.
Consulter le texte officielRFC 6409
Message Submission for Mail
Distingue la soumission par un client du relais entre serveurs, réserve le port 587 et autorise le serveur de soumission à corriger ou compléter le message avant transport.
Consulter le texte officielRFC 6531
SMTP Extension for Internationalized Email
Ajoute SMTPUTF8 afin de transporter des adresses et en-têtes contenant des caractères Unicode, avec annonce explicite de la capacité par le serveur.
Consulter le texte officiel
Chiffrement et politiques de transport
TLS passe d’une option opportuniste à une exigence explicite dans plusieurs scénarios.
RFC 3207
SMTP Service Extension for Secure SMTP over TLS
Définit STARTTLS pour transformer une connexion SMTP existante en canal TLS. Après la négociation, les capacités doivent être annoncées de nouveau.
Consulter le texte officielRFC 8314
Cleartext Considered Obsolete
Recommande TLS pour la soumission et l’accès au courrier, privilégie le TLS implicite sur les ports dédiés et considère les connexions en clair comme obsolètes.
Consulter le texte officielRFC 8461
SMTP MTA Strict Transport Security (MTA-STS)
Permet à un domaine de publier une politique HTTPS exigeant TLS et des certificats valides pour la livraison SMTP, afin de limiter le downgrade et l’interception.
Consulter le texte officielRFC 8689
SMTP Require TLS Option
Ajoute le paramètre REQUIRETLS : l’expéditeur peut demander que chaque relais conserve une protection TLS ou échoue au lieu de livrer sans garantie suffisante.
Consulter le texte officiel
Lecture de l’évolution
SMTP conserve volontairement son dialogue historique. Son évolution se fait par extensions annoncées après EHLO, ce qui permet aux anciens et nouveaux serveurs d’interopérer tout en ajoutant sécurité, internationalisation et politiques de livraison.