Commandes SMTP : principales commandes, exemples et diagnostic

Les commandes SMTP sont les instructions textuelles qu’un client de messagerie ou un serveur expéditeur envoie à un serveur SMTP pour ouvrir une session, présenter l’expéditeur, désigner les destinataires, transmettre le message et fermer proprement la connexion.

Dans une transaction classique, l’ordre est EHLO, éventuellement STARTTLS puis un nouvel EHLO, AUTH si le serveur de soumission le demande, MAIL FROM, un ou plusieurs RCPT TO, DATA, le contenu terminé par une ligne contenant un seul point, puis QUIT.

Chaque commande reçoit une réponse numérique. Un code 2xx indique généralement une réussite, 3xx demande des données supplémentaires, 4xx signale un échec temporaire qui pourra être retenté et 5xx un échec permanent qui exige une correction. Il ne suffit donc pas de connaître les mots-clés : il faut lire la commande, sa place dans la séquence et la réponse complète du serveur.

Qu’est-ce qu’une commande SMTP ?

SMTP signifie Simple Mail Transfer Protocol. La RFC 5321 le définit comme le protocole de base destiné au transport fiable et efficace du courrier électronique. Son fonctionnement repose sur un dialogue client-serveur : le client envoie une ligne de commande, le serveur répond par un code à trois chiffres accompagné d’un texte explicatif, puis la transaction progresse ou s’arrête selon cette réponse.

Une commande SMTP se compose d’un verbe, parfois suivi d’un argument. NOOP n’a pas besoin d’argument, tandis que MAIL FROM:<alice@example.com> indique un chemin de retour. Les commandes sont traditionnellement écrites en majuscules pour être lisibles, même si leur nom n’est pas sensible à la casse. Les arguments, les adresses et le contenu du message doivent en revanche respecter leur propre syntaxe.

SMTP ne sert pas à consulter une boîte de réception. L’envoi et le transfert reposent sur SMTP ; l’accès aux messages reçus dépend plutôt d’IMAP ou de POP3. Cette séparation explique pourquoi un utilisateur peut recevoir ses e-mails correctement mais ne plus réussir à en envoyer : le serveur entrant fonctionne, tandis que le serveur SMTP, son port, son chiffrement ou son authentification est mal configuré.

Il faut aussi distinguer deux usages. Le transfert entre serveurs de messagerie utilise généralement SMTP sur le port 25. La soumission d’un message par un utilisateur ou une application passe normalement par un serveur de soumission, souvent sur le port 587 avec STARTTLS ou le port 465 avec TLS implicite. Les commandes se ressemblent, mais la soumission exige fréquemment une authentification et applique des règles propres au fournisseur.

Comment se déroule une session SMTP complète ?

Une session commence lorsque le serveur accepte la connexion TCP et envoie une bannière 220. Le client ne doit pas envoyer immédiatement le corps du message. Il se présente d’abord avec EHLO, lit les extensions annoncées, active éventuellement TLS, s’authentifie si nécessaire, puis ouvre une transaction de courrier avec MAIL FROM.

Voici une conversation simplifiée. Les lignes préfixées par S: viennent du serveur et celles préfixées par C: du client :

S: 220 smtp.example.net ESMTP ready

C: EHLO client.example.org

S: 250-smtp.example.net

S: 250-STARTTLS

S: 250-AUTH PLAIN LOGIN

S: 250 SIZE 26214400

C: STARTTLS

S: 220 Ready to start TLS

  [négociation TLS]

C: EHLO client.example.org

S: 250-smtp.example.net

S: 250-AUTH PLAIN LOGIN

S: 250 SIZE 26214400

C: AUTH …

S: 235 2.7.0 Authentication successful

C: MAIL FROM:<alice@example.org>

S: 250 2.1.0 Sender accepted

C: RCPT TO:<bob@example.net>

S: 250 2.1.5 Recipient accepted

C: DATA

S: 354 End data with <CRLF>.<CRLF>

C: From: Alice <alice@example.org>

C: To: Bob <bob@example.net>

C: Subject: Test SMTP

C:

C: Bonjour Bob,

C: ceci est un test.

C: .

