RFC 1869 – Extensions de service SMTP (ESMTP)

Norme Internet SMTP et Format de Message Published March 2026

ELI5: SMTP original ressemblait à deux personnes qui ne pouvaient parler qu'un anglais basique. ESMTP ressemble à commencer une conversation en disant « Je parle aussi le français, l'allemand et le japonais — et toi ? » La commande EHLO a remplacé HELO et permet aux deux côtés de découvrir quelles fonctionnalités supplémentaires ils partagent avant de commencer à échanger du courrier. Chaque fonctionnalité SMTP moderne — authentification, chiffrement, limites de taille — repose sur ce mécanisme de négociation.

Pourquoi cette RFC existe

Le protocole SMTP d'origine (RFC 821, 1982) n'avait aucun mécanisme pour ajouter de nouvelles fonctionnalités. Il n'y avait aucun moyen pour un client de découvrir ce qu'un serveur supportait, et aucun moyen pour un serveur d'annoncer ses capacités. Chaque extension nécessitait une nouvelle version de protocole incompatible.

La RFC 1869, publiée en 1995, a résolu ce problème en définissant un cadre générique pour les extensions SMTP. Elle a introduit la commande EHLO (Extended HELLO) en remplacement de HELO. Quand un client envoie EHLO, le serveur répond avec une liste des extensions qu'il supporte. Le client peut alors utiliser toutes les extensions que les deux côtés comprennent.

Ce cadre est tellement fondamental qu'il a été intégré directement dans la spécification SMTP de base dans la RFC 5321. Pratiquement chaque session SMTP aujourd'hui utilise ESMTP — le simple HELO est effectivement obsolète.

Comment ça fonctionne

