ESMTPS : sens dans un en-tête d’e-mail
ChatGPT
Claude
Gemini
Perplexity
GrokL’essentiel
ESMTPS dans un en-tête signifie qu’ESMTP a franchi un saut protégé par TLS. Différences avec ESMTP, ESMTPSA, STARTTLS et les connexions TLS implicites.
ESMTPS dans un en-tête Received indique que, selon le serveur de réception, ce saut a utilisé Extended SMTP après une négociation TLS réussie. Le S final indique un transport sécurisé pour ce saut. ESMTPA indique que le client s’est authentifié, et ESMTPSA note TLS et authentification. ESMTPS est un mot-clé de trace, pas une commande SMTP, un verdict de livraison ni la preuve que chaque saut de l’expéditeur au destinataire a utilisé TLS.
En bref
Points clés
- ESMTP est SMTP utilisé avec son cadre d’extensions.
- ESMTPS note ESMTP sur un saut protégé par TLS.
- ESMTPA ajoute l’authentification du client sans affirmer TLS.
- ESMTPSA note TLS et l’authentification du client.
- Le mot-clé décrit un seul transfert, noté dans un seul champ
Received. - Une trace n’est utile que si vous vous fiez au serveur qui l’a ajoutée.
Qui est concerné ?
Quiconque lit des en-têtes bruts lors d’une enquête de livraison, de sécurité ou de transport peut voir ESMTPS. Il figure souvent après with dans un champ Received, près des serveurs, de l’identifiant de file, du destinataire et de l’horodatage d’une remise SMTP.
Le terme relève de la couche infrastructure e-mail. Il décrit le transport entre systèmes de messagerie. Il ne donne aucun résultat SPF, DKIM ou DMARC, et ne dit pas si le destinataire a placé le message en boîte de réception.
Quelles sont les exigences ?
La RFC 3848 inscrit les mots-clés Received
La RFC 3848 enregistre sept nouveaux types de transmission pour la clause with d’un en-tête Received. Le registre contenait déjà SMTP et ESMTP ; voici les quatre formes ESMTP utiles à lire :
ESMTP: Extended SMTP.ESMTPA: Extended SMTP avec authentification du client réussie.ESMTPS: la RFC 3848 le décrit comme ESMTP « quand STARTTLS est aussi négocié avec succès pour fournir une couche de chiffrement forte ».ESMTPSA: STARTTLS et SMTP AUTH négociés avec succès, soitESMTPSetESMTPAcombinés.
Authentication-Results des méthodes d’authentification des messages.
ESMTP commence par EHLO et les extensions annoncées
La RFC 5321 définit EHLO et les extensions de service SMTP. Un client envoie EHLO pour s’identifier et recevoir la liste d’extensions du serveur. Un libellé ESMTP seul n’affirme pas que TLS a été utilisé.
Pour une introduction au protocole, voir ce qu’est SMTP. Le S en plus dans ESMTPS est le signal qui restreint cette trace à un transport protégé.
TLS peut être négocié avec STARTTLS
La RFC 3207 définit STARTTLS pour SMTP. Le serveur annonce l’extension STARTTLS, le client la demande et les deux lancent une négociation TLS. Une fois TLS démarré, chaque côté oublie ce qu’il a appris pendant la phase en clair, et le client renvoie EHLO.
ESMTPS note le saut ESMTP protégé obtenu. Il n’indique ni la suite de chiffrement, ni la décision sur le certificat, ni la politique de transport d’un autre serveur, sauf si l’en-tête donne ces détails.
Un champ Received couvre un saut
La RFC 5321 impose à un serveur SMTP qui accepte un message à relayer ou livrer d’insérer un enregistrement de trace Received. Chaque serveur ajoute sa ligne : un message à plusieurs sauts peut porter plusieurs types de transmission.
Received: from outbound.example.net (outbound.example.net [192.0.2.25])
by mx.example.org with ESMTPS id ABC123
for <recipient@example.org>; Tue, 25 Aug 2026 00:30:00 +0000Cet en-tête est un exemple. Il dit que mx.example.org a noté un transfert ESMTP protégé par TLS depuis la source nommée. Il ne prouve pas qu’un saut antérieur ou ultérieur a utilisé TLS.
Quand l’exigence entre-t-elle en vigueur ?
La RFC 3848 enregistre ces mots-clés de trace depuis 2004. La RFC 3207 définit l’extension STARTTLS et la RFC 5321 le comportement de trace SMTP moderne. Aucune échéance de fournisseur de messagerie n’est liée au sens d’ESMTPS.
Un serveur peut toujours choisir un autre type de transmission enregistré ou ajouter des commentaires propres à son implémentation. Lisez le champ complet et la chaîne de trace autour, au lieu de réduire l’enquête au mot-clé.
Comment mettre en œuvre l’exigence ?
1. Trouvez ESMTPS dans un champ Received
Ouvrez la source brute du message et repérez les lignes Received. L’article sur ce qu’est un en-tête d’e-mail distingue les champs fournis par l’expéditeur des champs de trace ajoutés par les serveurs.
2. Identifiez le serveur qui a ajouté la ligne
Lisez l’hôte après by. Ce serveur affirme le type de transmission de la connexion qu’il a acceptée. Vérifiez qu’il fait partie d’une infrastructure de confiance avant de vous fier à cette affirmation.
3. Séparez TLS et authentification du client
Utilisez le mot-clé exact. ESMTPS inclut le signal TLS mais pas le suffixe d’authentification. ESMTPSA inclut les deux. Aucun n’est un résultat SPF, DKIM ou DMARC.
4. Comparez chaque saut pertinent
Lisez la trace en remontant depuis la plus ancienne remise de confiance. Une ligne ESMTPS ne prouve rien sur un autre transfert. Un message peut franchir des sauts protégés et non protégés.
Comment valider la conformité ?
Envoyez un message de test par la route de production. Exportez sa source brute, gardez la chaîne Received complète et comparez horodatages et hôtes avec les journaux du système d’envoi. Ne collez pas d’en-têtes non expurgés dans un ticket public : ils peuvent contenir adresses e-mail, noms d’hôtes internes, adresses IP et identifiants de message.
L’analyseur d’en-têtes d’e-mail peut structurer l’en-tête pour la revue. Il ne peut pas prouver qu’une ligne de trace non fiable dit vrai, inspecter une session TLS non notée, ni garantir que les sauts futurs utiliseront le même transport.
Preuve
Sources et pour aller plus loin
Questions des lecteurs
Questions fréquentes
ESMTPS : le message a-t-il utilisé TLS ?
Oui. La RFC 3848 définit ESMTPS comme ESMTP « quand STARTTLS est aussi négocié avec succès pour fournir une couche de chiffrement forte » sur ce saut. Le registre définit le mot-clé par STARTTLS, mais les MTA courants l’émettent pour toute session ESMTP protégée par TLS, y compris le TLS implicite sur le port 465.
Quelle différence entre ESMTPS et ESMTPSA ?
Seulement l’authentification. ESMTPS note TLS seul. ESMTPSA note TLS plus une authentification du client réussie, que la RFC 3848 décrit comme la combinaison des deux mots-clés.
ESMTPS : le client SMTP s’est-il authentifié ?
Non. ESMTPS note TLS sans le suffixe d’authentification. ESMTPSA note à la fois un TLS valable et une authentification du client réussie.
ESMTPS équivaut-il à SMTPS sur le port 465 ?
Non. ESMTPS est un mot-clé de type de transmission Received. Il n’indique pas à lui seul le port TCP, ni si TLS a démarré de façon implicite ou via STARTTLS.
Une ligne ESMTPS : chiffrement de bout en bout ?
Non. Une ligne décrit un saut entre serveurs. Examinez chaque saut de confiance pertinent et les preuves de transport du système d’envoi.
Une ligne ESMTPS est-elle falsifiable ?
Oui. La RFC 3848 le dit : ces mots-clés « ne sont normalement pas protégés pendant le transport, et un attaquant actif peut donc les modifier ». Fiez-vous aux lignes ajoutées par des serveurs de confiance et comparez-les aux journaux quand la distinction compte.
Rédigé par
Ian BussieresCTO et cofondateur, Palisade
Ian Bussieres est CTO et cofondateur de Palisade, logiciel DMARC agentique pour équipes IT et MSP.
Lire Ian →