S: 250 2.0.0 Message queued as ABC123

C: QUIT

S: 221 2.0.0 Bye

Le 250 reçu après la fin de DATA signifie que le serveur consulté a accepté le message dans sa file. Il ne garantit pas que le destinataire l’a déjà lu, ni même que le serveur final l’a livré dans la boîte de réception. Le message peut encore être relayé, différé, filtré ou renvoyé plus tard sous forme de rapport de non-remise.

Une transaction peut comporter plusieurs destinataires. Le client répète alors RCPT TO pour chacun. Le serveur peut accepter certains destinataires et en refuser d’autres. Le logiciel d’envoi doit conserver cette différence au lieu de considérer toute la transaction comme entièrement réussie ou entièrement échouée.

Tableau des principales commandes SMTP et ESMTP

Ce tableau est un point de départ, pas une invitation à envoyer toutes les commandes à n’importe quel serveur. Les extensions disponibles doivent être lues dans la réponse à EHLO. Un serveur peut désactiver VRFY ou EXPN pour éviter l’énumération de comptes, limiter AUTH aux connexions chiffrées ou refuser le relais à un client non autorisé.

HELO et EHLO : comment ouvrir correctement le dialogue ?

HELO et EHLO présentent le client au serveur. Leur argument doit identifier le client avec un nom de domaine pleinement qualifié lorsque celui-ci en possède un ; à défaut, la syntaxe prévue pour une adresse littérale peut être utilisée. Une chaîne arbitraire, un domaine appartenant à un tiers ou une valeur incohérente avec l’infrastructure peut déclencher des contrôles antispam.

EHLO est la commande moderne. Elle active le modèle ESMTP et demande au serveur d’annoncer ses capacités sur plusieurs lignes 250-, la dernière étant généralement introduite par 250  avec un espace. On peut y trouver SIZE, STARTTLS, AUTH, PIPELINING, 8BITMIME, SMTPUTF8, DSN ou CHUNKING. Le client ne doit utiliser une extension que si elle a été annoncée dans cette session.

HELO reste utile comme solution de repli lorsqu’un ancien serveur ne reconnaît pas EHLO. Ce repli supprime toutefois l’accès aux extensions annoncées par ESMTP. Dans une configuration contemporaine, passer silencieusement de EHLO à HELO peut donc empêcher STARTTLS ou l’authentification. Il vaut mieux diagnostiquer la compatibilité plutôt que masquer un problème de serveur.

Après une négociation STARTTLS réussie, le client doit envoyer un nouvel EHLO. Les capacités annoncées avant le chiffrement ne doivent plus être considérées comme valables : le serveur peut publier une liste différente dans le tunnel TLS, notamment rendre AUTH visible seulement après le chiffrement.

MAIL FROM : définir l’expéditeur d’enveloppe

MAIL FROM ouvre une nouvelle transaction de courrier et définit le reverse-path, aussi appelé expéditeur d’enveloppe ou adresse de retour. Exemple :

MAIL FROM:<bounce@example.org>

Cette adresse n’est pas forcément celle visible dans l’en-tête From: du message. Le chemin d’enveloppe sert au transport et aux rapports de non-remise. L’en-tête From: appartient au contenu du message et indique l’auteur présenté au lecteur. Confondre les deux provoque des erreurs de diagnostic, notamment avec les plateformes marketing, les formulaires WordPress et les contrôles SPF ou DMARC.

Pour certains messages système, notamment les rapports de non-remise, le chemin de retour est vide : MAIL FROM:<>. Cette valeur évite qu’un nouveau rapport d’échec soit envoyé en réponse à un rapport d’échec, ce qui pourrait créer une boucle. Un chemin vide n’est donc pas automatiquement une anomalie ou une tentative d’usurpation.

Avec ESMTP, MAIL FROM peut recevoir des paramètres annoncés par le serveur. SIZE=12345 déclare la taille estimée du message, BODY=8BITMIME indique un contenu compatible avec l’extension correspondante, SMTPUTF8 signale l’usage des fonctions d’adresse internationalisée et REQUIRETLS impose des contraintes spécifiques lorsque cette extension est disponible. Il ne faut jamais ajouter un paramètre non annoncé.

