terme · protocole smtp

Qu’est-ce que le protocole SMTP et quel est son impact sur les e-mails applicatifs ?

SMTP, ou Simple Mail Transfer Protocol, est le protocole standardisé qu’utilisent les systèmes de messagerie pour soumettre, relayer et transmettre les e-mails sortants. Une application remet généralement un message finalisé à un service de soumission authentifié ; les serveurs de messagerie utilisent ensuite les commandes SMTP et le routage DNS pour l’acheminer vers chaque destinataire. Les réponses SMTP indiquent si un saut donné a accepté ou refusé un destinataire, mais l’acceptation n’équivaut pas au placement en boîte de réception. Les applications ont toujours besoin de files d’attente durables, de nouvelles tentatives sûres, d’identifiants de message, d’authentification et du traitement des bounces.

SMTP transfère les e-mails entre systèmes responsables

SMTP est un protocole de transfert de type store-and-forward (stockage puis retransmission). Un client ouvre une session avec un serveur, s’identifie, présente un expéditeur d’enveloppe, propose un ou plusieurs destinataires d’enveloppe, et transmet le contenu du message une fois que le serveur a accepté de le recevoir. Le serveur peut accepter certains destinataires et en refuser d’autres : le statut appartient donc à un destinataire et à une transaction, et pas seulement au message dans son ensemble. Une fois qu’un serveur a accepté la prise en charge, il peut livrer localement ou relayer le message vers un autre système choisi via les enregistrements DNS Mail Exchanger. Cette conception saut par saut explique pourquoi une application ne doit pas réduire l’état d’un e-mail à un simple booléen « envoyé ». L’application, le service de soumission, le relais, le serveur de réception et le système de filtrage de la boîte aux lettres connaissent chacun une partie différente du résultat. SMTP déplace le message entre les systèmes, tandis que les enregistrements au niveau du produit et les événements du fournisseur rendent ce déplacement compréhensible pour les utilisateurs et les opérateurs.

Soumission et relais sont deux rôles distincts du protocole

La RFC 6409 sépare la soumission des messages de leur relais. La soumission est la première remise, d’un utilisateur ou d’une application autorisés à un Message Submission Agent, normalement sur le port 587. Le relais est le transfert entre Message Transfer Agents et utilise traditionnellement le port 25. Les services de soumission peuvent exiger une authentification, valider ou compléter les champs du message et appliquer une politique d’expéditeur, car ils savent qui introduit du nouveau courrier. Les serveurs de relais publics doivent interopérer avec d’autres domaines et suivent d’autres règles de confiance. Le code applicatif doit donc se connecter à l’endpoint de soumission documenté par le fournisseur ou utiliser son API HTTP, et non ouvrir des connexions arbitraires sur le port 25 vers les serveurs de destination. Cette séparation clarifie aussi les identifiants : un nom d’utilisateur ou un jeton SMTP autorise la soumission à un service particulier ; il ne donne aucune autorité sur le domaine de destination. Gardez les identifiants de soumission côté serveur, limitez leur portée à la charge d’envoi lorsque le fournisseur le permet, et faites-en la rotation sans les intégrer au contenu des messages ni aux logiciels clients.

L’enveloppe SMTP diffère des en-têtes visibles du message

Une transaction SMTP transporte une enveloppe avec `MAIL FROM` et une ou plusieurs commandes `RCPT TO`. Le contenu transféré suit séparément l’Internet Message Format défini par la RFC 5322, avec des champs comme From, To, Date, Subject et Message-ID, plus un corps. Les standards MIME étendent ce contenu pour le HTML, les parties alternatives, les pièces jointes et les données non ASCII. L’expéditeur d’enveloppe est l’adresse utilisée pour les échecs de transport et peut différer de l’auteur From visible. Les destinataires d’enveloppe peuvent aussi différer des champs To et Cc visibles, comme avec Bcc. Ne construisez pas ces structures en concaténant des chaînes non fiables. Utilisez une bibliothèque de messages maintenue, validez les adresses, bloquez l’injection de sauts de ligne dans les champs d’en-tête et conservez un Message-ID stable. Lors du dépannage, examinez les deux couches : un champ From visible correct ne peut pas réparer une identité d’enveloppe non autorisée, et une enveloppe valide ne permet pas à un MIME malformé de s’afficher correctement.

Lisez la transaction comme une machine à états

