Chaque jour, plus de 300 milliards d’emails parcourent Internet. Ils voyagent entre des serveurs dont vous n’avez jamais entendu parler, à travers des réseaux que vous ne verrez jamais, en utilisant un protocole conçu en 1982. Ce protocole, c’est SMTP — Simple Mail Transfer Protocol — et malgré son âge, il reste l’épine dorsale de la communication par email.
La plupart des développeurs interagissent avec l’email via des APIs de haut niveau qui masquent la mécanique sous-jacente. Vous appelez une fonction, passez quelques paramètres, et l’email part. Mais lorsque quelque chose tourne mal — et cela arrivera — comprendre ce qui se passe réellement sous le capot fait la différence entre déboguer efficacement et tâtonner dans le noir.
La conversation SMTP
SMTP est un protocole textuel, ce qui signifie que vous pouvez littéralement avoir une conversation avec un serveur de mail via telnet ou netcat. Ce n’est pas qu’une curiosité — c’est une technique de débogage puissante. Voyons à quoi ressemble cette conversation.
Quand votre serveur de mail veut envoyer un email, il commence par rechercher le serveur du destinataire via les enregistrements DNS MX. Si vous envoyez à [email protected], il interroge les enregistrements MX de example.com pour savoir quel serveur gère le courrier pour ce domaine.
Ensuite, il ouvre une connexion TCP vers ce serveur, généralement sur le port 25 (ou 587 pour la submission, ou 465 pour l’implicite TLS). Le serveur récepteur répond par une salutation — généralement un code d’état 220 et quelques informations d’identification.
Votre serveur se présente avec EHLO (ou l’ancien HELO), en annonçant son hostname. Le serveur récepteur répond avec une liste des extensions qu’il prend en charge — des choses comme STARTTLS pour le chiffrement, AUTH pour l’authentification, et des limites de SIZE.
Si les deux serveurs prennent en charge STARTTLS, ils négocient à ce moment une connexion chiffrée. C’est du chiffrement opportuniste — si cela échoue, ils peuvent revenir à une transmission non chiffrée (sauf si l’un des côtés exige le chiffrement).
Vient ensuite la transmission réelle de l’email. Votre serveur envoie MAIL FROM avec l’adresse de l’expéditeur de l’enveloppe. Puis RCPT TO avec l’adresse du destinataire (répété pour plusieurs destinataires). Le serveur récepteur peut accepter ou refuser à chaque étape — peut-être que le destinataire n’existe pas, ou que l’expéditeur est sur liste noire.
Enfin, votre serveur envoie DATA, suivi du contenu réel de l’email (headers et corps), terminé par une ligne ne contenant qu’un point. Le serveur récepteur accepte le message (250 OK) ou le rejette avec un code d’erreur.
Enveloppe vs. headers
Voici quelque chose qui en déroute beaucoup : les adresses dans la conversation SMTP (l’‘enveloppe’) sont séparées des adresses dans les headers de l’email. Elles peuvent être — et sont souvent — différentes.
Les adresses d’enveloppe (MAIL FROM et RCPT TO) servent au routage. Elles déterminent où l’email va réellement et où les rebonds sont envoyés. Les adresses des headers (From, To, Cc) sont celles que les destinataires voient dans leur client mail.
Cette séparation existe pour de bonnes raisons. Les listes de diffusion l’utilisent : l’expéditeur d’enveloppe est l’adresse de rebond de la liste, tandis que le header From affiche l’auteur original. Le transfert l’utilise : l’enveloppe change à chaque saut, mais les headers conservent l’expéditeur d’origine.
Mais cette séparation permet aussi l’usurpation. Un attaquant peut définir le header From sur n’importe quelle adresse tout en utilisant son propre serveur pour l’enveloppe. C’est pourquoi SPF vérifie l’expéditeur d’enveloppe, DKIM signe les headers, et DMARC exige leur alignement.
Relais et smart hosts
Aux débuts de l’email, les serveurs relayaient des messages pour n’importe qui. Vous pouviez vous connecter à n’importe quel serveur SMTP et lui demander de livrer du courrier pour vous. Ce modèle d’open relay était pratique mais est devenu intenable avec l’explosion du spam.
Aujourd’hui, la plupart des serveurs SMTP sont configurés pour relayer uniquement pour des utilisateurs authentifiés ou des plages d’IP spécifiques. Si vous essayez d’envoyer via un serveur que vous n’êtes pas autorisé à utiliser, vous obtiendrez une erreur ‘550 relay not permitted’.
Beaucoup d’organisations utilisent une configuration de ‘smart host’ : les systèmes internes envoient tout l’email sortant à un serveur central, qui gère l’authentification, la mise en file d’attente et la livraison vers Internet. Cela centralise la gestion de l’email et facilite la mise en œuvre de politiques cohérentes.
Les services email dans le cloud fonctionnent de manière similaire. Quand vous utilisez une API pour envoyer des emails, vous utilisez essentiellement leurs serveurs comme smart host. Ils gèrent la complexité SMTP, entretiennent la réputation d’IP et s’occupent des problèmes de livraison pour que vous n’ayez pas à le faire.
Codes d’erreur et leur signification
SMTP utilise des codes d’état à trois chiffres, et les comprendre aide à diagnostiquer les problèmes de livraison.
Les codes commençant par 2 indiquent un succès. 250 est la réponse ‘OK’ standard. 251 signifie que l’utilisateur n’est pas local mais que le serveur va transférer le message.
Les codes commençant par 4 sont des échecs temporaires. 421 signifie que le serveur est temporairement indisponible. 450 signifie que la boîte aux lettres est temporairement indisponible (peut-être quota dépassé). 451 est un ‘try again later’ générique. Votre serveur devrait réessayer ces cas automatiquement.
Les codes commençant par 5 sont des échecs permanents. 550 est le refus fourre-tout — utilisateur inexistant, relay denied, rejet pour raisons de politique. 551 signifie que l’utilisateur a changé d’adresse. 552 signifie que le message est trop volumineux. 553 signifie que la syntaxe de l’adresse est invalide. 554 est un ‘transaction failed’ générique.
Le deuxième chiffre apporte plus de contexte : x0x concerne la syntaxe, x1x l’information, x2x les connexions, x5x l’état du système de messagerie. Mais en pratique, le texte lisible par l’humain après le code est généralement plus informatif que le code lui-même.
Les serveurs modernes incluent souvent des codes d’état étendus (comme 5.1.1 pour ‘bad destination mailbox address’) et des explications détaillées. Lors du débogage des problèmes de livraison, regardez toujours le message d’erreur complet, pas seulement le code.
SMTP dans le monde moderne
SMTP a beaucoup évolué depuis 1982, même si le protocole de base reste reconnaissable. Plusieurs extensions sont devenues essentielles pour l’email moderne.
STARTTLS permet le chiffrement des connexions SMTP. Ce n’est pas parfait — c’est opportuniste et vulnérable aux attaques de rétrogradation — mais c’est largement déployé et apporte une protection significative contre l’écoute passive.
SMTP AUTH permet aux serveurs d’exiger une authentification avant d’accepter le mail en relais. C’est ainsi que vous vous connectez pour envoyer des emails via les serveurs de votre fournisseur.
CHUNKING et BINARYMIME permettent une transmission plus efficace des messages volumineux et du contenu binaire, en évitant le surcoût de l’encodage base64.
Malgré ces améliorations, SMTP accuse son âge. Il est synchrone et orienté connexion, ce qui passe mal à l’échelle. Il n’a pas d’authentification intégrée des expéditeurs (d’où la nécessité de SPF/DKIM/DMARC). Il est textuel, ce qui est génial pour le débogage mais inefficace pour de gros volumes.
Des propositions visant à remplacer SMTP par quelque chose de plus moderne ont été faites, mais aucune n’a pris. La base installée est trop vaste, les exigences d’interopérabilité trop strictes. Pour l’avenir prévisible, SMTP reste la lingua franca de l’email.
Frequently asked questions
Quelle est la différence entre les ports 25, 465 et 587 ?
Le port 25 sert à la communication entre serveurs. Le port 587 est pour la soumission côté client (votre client mail vers le serveur de votre fournisseur) avec STARTTLS. Le port 465 est pour l’implicite TLS (chiffré dès le départ). La plupart des fournisseurs préfèrent désormais 587 ou 465 pour les connexions client.
Pourquoi mes emails sont-ils rejetés avec 'relay denied' ?
Le serveur ne vous fait pas confiance pour envoyer via lui. Soit vous n’êtes pas authentifié, soit vous essayez d’envoyer vers un domaine que le serveur ne gère pas, soit votre IP n’est pas dans la liste autorisée. Vérifiez vos paramètres d’authentification.
Puis-je envoyer des emails directement sans utiliser un service email ?
Techniquement oui, mais c’est peu pratique. Il vous faudrait gérer la réputation d’IP, traiter les rebonds, implémenter l’authentification, gérer le rate limiting et maintenir la délivrabilité — autant de choses que les services email font pour vous.
Que se passe-t-il si le serveur du destinataire est en panne ?
Votre serveur met le message en file d’attente et réessaie périodiquement. La plupart des serveurs réessaient pendant 4–5 jours avant d’abandonner et d’envoyer un message de rebond. La cadence de réessai varie mais commence généralement élevée puis se réduit progressivement.