Un refus à ce stade peut venir d’une syntaxe invalide, d’un domaine expéditeur interdit, d’une politique de relais, d’une authentification absente ou d’une taille déclarée excessive. Le texte après le code fournit souvent le véritable motif.

RCPT TO : ajouter un ou plusieurs destinataires

RCPT TO ajoute un destinataire à l’enveloppe de la transaction :

RCPT TO:<bob@example.net>

Pour trois destinataires, la commande est envoyée trois fois. Les champs visibles To: et Cc: ne remplacent pas ces commandes. Inversement, un destinataire d’enveloppe peut ne pas apparaître dans les en-têtes, comme dans le cas d’une copie cachée. Le serveur distribue selon l’enveloppe SMTP, pas selon la présentation du message.

Le traitement individuel explique les résultats partiels. Si le premier destinataire reçoit 250, le deuxième 450 et le troisième 550, le premier est accepté, le deuxième doit être retenté plus tard et le troisième demande une correction. Un client sérieux enregistre le statut de chaque adresse.

Une erreur 550 à l’étape RCPT TO peut signaler une adresse inexistante, un accès refusé, une politique antispam ou un relais non autorisé. Notre guide sur l’erreur SMTP 550 détaille les variantes 5.1.1, 5.7.1, 5.7.26 et relay access denied. Il faut lire la ligne entière, car le même code primaire couvre plusieurs causes.

Les serveurs publics désactivent souvent la vérification préalable d’adresses et peuvent accepter un destinataire avant de rejeter le message plus tard. Une réponse 250 à RCPT TO n’est donc pas une preuve permettant de constituer ou valider une base d’adresses.

DATA : transmettre les en-têtes et le corps du message

DATA demande l’autorisation d’envoyer le contenu du message. Si la séquence est correcte et qu’au moins un destinataire a été accepté, le serveur répond normalement 354. Le client transmet ensuite les en-têtes, une ligne vide, le corps, puis termine le bloc par <CRLF>.<CRLF>, c’est-à-dire une ligne contenant uniquement un point.

DATA

354 End data with <CRLF>.<CRLF>

From: Alice <alice@example.org>

To: Bob <bob@example.net>

Subject: Rapport de test

Date: Tue, 1 Sep 2026 10:00:00 +0200

Message-ID: <test-20260901@example.org>

Bonjour,

le serveur doit recevoir cette ligne comme corps du message.

.

250 2.0.0 Message accepted for delivery

Le point final n’est pas inclus dans le message. Lorsqu’une ligne réelle du contenu commence par un point, le client applique le dot-stuffing en ajoutant un second point. Le serveur retire ce point supplémentaire. Sans ce mécanisme, une ligne du corps pourrait être interprétée comme la fin prématurée de DATA.

La réponse décisive arrive après le point final. Un 250 signifie que le serveur a accepté sa responsabilité pour le message. Un 4xx indique un échec temporaire ; un 5xx, un rejet définitif dans l’état actuel. Fermer la connexion avant cette réponse laisse le résultat incertain et peut provoquer un doublon si l’application renvoie aveuglément le message.

Les pièces jointes ne sont pas envoyées par une commande SMTP distincte. Elles font partie du contenu MIME transmis pendant DATA, encodées et décrites dans les en-têtes du message. SMTP transporte le bloc ; MIME en structure le texte, les versions HTML et les pièces jointes.

RSET, NOOP et QUIT : contrôler ou terminer la session

RSET annule la transaction en cours sans fermer la connexion. Le serveur efface l’expéditeur, les destinataires et les données associés à cette transaction, puis revient à un état où un nouveau MAIL FROM peut être envoyé. Cette commande est utile après une erreur de séquence ou lorsqu’une application abandonne un message mais veut réutiliser la session.

NOOP ne modifie pas l’état. Il demande simplement une réponse, généralement 250. Les outils de supervision l’utilisent pour vérifier qu’une session reste réactive. Il ne faut pas le confondre avec un test complet d’envoi : un serveur peut répondre à NOOP tout en refusant ensuite l’authentification ou les destinataires.