Une session Extended SMTP de base commence par un message d’accueil du serveur, puis `EHLO` pour que le serveur annonce ses extensions. Le client peut négocier TLS et l’authentification pour la soumission. Une transaction de messagerie utilise ensuite `MAIL FROM`, un `RCPT TO` par destination, `DATA`, le message complet terminé selon le cadrage SMTP, et `QUIT`. Ne voyez pas dans cet exemple une raison d’implémenter vous-même le protocole ; les bibliothèques SMTP matures gèrent de façon plus sûre les fins de ligne, la transparence des points, la négociation des capacités, l’authentification et l’état TLS. Instrumentez la bibliothèque au niveau des catégories de commandes et des codes de réponse, sans journaliser les identifiants ni les corps de messages complets. Notez quel destinataire a échoué à quelle étape, et si le serveur avait accepté la prise en charge après les données du message. Cette frontière détermine si une nouvelle tentative est appropriée, si un doublon est possible, et si l’échec sera signalé par une notification d’état de livraison ultérieure plutôt que par une réponse immédiate.

Classez les codes de réponse avant de décider de réessayer

Les classes de réponse SMTP indiquent l’action à mener. Une réponse 2xx signale l’exécution réussie de la commande. Une réponse 4xx est un échec négatif transitoire : un expéditeur disposant d’une file d’attente peut réessayer après un délai. Une réponse 5xx est un échec négatif permanent pour la commande tentée et exige normalement une correction, une suppression ou une investigation humaine plutôt que des nouvelles tentatives répétées. Les codes de statut étendus ajoutent un diagnostic structuré `X.Y.Z` pour les conditions relatives à l’adresse, à la boîte aux lettres, au système, au routage, au protocole, au contenu ou à la sécurité et aux politiques. Conservez à la fois le code numérique et le texte du serveur, car chacun peut apporter une valeur diagnostique, mais n’exposez pas largement les réponses brutes contenant des données de destinataires. Appliquez aux échecs transitoires un backoff exponentiel avec jitter et une durée de vie maximale dans la file. Ne réessayez jamais de manière si agressive qu’un problème temporaire chez la destination se transforme en trafic abusif. En cas d’échec permanent sur une adresse, arrêtez les envois automatiques vers cette destination et mettez à jour l’état de suppression. En cas d’échec de politique ou d’authentification, corrigez l’identité, le DNS, les identifiants ou le contenu avant toute nouvelle tentative.

Utilisez une soumission chiffrée et authentifiée

SMTP est né comme protocole de transport entre des réseaux aux hypothèses de confiance différentes : la sécurité de la soumission repose donc sur des extensions et sur la politique de déploiement. STARTTLS fait passer une connexion SMTP en TLS, après quoi le client doit ignorer les capacités apprises avant la négociation et renvoyer `EHLO`. La RFC 8314 met à jour les recommandations sur la soumission en considérant l’accès et la soumission en clair comme obsolètes et en décrivant le TLS implicite pour la soumission. SMTP AUTH, standardisé dans la RFC 4954, permet à un serveur de soumission d’authentifier un client via les mécanismes annoncés. Utilisez le nom d’hôte, le port, le mode TLS et les instructions d’authentification actuels du fournisseur plutôt que de deviner une combinaison. Validez le certificat du serveur et ne revenez pas silencieusement au texte en clair lorsque la charge exige une soumission protégée. Conservez les mots de passe ou jetons dans un gestionnaire de secrets, utilisez des identifiants distincts par environnement et désactivez les mécanismes d’authentification obsolètes. TLS protège un saut de connexion ; il n’authentifie pas l’auteur du message auprès de chaque destinataire en aval et ne remplace pas l’alignement d’identité SPF, DKIM et DMARC.

Diagnostiquez un échec d’e-mail applicatif saut par saut

Commencez par l’enregistrement sortant durable de l’application : l’événement produit était-il autorisé, et une seule tâche en file d’attente l’a-t-elle pris en charge ? Examinez ensuite la soumission : résolution DNS, connexion TCP, négociation TLS, validation du certificat, authentification, autorisation de l’expéditeur d’enveloppe, réponses par destinataire et réponse finale à DATA. Si le service de soumission a accepté le message, cessez de rejouer aveuglément la requête et suivez son identifiant de message et son flux d’événements. Distinguez un état traité par le fournisseur de l’acceptation par le serveur de réception. Un bounce ultérieur peut encore signaler un échec permanent après l’acceptation initiale. Si le serveur de réception a accepté le message, examinez les résultats d’authentification, la réputation, la politique du destinataire, le contenu et le classement dans la boîte aux lettres, au lieu de parler d’échec de transport SMTP. Vérifiez à la fois les identités d’enveloppe et d’en-tête, et conservez les horodatages, les codes de réponse, le nombre de tentatives dans la file et les identifiants du fournisseur. Utilisez des destinataires contrôlés pour les tests. Ne collez jamais d’identifiants SMTP de production ni de messages clients complets dans des tickets, des prompts, l’historique du terminal ou des outils de diagnostic publics.