Le client se connecte et reçoit la bannière d'accueil du serveur.
Le client envoie EHLO client.example.com (au lieu de l'ancien HELO).
Le serveur répond avec 250 suivi de son nom d'hôte, puis un mot-clé d'extension par ligne. Chaque ligne utilise 250- (continuation) sauf la dernière, qui utilise 250 (finale).
Le client inspecte la liste des extensions et utilise uniquement les fonctionnalités que le serveur a annoncées.
Si le serveur ne comprend pas EHLO (extrêmement rare aujourd'hui), il retourne une erreur 500, et le client revient à HELO.

Exemple SMTP

Une négociation de capacité ESMTP typique :

S: 220 mx.example.com ESMTP ready C: EHLO sender.example.net S: 250-mx.example.com Hello sender.example.net S: 250-SIZE 52428800 S: 250-8BITMIME S: 250-STARTTLS S: 250-ENHANCEDSTATUSCODES S: 250-PIPELINING S: 250-CHUNKING S: 250-SMTPUTF8 S: 250 AUTH PLAIN LOGIN # Le client sait maintenant exactement ce que ce serveur supporte : # SIZE — la taille maximale du message est 50 MB # 8BITMIME — codage de transfert de contenu 8 bits autorisé # STARTTLS — chiffrement TLS disponible # ENHANCEDSTATUSCODES — codes de statut RFC 3463 # PIPELINING — peut regrouper les commandes (RFC 2920) # CHUNKING — commande BDAT disponible (RFC 3030) # SMTPUTF8 — adresses internationalisées (RFC 6531) # AUTH — authentification avec PLAIN ou LOGIN

Détails techniques clés

Le registre des extensions

Les extensions ESMTP sont enregistrées auprès de l'IANA. Chaque extension définit un mot-clé (par exemple, STARTTLS, AUTH, PIPELINING) et éventuellement des paramètres. Les extensions les plus importantes pour le courrier électronique :

Mot-clé	RFC	Objectif
`SIZE`	RFC 1870	Déclarer la taille maximale du message
`8BITMIME`	RFC 6152	Autoriser le contenu 8 bits dans le corps du message
`STARTTLS`	RFC 3207	Mettre à niveau la connexion vers le chiffrement TLS
`AUTH`	RFC 4954	Authentification SMTP
`PIPELINING`	RFC 2920	Regrouper plusieurs commandes sans attendre
`CHUNKING`	RFC 3030	Transfert de données binaires avec BDAT
`SMTPUTF8`	RFC 6531	Adresses de courrier électronique internationalisées
`DSN`	RFC 3461	Demandes de notification d'état de livraison
`ENHANCEDSTATUSCODES`	RFC 3463	Codes de statut détaillés dans les réponses
`REQUIRETLS`	RFC 8689	Exiger TLS pour ce message

EHLO vs. HELO

HELO est la salutation SMTP d'origine de 1982. Elle ne fournit aucune découverte de capacité. EHLO est un sur-ensemble strict : elle remplit la même fonction de salutation mais déclenche également la liste des capacités. Les serveurs doivent supporter les deux, mais les clients doivent toujours d'abord utiliser EHLO et ne revenir à HELO que si EHLO est rejeté.

Re-EHLO après les changements d'état

La liste des capacités peut changer au cours d'une session. Après une poignée de main STARTTLS, le client doit envoyer un nouveau EHLO car le serveur peut annoncer des extensions différentes sur la connexion chiffrée (par exemple, AUTH n'est souvent disponible qu'après TLS). Après RSET, la liste des capacités reste valide.

Paramètres d'extension

Certaines extensions incluent des paramètres sur la ligne de réponse EHLO. Par exemple, SIZE 52428800 déclare une limite de 50 MB, et AUTH PLAIN LOGIN énumère les mécanismes d'authentification disponibles. Les extensions peuvent également ajouter des paramètres aux commandes MAIL FROM et RCPT TO, comme MAIL FROM:<user@example.com> SIZE=1048576.

Erreurs courantes

Utiliser HELO au lieu de EHLO. Certaines applications héritées envoient toujours HELO. Cela désactive toutes les extensions SMTP, y compris l'authentification et le chiffrement. Utilisez toujours EHLO.
Ne pas vérifier la réponse EHLO. Les clients qui utilisent aveuglément les extensions sans vérifier que le serveur les a annoncées obtiendront des erreurs. Analysez toujours la liste des capacités avant d'utiliser une extension.
Mettre en cache les capacités entre les sessions. Les extensions qu'un serveur supporte peuvent changer entre les connexions. Effectuez toujours un EHLO frais pour chaque nouvelle connexion.
Oublier de re-EHLO après STARTTLS. Après la mise à niveau vers TLS, la liste des capacités pré-TLS est invalide. Un nouveau EHLO est obligatoire pour obtenir les capacités mises à jour.
Envoyer un nom d'hôte EHLO invalide. L'argument de EHLO doit être le FQDN de votre serveur ou, si aucun nom d'hôte n'est disponible, un littéral d'adresse comme [192.0.2.1]. Envoyer un nom d'hôte vide ou faux peut entraîner un rejet.
Ignorer le domaine EHLO pour la sécurité. Les serveurs destinataires ne doivent pas faire confiance au nom d'hôte EHLO pour l'authentification — il est auto-déclaré et trivialement forgé. Utilisez plutôt SPF, DKIM et DMARC.

Impact sur la délivrabilité

ESMTP est nécessaire pour le courrier électronique moderne. Sans EHLO, vous ne pouvez pas utiliser STARTTLS, AUTH, PIPELINING ou toute autre extension. Un client qui ne parle que HELO est traité comme suspect par la plupart des serveurs de courrier.
Le support des extensions signale la légitimité. Les serveurs qui annoncent et implémentent correctement les extensions standard (ENHANCEDSTATUSCODES, PIPELINING, SIZE) sont considérés comme bien configurés. Le manque de support ou la rupture des extensions peut déclencher un score négatif dans les filtres anti-spam.
Le nom d'hôte EHLO importe pour la réputation. Bien que le nom d'hôte EHLO ne soit pas authentifié, de nombreux filtres anti-spam vérifient qu'il se résout en DNS et correspond au DNS inversé de l'IP de connexion. Les non-concordances contribuent au score de spam.
La déclaration SIZE prévient le gaspillage de bande passante. Quand le serveur annonce sa limite de taille, les clients peuvent éviter d'envoyer des messages trop volumineux qui seraient rejetés après le transfert des données complet. Cela améliore l'efficacité de la livraison.