QUIT demande une fermeture propre. Le serveur répond normalement 221, puis ferme le canal. Interrompre brutalement la connexion n’est pas équivalent : l’administrateur perd une partie de la trace normale et le client peut mal interpréter l’état de la dernière transaction.

Ces trois commandes facilitent la gestion de sessions longues, mais une application ne doit pas maintenir des connexions indéfiniment. Les serveurs appliquent des temporisations, des limites de messages et des politiques de débit. La réutilisation doit respecter les réponses et les recommandations du fournisseur.

VRFY, EXPN et HELP : pourquoi ces commandes sont souvent limitées ?

VRFY demande au serveur de confirmer ou de préciser l’identité d’un utilisateur. EXPN demande le développement des membres d’une liste de diffusion. Historiquement utiles pour le diagnostic, elles peuvent aussi permettre à un attaquant d’énumérer des comptes et des groupes.

La RFC 5321 autorise les serveurs à limiter les informations renvoyées pour des raisons de sécurité. Un serveur peut répondre 252, indiquant qu’il ne peut pas vérifier l’utilisateur mais acceptera le message et tentera la livraison, ou retourner une réponse de politique. Ce refus ne signifie pas que SMTP est en panne.

HELP fournit une aide générale ou relative à une commande. Son résultat varie fortement selon le logiciel serveur et ne remplace pas la documentation de l’hébergeur. Les réponses habituelles appartiennent aux codes 211 ou 214.

N’utilisez jamais VRFY ou EXPN pour collecter des adresses sur une infrastructure qui ne vous appartient pas. Pour diagnostiquer votre propre serveur, préférez les journaux, les comptes de test et les outils d’administration. Une fonctionnalité accessible au niveau du protocole n’est pas nécessairement autorisée par la politique du service.

STARTTLS : chiffrer la connexion SMTP existante

STARTTLS est une extension ESMTP définie par la RFC 3207. Le client commence en clair, envoie EHLO, vérifie que le serveur annonce STARTTLS, puis demande la mise à niveau :

EHLO client.example.org

250-STARTTLS

250 SIZE 26214400

STARTTLS

220 Ready to start TLS

Après 220, les octets suivants appartiennent à la négociation TLS, pas à une nouvelle commande SMTP lisible. Le client doit vérifier le certificat, le nom du serveur, sa période de validité et la chaîne de confiance. Une fois le tunnel établi, il envoie un nouvel EHLO et utilise uniquement les capacités annoncées dans la session protégée.

STARTTLS n’est pas la même chose que TLS implicite. Sur le port 587, la session débute habituellement en clair avant la commande STARTTLS. Sur le port 465, la négociation TLS a lieu dès l’ouverture de la connexion, avant toute bannière SMTP. Dans les deux cas, le résultat attendu est une connexion chiffrée ; la méthode de démarrage diffère.

Le chiffrement protège le trajet entre les deux systèmes connectés. Il ne remplace pas l’authentification du domaine par SPF, DKIM et DMARC, ni le chiffrement de bout en bout du contenu. Pour approfondir les termes, consultez notre comparaison SSL ou TLS.

Un test ne doit pas accepter silencieusement un certificat invalide. Si l’application est configurée pour exiger TLS et que la négociation échoue, elle doit signaler l’incident. Désactiver la vérification des certificats pour « faire fonctionner » l’envoi transforme une erreur visible en risque d’interception.

AUTH : authentifier un utilisateur ou une application

AUTH est l’extension d’authentification SMTP décrite par la RFC 4954. Les mécanismes disponibles apparaissent dans la réponse à EHLO, par exemple AUTH PLAIN LOGIN ou des mécanismes modernes fondés sur OAuth. Le client choisit uniquement une méthode qu’il comprend et que le serveur annonce.

L’authentification intervient généralement sur le serveur de soumission. Elle ne doit pas être confondue avec SPF, DKIM ou DMARC : AUTH prouve au serveur que le client est autorisé à utiliser un compte ou un service ; SPF et DKIM permettent aux domaines destinataires d’évaluer l’origine du message, tandis que DMARC ajoute une politique d’alignement.