Distinguez acceptation, livraison et placement en boîte de réception

La précision protocolaire compte dans les interfaces produit. L’acceptation applicative signifie que le système local a enregistré une requête. L’acceptation à la soumission signifie que le premier service de messagerie a accepté la responsabilité de la traiter. La livraison au serveur de réception signifie que le serveur SMTP de destination a renvoyé un succès pour la remise. Le placement en boîte de réception est une décision ultérieure de politique et de classement au sein de l’environnement de réception. Un message peut franchir un état puis échouer ou être classé différemment à l’étape suivante. SMTP fournit des preuves directes sur la transaction en cours et peut produire ultérieurement des notifications d’état de livraison, mais il n’expose pas le dossier final du destinataire. Stockez ces états indépendamment au lieu de qualifier chaque réponse 250 de livraison en boîte de réception. Un événement du fournisseur qui inclut la réponse SMTP de succès de la destination peut justifier un état « remis au serveur ». Un bounce justifie un traitement d’échec ou de suppression. Aucun des deux ne permet de promettre la visibilité, la lecture ou l’engagement. Ce modèle garde des statuts fidèles à la réalité et empêche des nouvelles tentatives dangereuses une fois la responsabilité transférée.

Utilisez l’API documentée de SendHQ

Une application peut utiliser SMTP au moyen d’une bibliothèque de fournisseur, ou appeler une API e-mail HTTP dont le fournisseur gère le transport de courrier Internet sous cette interface. SendHQ fournit une API e-mail limitée à l’espace de travail avec des vérifications de domaine, des ressources de messages sortants et entrants, des événements, des suppressions, des boîtes de réception et des limites de ressources d’espace de travail. Son API HTTP peut fournir des requêtes structurées, des identifiants et des événements en parallèle de la soumission SMTP directe. Elle ne modifie pas le comportement du serveur de destination et n’établit ni l’acceptation SMTP, ni le placement en boîte de réception, ni l’engagement du destinataire.

Questions fréquentes

Que signifie SMTP ?

SMTP signifie Simple Mail Transfer Protocol. Il définit comment les clients et serveurs de messagerie soumettent et transfèrent les messages sortants au moyen de commandes, de réponses, d’enveloppes, de données de message et d’extensions pour des capacités comme l’authentification et TLS.

SMTP sert-il à lire les e-mails d’une boîte de réception ?

Non. SMTP sert principalement à soumettre et transférer les e-mails sortants. L’accès à une boîte de réception passe par d’autres interfaces comme IMAP, POP, une API de boîte aux lettres propre au fournisseur ou une API e-mail applicative qui expose les messages entrants stockés.

Quelle est la différence entre les ports 25, 587 et 465 ?

Le port 25 est traditionnellement utilisé pour le relais de serveur à serveur. Le port 587 est le service standard de soumission de messages et négocie couramment TLS. Le port 465 est enregistré pour la soumission via TLS implicite. Suivez l’endpoint et le mode de sécurité documentés par le fournisseur plutôt que de changer de port à titre expérimental.

Un succès SMTP prouve-t-il qu’un e-mail est arrivé en boîte de réception ?

Non. Une réponse de succès prouve seulement que le serveur SMTP qui répond a accepté la commande concernée ou la responsabilité du message. Le système de réception peut encore appliquer une politique ultérieure, générer un échec différé ou classer le message accepté en dehors de la boîte de réception principale.

Une application doit-elle réessayer chaque réponse SMTP 4xx ?

Un code 4xx indique un résultat négatif transitoire, mais les nouvelles tentatives doivent passer par une file d’attente durable, avec un backoff exponentiel et du jitter, une durée de vie finie et des limites de tentatives tenant compte du destinataire. Examinez les échecs temporaires répétés au lieu de réessayer indéfiniment.

Une API e-mail HTTP remplace-t-elle SMTP ?

Elle peut remplacer SMTP dans le code applicatif, mais le fournisseur utilise normalement toujours SMTP pour communiquer avec les systèmes de messagerie des destinataires. Une API ajoute, au-dessus de la couche de transport, une authentification structurée, des payloads, une portée des ressources, des identifiants et la gestion des événements.

Sources

Continuer à apprendre

Guide d’implémentation d’une API e-mail pour les équipes produitConcevez une intégration d’API e-mail sûre avec des domaines vérifiés, des envois mis en file d’attente, des identifiants stables, des nouvelles tentatives maîtrisées, des événements de livraison, la suppression et l’isolation entre tenants.