Les mécanismes PLAIN et LOGIN ne chiffrent pas eux-mêmes le secret. Ils utilisent un encodage, souvent Base64, qui est réversible. Ils ne doivent être employés que dans un canal TLS correctement vérifié. Base64 n’est pas une protection cryptographique.

Ne collez jamais un vrai mot de passe, jeton OAuth ou mot de passe d’application dans une capture, un ticket public ou une commande enregistrée dans l’historique du terminal. Utilisez un compte de test à privilèges limités, supprimez les traces et révoquez immédiatement tout secret exposé.

Les réponses fréquentes incluent 235 pour une authentification réussie, 334 lorsqu’un échange supplémentaire est attendu, 454 pour un échec temporaire et 535 pour des identifiants refusés. Le texte enrichi aide à distinguer mot de passe erroné, mécanisme interdit, authentification moderne obligatoire ou compte bloqué.

Quelles extensions ESMTP peut annoncer EHLO ?

ESMTP permet d’ajouter des capacités sans modifier le cœur du protocole. La liste dépend du serveur et parfois de l’état de la session. Les extensions suivantes sont courantes :

PIPELINING améliore les performances, mais complique le traitement des erreurs. Le client peut envoyer plusieurs commandes autorisées sans attendre chaque réponse, tout en devant associer chaque réponse à la bonne commande. Cette extension n’autorise pas à ignorer l’ordre logique de la transaction.

SIZE peut apparaître avec une valeur, par exemple 250-SIZE 26214400. La limite porte sur la représentation transmise et peut différer de la taille du fichier original, car MIME et Base64 augmentent le volume. Un fichier joint proche de la limite peut donc produire un message trop grand.

SMTPUTF8 ne signifie pas que tout serveur accepte toutes les adresses internationalisées. Le client doit annoncer le paramètre approprié avec MAIL FROM et vérifier la compatibilité du trajet. Une solution prudente conserve une adresse de repli lorsque l’écosystème du destinataire ne prend pas en charge l’extension.

Comment lire les codes de réponse SMTP ?

Le premier chiffre donne la classe générale. 2xx signifie que l’action demandée a été accomplie ; 3xx que le serveur attend une information ou le contenu ; 4xx qu’un problème temporaire empêche l’action ; 5xx que la requête ne doit pas être répétée à l’identique sans correction.

Les codes enrichis comme 5.1.1, 5.2.2 ou 5.7.1 ajoutent trois dimensions : classe, sujet et détail. 5.1.1 pointe généralement vers une adresse de destination inexistante ; 5.2.2 vers une boîte saturée ; 5.7.1 vers une politique ou une autorisation. Le texte propre au serveur reste indispensable.

Une erreur 4xx ne doit pas déclencher une boucle de renvoi rapide. Le système expéditeur conserve normalement le message en file et applique une temporisation croissante. Une erreur 5xx ne doit pas être retentée à l’identique automatiquement, car cela gaspille les ressources et peut détériorer la réputation de l’expéditeur.

Quels ports utiliser pour SMTP : 25, 587 ou 465 ?

Le port 25 sert principalement au transfert SMTP entre serveurs. Il est indispensable au fonctionnement du courrier Internet, mais de nombreux réseaux bloquent les connexions sortantes vers ce port pour limiter le spam. Un particulier ou une application ne doit pas supposer que le port 25 est celui fourni pour l’envoi authentifié.

Le port 587 correspond à la soumission de messages. Le client se connecte, reçoit la bannière, envoie EHLO, exige STARTTLS et vérifie correctement le certificat avant toute authentification. Si le serveur n’annonce pas STARTTLS alors que la configuration impose une soumission sécurisée, le client doit interrompre la session plutôt que transmettre des identifiants en clair.

C’est souvent le choix recommandé par les fournisseurs pour les logiciels de messagerie et les applications.

Le port 465 est enregistré pour la soumission avec TLS implicite. La négociation TLS précède le dialogue SMTP. Il n’est donc pas possible d’ouvrir une session Telnet lisible sur ce port puis d’envoyer STARTTLS : le serveur attend déjà un ClientHello TLS.

Le port seul ne garantit pas la sécurité. Il faut vérifier le certificat, exiger une version TLS acceptable, protéger les identifiants et respecter la documentation du fournisseur. Si celui-ci impose OAuth2 ou un mot de passe d’application, remplacer simplement 587 par 465 ne résoudra pas l’authentification.

Comment tester un serveur SMTP avec OpenSSL sans exposer ses identifiants ?

Un test manuel doit être réalisé uniquement sur un serveur que vous administrez ou que votre fournisseur vous autorise à tester. Utilisez un compte dédié, sans données réelles, et ne lancez pas de vérification intrusive contre des serveurs tiers.

Pour tester STARTTLS sur le port 587 :

openssl s_client -starttls smtp -connect smtp.example.org:587 -servername smtp.example.org -crlf

Pour tester TLS implicite sur le port 465 :

openssl s_client -connect smtp.example.org:465 -servername smtp.example.org -crlf

L’option -servername transmet le nom SNI attendu et facilite la présentation du bon certificat sur une infrastructure mutualisée. Vérifiez le résultat de validation, le nom couvert, l’émetteur et la chaîne. Ne vous contentez pas de constater qu’un chiffrement a été négocié.

Une fois connecté, envoyez EHLO test.example.org et lisez la liste des extensions. Pour tester la transaction sans transmettre un vrai message, vous pouvez utiliser RSET et QUIT. Si un test d’envoi est nécessaire, utilisez une adresse de test contrôlée et un contenu clairement identifié.

Telnet et Netcat peuvent aider sur un environnement local non sensible, mais ils ne protègent pas les identifiants. N’utilisez jamais AUTH sur une connexion en clair. Évitez aussi de placer un secret directement dans une commande shell, car l’historique, la liste des processus ou les journaux peuvent le conserver.

Erreurs fréquentes et scénarios de diagnostic

Scénario 1 : `503 Bad sequence of commands`. Le client a envoyé les commandes dans le mauvais ordre, par exemple DATA avant un destinataire accepté ou AUTH dans un état non prévu. Envoyez RSET, reprenez par MAIL FROM, puis vérifiez la séquence et les réponses précédentes. Après STARTTLS, n’oubliez pas le nouvel EHLO.

Scénario 2 : `530 Authentication required`. Le serveur de soumission refuse le relais tant que le client n’est pas authentifié. Vérifiez que AUTH est annoncé après TLS, que le compte est autorisé et que le client utilise la bonne méthode. N’essayez pas de contourner l’exigence en changeant l’adresse MAIL FROM.

Scénario 3 : `535 Authentication failed`. Les identifiants peuvent être erronés, le mot de passe d’application révoqué, l’authentification basique désactivée ou le compte bloqué. Testez la connexion au webmail, consultez les événements de sécurité et utilisez la méthode officielle. Répéter rapidement le mot de passe peut déclencher un verrouillage.

Scénario 4 : `550 relay access denied`. Le client tente d’envoyer vers un domaine externe sans être reconnu comme relais autorisé. Utilisez le serveur de soumission du fournisseur, activez TLS et authentifiez-vous. Sur un serveur que vous administrez, contrôlez les réseaux de confiance et les politiques sans créer un relais ouvert.

Scénario 5 : le serveur accepte `MAIL FROM` mais refuse `RCPT TO`. L’expéditeur est acceptable, mais le destinataire, le domaine ou la politique de relais ne l’est pas. Lisez le code enrichi. Vérifiez l’adresse et le domaine MX ; ne modifiez pas le corps du message si le rejet intervient avant DATA, sauf si le texte indique une règle spécifique.

Scénario 6 : `552 message size exceeds fixed limit`. La taille MIME dépasse la limite annoncée par SIZE. Réduisez les pièces jointes, partagez un lien sécurisé ou ajustez la limite si vous administrez les deux côtés. La taille encodée est supérieure à celle du fichier brut.

Scénario 7 : STARTTLS est annoncé mais la négociation échoue. Vérifiez le nom du serveur, le certificat, la chaîne, l’horloge, les versions TLS et une éventuelle interception réseau. Ne désactivez pas la validation. Comparez le test depuis un autre réseau et consultez les journaux serveur.

Scénario 8 : le message reçoit `250` mais n’arrive pas. Le serveur interrogé l’a accepté, mais la suite du trajet peut échouer. Conservez l’identifiant de file, consultez les journaux, cherchez un NDR, contrôlez le relais suivant, les filtres et la quarantaine. Un 250 n’est pas une preuve de placement dans la boîte principale.

Scénario 9 : plusieurs destinataires donnent des résultats différents. Traitez chaque réponse RCPT TO séparément. Envoyez le message aux destinataires acceptés, différez les 4xx selon la politique et retirez ou corrigez les 5xx. Ne renvoyez pas ensuite le message à tous, au risque de créer des doublons.

Scénario 10 : l’application fonctionne en local mais pas sur l’hébergement. Le fournisseur peut bloquer le port 25, imposer un serveur relais, filtrer les connexions sortantes ou exiger une adresse d’expéditeur du domaine. Testez la résolution DNS, la connectivité vers 587/465 et les paramètres officiels de l’hébergeur.

FAQ

Quelle est la séquence minimale pour envoyer un e-mail ?

Après la bannière 220, la séquence de base est EHLO ou HELO, MAIL FROM, un ou plusieurs RCPT TO, DATA, les en-têtes et le corps terminés par une ligne contenant un point, puis QUIT. Sur un serveur de soumission moderne, STARTTLS et AUTH s’insèrent généralement après le premier EHLO.

Faut-il utiliser HELO ou EHLO ?

Utilisez EHLO en premier. Il permet au serveur d’annoncer ses extensions, notamment STARTTLS, AUTH et SIZE. HELO sert surtout de repli pour un serveur ancien qui ne prend pas en charge ESMTP.

MAIL FROM est-il identique au champ From visible ?

Non. MAIL FROM définit l’expéditeur d’enveloppe utilisé pour le transport et les rapports de non-remise. Le champ From: fait partie du message affiché au lecteur. Ils peuvent être différents, même si les politiques d’authentification imposent souvent un alignement cohérent.

Peut-on vérifier une adresse avec VRFY ?

Pas de manière fiable. Beaucoup de serveurs limitent ou désactivent VRFY pour protéger les comptes contre l’énumération. Une absence de confirmation ne prouve pas que l’adresse n’existe pas, et une acceptation à l’étape SMTP ne garantit pas la livraison finale.

Un code 250 signifie-t-il que l’e-mail est livré ?

Il signifie que le serveur a accepté l’action demandée. Après DATA, il indique que ce serveur a accepté le message. Le courrier peut encore être relayé, filtré, différé ou faire l’objet d’un rapport de non-remise ultérieur.

SMTP permet-il de recevoir les e-mails ?

SMTP sert à l’envoi, au relais et au transport. La consultation et la synchronisation d’une boîte reposent sur IMAP ou, dans certains usages, sur POP3.

Sources officielles consultées

• RFC 5321 — Simple Mail Transfer Protocol, IETF / RFC Editor.
• RFC 3207 — SMTP Service Extension for Secure SMTP over TLS, IETF / RFC Editor.
• RFC 4954 — SMTP Service Extension for Authentication, IETF / RFC Editor.
• RFC 6409 — Message Submission for Mail, IETF / RFC Editor.
• RFC 8314 — Cleartext Considered Obsolete, IETF / RFC Editor.
• RFC 3463 — Enhanced Mail System Status Codes, IETF / RFC Editor.
• RFC 2920 — SMTP Service Extension for Command Pipelining, IETF / RFC Editor.
• RFC 1870 — SMTP Service Extension for Message Size Declaration, IETF / RFC Editor.
• RFC 6531 — SMTP Extension for Internationalized Email, IETF / RFC Editor.
• RFC 8689 — SMTP Require TLS Option, IETF / RFC Editor.
• RFC 3461 — SMTP Service Extension for Delivery Status Notifications, IETF / RFC Editor.
• RFC 3030 — SMTP Service Extensions for Transmission of Large and Binary MIME Messages, IETF / RFC Editor.
• RFC 6152 — SMTP Service Extension for 8-bit MIME Transport, IETF / RFC Editor.
• Registre des noms de services et numéros de ports, IANA.