SMTP : transport, file d’attente et responsabilité de livraison

Le Simple Mail Transfer Protocol (SMTP) achemine un message d’un processus de messagerie au suivant. Le client se connecte à un serveur, interroge ses capacités, indique l’expéditeur et les destinataires de l’enveloppe, puis transfère seulement ensuite le contenu du message. Le serveur répond à chaque étape par un code numérique. De cette séquence apparemment simple naissent le routage, la mise en file d’attente, les nouvelles tentatives et la question décisive de savoir quel serveur assume actuellement la responsabilité du message (RFC 5321, sections 1 et 2).

Pour les administrateurs de messagerie, la propriété décisive réside dans le transfert de responsabilité. L’établissement réussi d’une connexion TCP signifie seulement qu’un écouteur est accessible. Un RCPT TO accepté réserve un destinataire au sein de la transaction en cours. Seule une conclusion positive après le contenu complet du message transfère au système SMTP destinataire la responsabilité de livrer le message ou de signaler ultérieurement une erreur à l’expéditeur de l’enveloppe (RFC 5321, sections 4.1.1.4 et 6.1). L’ID de file d’attente, le code de réponse, le MTA distant, l’état du destinataire et la trace Received ne sont donc pas de simples détails de journalisation, mais la chaîne de preuve d’une livraison.

L’explication suit un message depuis le client émetteur, via la session SMTP, l’enveloppe et la file d’attente, jusqu’au serveur de messagerie suivant ou à la boîte aux lettres. DNS, les nouvelles tentatives, les codes d’état, la sécurité et le diagnostic sont approfondis là où ils influencent le cheminement.

Rôles et responsabilités

SMTP ne connaît initialement que les rôles de client et de serveur. Dans une chaîne de livraison réelle, ces rôles changent à chaque saut : un agent de transfert de courrier reçoit un message en tant que serveur, le stocke dans sa file d’attente et devient lui-même client lors de la tentative de livraison suivante. Seul ce changement de rôle permet de lire correctement les journaux et les responsabilités (RFC 5321, section 2.3.3, RFC 5598, section 4, RFC 6409, section 2.1).

Le MSA n’est pas simplement un MTA sur un autre port. La soumission de messages sépare l’injection contrôlée de nouveaux messages du transfert ouvert entre domaines de messagerie. Un MSA peut notamment contrôler les droits d’expéditeur, compléter les champs obligatoires manquants et adapter les messages aux règles locales ; un MTA en aval ne devrait en principe pas modifier arbitrairement le contenu de messages finalisés (RFC 6409, sections 1, 6 et 8). Cette limite est particulièrement pertinente pour les signatures DKIM : toute modification ultérieure d’en-têtes signés ou du corps peut invalider la signature.

Le graphique montre des limites logiques. Le MSA, le MTA sortant, la passerelle et le MTA entrant peuvent fonctionner comme des services distincts, être réunis sur un même système ou être masqués par un fournisseur cloud. Les normes ne prescrivent aucune architecture de processus. Sur le plan administratif, la séparation reste néanmoins nécessaire, car chaque transfert accepté peut créer une nouvelle file d’attente, un nouvel état de nouvelle tentative et un nouveau responsable.

Enveloppe et contenu du message

Avant d’examiner le dialogue en détail, il faut distinguer deux zones de données : l’enveloppe pour le transport et le contenu du message pour les destinataires et les programmes de messagerie. L’enveloppe consiste en un chemin de retour issu de MAIL FROM et un ou plusieurs chemins de transfert issus de RCPT TO. Le contenu suit DATA et comprend une zone d’en-tête conforme à l’Internet Message Format ainsi que le corps, souvent avec une structure MIME (RFC 5321, section 2.3.1, RFC 5322, section 2.1).

Les serveurs SMTP ne peuvent pas déduire la route finale de To:, Cc: ou From:. Inversement, les adresses d’enveloppe ne doivent pas apparaître dans l’en-tête du message. C’est pourquoi Bcc, les listes de diffusion, les redirections, SRS et les adresses de rebond distinctes fonctionnent. Cette séparation explique aussi pourquoi un message peut sembler visuellement provenir de ceo@example.ch dans le client, alors que son expéditeur d’enveloppe utilise un autre domaine. SPF considère le chemin SMTP ; DMARC établit en outre un lien avec le From: visible. Les détails de ces vérifications sont traités dans l’authentification des e-mails (RFC 5321, annexe C, RFC 5322, section 3.6).

Un chemin de retour vide est transmis sous la forme MAIL FROM:<>. Il évite les boucles de rapports d’erreur et est obligatoire pour les Delivery Status Notifications. Un serveur qui refuse systématiquement les expéditeurs vides endommage donc le chemin de retour du système de messagerie (RFC 5321, section 3.6.3).

Session et transaction SMTP

Une session SMTP s’exécute sur une connexion TCP; plusieurs messages peuvent y suivre sous forme de transactions de courrier distinctes. Le serveur commence par un message d’accueil 220 ; le client s’identifie avec EHLO et reçoit une liste de capacités ESMTP propres à la session. Une transaction se compose ensuite de MAIL, d’au moins un RCPT accepté et de DATA ou d’un substitut négocié tel que BDAT (RFC 5321, sections 3.1 et 4.1).

1. Connexion et message d’accueil : le client se connecte ; le serveur répond avec 220. S’il tarde ou refuse déjà à ce stade, aucune transaction de courrier n’existe encore.
2. Négociation des capacités : EHLO client.example place les deux côtés dans l’état initial et fournit des extensions telles que SIZE, STARTTLS, PIPELINING ou SMTPUTF8. Un client ne peut pas supposer qu’un autre nœud du cluster ou une session ultérieure offre les mêmes capacités.
3. Mise à niveau TLS facultative : après un STARTTLS réussi, l’état SMTP et les capacités précédemment apprises sont abandonnés. Le client envoie de nouveau EHLO dans le canal protégé (RFC 3207, section 4).
4. Expéditeur de l’enveloppe : MAIL FROM ouvre une transaction et vide les précédents tampons d’enveloppe et de données. Des paramètres ESMTP comme SIZE, BODY ou SMTPUTF8 sont associés à cette commande.
5. Destinataires : chaque RCPT TO reçoit une réponse individuelle. Un serveur peut accepter deux destinataires et rejeter définitivement un troisième ; le client envoie alors le contenu pour le sous-ensemble accepté.
6. Contenu : après DATA, le serveur répond 354 lorsqu’il est prêt. Le client transfère les en-têtes et le corps sous forme de lignes terminées par CRLF, échappe les points en début de ligne et termine par une ligne composée uniquement de ..
7. Conclusion : la réponse suivant ce marqueur de fin de données décide si le serveur prend en charge le message dans son ensemble pour les destinataires précédemment acceptés. RSET abandonne la transaction en cours sans fermer la session ; QUIT la ferme proprement.

SMTP est orienté lockstep, mais ESMTP-PIPELINING peut envoyer des groupes de commandes autorisés sans attendre chaque réponse individuelle. Les réponses restent dans l’ordre de réception et doivent toujours être correctement associées à chaque commande (RFC 2920). Une capture de paquets montrant plusieurs lignes MAIL-/RCPT directement successives n’est donc pas automatiquement une violation du protocole.

Le dialogue est ainsi complet, mais la responsabilité de livraison n’est pas encore clarifiée. Elle ne change qu’avec une réponse bien précise du serveur destinataire.

Limite d’acceptation : 250 après End-of-Data

La limite SMTP la plus importante se situe après le contenu du message. Un 250 en réponse à MAIL FROM n’accepte que le chemin de retour. Un 250 en réponse à RCPT TO accepte un destinataire pour la transaction en cours. Seul un 250 après le marqueur End-of-Data signifie que le serveur a assumé la responsabilité du message. Un système correct doit ensuite soit le livrer, soit produire un rapport de non-livraison si une erreur est détectée ultérieurement ; le client expéditeur peut retirer sa copie locale de la responsabilité de livraison active (RFC 5321, sections 4.1.1.4 et 6.1).

Cette sémantique rend la dernière partie du dialogue critique. Si la connexion est interrompue après le point mais avant la réception complète d’une réponse, le client ne sait pas avec certitude si le serveur a stocké le message. Il doit pouvoir tenter à nouveau la livraison ; des doublons sont donc possibles. SMTP n’offre aucune garantie globale d’exécution exactement une fois. Les systèmes nécessitent par conséquent un suivi idempotent via l’ID de file d’attente, Message-ID, le destinataire, l’heure, la taille et, le cas échéant, une référence de transaction propriétaire, sans assimiler ces identifiants.

Les filtres de contenu, la DLP, l’analyse antimalware ou la signature DKIM devraient être intégrés à la chaîne d’acceptation de manière à ce que le serveur sache, avant la réponse positive finale, s’il peut assumer une responsabilité persistante. Un proxy en amont qui signale prématurément 250 puis perd le message en interne ne peut plus renvoyer l’erreur au client SMTP d’origine. C’est précisément ici qu’une architecture doit déterminer si l’acceptation est confirmée uniquement après une écriture durable, après réplication, après analyse ou déjà après la remise à un courtier interne. Il s’agit d’une propriété de produit, non d’une exigence de la norme SMTP, et elle doit être étayée par la documentation du fabricant ainsi que par des tests de défaillance et de restauration.

Après l’acceptation, le MTA doit décider vers où envoyer ensuite le message. Pour le courrier Internet, cette décision commence dans le DNS.

Routage via DNS et MX

Pour une livraison Internet directe, le MTA expéditeur détermine la prochaine destination à partir du domaine du destinataire de l’enveloppe. Il interroge DNS pour les enregistrements MX, trie les candidats par valeur de préférence croissante et résout les noms Exchange sélectionnés en adresses A ou AAAA. Plusieurs destinations de même préférence constituent des candidats équivalents ; un MX de secours à valeur plus élevée n’est pas une réplique de la file d’attente primaire, mais un destinataire SMTP indépendant avec sa propre politique et sa responsabilité de livraison (RFC 5321, section 5).

En l’absence de jeu d’enregistrements MX, SMTP traite historiquement le domaine comme un MX implicite pointant vers le nom de domaine lui-même et tente ses adresses. Un Null MX explicite avec la préférence 0 et Exchange . indique en revanche qu’un domaine n’accepte pas d’e-mails (RFC 7505). NXDOMAIN, NODATA, SERVFAIL, les échecs de validation DNSSEC et un MX accessible sans service SMTP fonctionnel sont des états distincts et doivent rester séparément visibles dans le motif de mise en file d’attente.

Les chemins de messagerie internes utilisent fréquemment des next hops statiques, des smarthosts, des connecteurs ou des tables de routage au lieu de la sélection MX publique. Le destinataire de l’enveloppe reste néanmoins l’adresse de livraison ; la politique de routage locale décide seulement à quel système suivant elle est confiée. Pour chaque diagnostic, trois noms doivent donc être consignés : domaine du destinataire, nom du next hop sélectionné et adresse IP effectivement connectée.

Même lorsqu’il connaît la destination, le MTA ne peut pas toujours livrer immédiatement. Les erreurs temporaires conduisent donc à la file d’attente plutôt qu’à la perte du message.

File d’attente, nouvelles tentatives et DSN

Un MTA complet est un système store-and-forward. S’il ne peut pas joindre immédiatement le saut suivant ou si celui-ci répond temporairement, le MTA conserve le message et l’enveloppe dans une file d’attente persistante, planifie une nouvelle tentative et gère l’état par destinataire. RFC 5321 exige une stratégie de nouvelles tentatives, mais ne prescrit pas un algorithme unique pour tous les produits. Elle recommande des répétitions différées, une notification en cas de retard prolongé et une conservation de plusieurs jours avant l’abandon définitif (RFC 5321, section 4.5.4). Les valeurs produit telles que le backoff, la durée de vie maximale de la file d’attente, le parallélisme et la concurrence par destination doivent donc être lues dans la configuration MTA concernée.

Un enregistrement de file d’attente pertinent contient au minimum :

• le contenu de message immuable ou un blob référencé ;
• l’expéditeur de l’enveloppe et l’état de chaque destinataire de l’enveloppe ;
• l’heure d’acceptation, la prochaine tentative et la limite d’expiration ;
• le transport choisi, le next hop, la dernière adresse et la décision TLS/de politique ;
• le dernier code SMTP et code d’état étendu avec le texte distant ;
• l’ID de file d’attente local ainsi que des ID corrélables provenant de sauts en amont ou en aval ;
• les états active, deferred, hold, delivered, bounced et quarantined ;
• l’état de réplication, du système de fichiers ou de la base de données si l’acceptation doit être hautement disponible.

Les erreurs temporaires font normalement l’objet de nouvelles tentatives. Les erreurs permanentes avant sa propre acceptation sont renvoyées de manière synchrone au client SMTP expéditeur. Les erreurs permanentes après sa propre acceptation donnent lieu à une Delivery Status Notification (DSN) vers le chemin de retour. RFC 3464 définit à cet effet un message multipart/report lisible par machine, avec des champs par message et par destinataire tels que Reporting-MTA, Final-Recipient, Action, Status et, en option, Remote-MTA ou Diagnostic-Code (RFC 3464).

Un rebond n’est pas automatiquement digne de confiance. Les DSN peuvent être falsifiées, divulguer le contenu d’origine ou créer du backscatter lorsque l’expéditeur de l’enveloppe a été défini de manière abusive. Une passerelle devrait rejeter les messages non valides, si possible pendant la session SMTP initiale, plutôt que de les accepter puis de les renvoyer ultérieurement à une adresse potentiellement falsifiée.

Codes de réponse et signification pour le diagnostic

Les réponses SMTP possèdent un code de base à trois chiffres. La première plage de chiffres décrit l’état immédiat ; le texte est destiné aux humains et peut être spécifique au produit (RFC 5321, section 4.2).

Les Enhanced Status Codes complètent le format x.y.z. x indique succès, temporaire ou permanent ; y désigne la catégorie générale de défaillance et z le détail. Ainsi, 5.1.1 relève de la classe d’adresse et désigne une boîte aux lettres cible inexistante, tandis que 4.4.x classe les problèmes de réseau et de routage. Les significations enregistrées figurent dans le registre IANA des Enhanced Status Codes ; un texte de fabricant ne doit pas être interprété à l’encontre de la sémantique numérique (RFC 3463, RFC 5248).

Le même code peut concerner quelque chose de différent selon la phase du protocole. Un 550 sur MAIL FROM rejette l’expéditeur ou son autorisation, sur RCPT TO un destinataire spécifique, et après le contenu la transaction complète. Un ticket sans hôte distant, heure, phase, codes de base, code étendu et texte de réponse complet est donc incomplet.

ESMTP et extensions

Extended SMTP utilise EHLO pour négocier les capacités par connexion. L’IANA tient le registre contraignant des SMTP Service Extensions. Un client ne peut utiliser une extension que si elle a été proposée dans la session actuelle ; après STARTTLS, il doit interroger à nouveau la liste.

La dérive des capacités entre nœuds de cluster est un problème opérationnel fréquent. Si seuls certains écouteurs proposent SMTPUTF8, la même valeur SIZE ou des mécanismes AUTH identiques, des échecs de livraison apparemment aléatoires surviennent. La supervision ne devrait donc pas contrôler uniquement une VIP, mais chaque chemin backend pertinent avec le même SNI, nom EHLO et réseau source.

Jusqu’ici, il s’agissait du transport entre serveurs. La soumission par des utilisateurs et applications constitue un service distinct avec d’autres ports, identités et risques d’abus.

Soumission, relais et authentification

Le port 25 sert au transfert MTA à MTA. Le port 587 désigne la soumission de messages ; le port 465 est enregistré pour la soumission avec TLS actif dès le début sous le nom de service submissions. Le port 465 n’est pas un port MX alternatif : la livraison MX publique ne connaît aucune indication de port et utilise le port 25 (RFC 6409, sections 1 et 3, RFC 8314, section 7.3, IANA Service Name and Port Number Registry).

Un service de soumission associe authentification et autorisation. AUTH utilise SASL et peut transporter des mécanismes tels que PLAIN sur TLS ou des jetons Bearer basés sur OAuth. L’identité authentifiée, l’identité d’autorisation demandée et l’expéditeur d’enveloppe autorisé sont des grandeurs distinctes. Une connexion réussie n’autorise pas automatiquement l’utilisation de tout domaine expéditeur ou de tout expéditeur d’enveloppe (RFC 4422, section 3.4, RFC 4954, RFC 7628).

Un relais ouvert apparaît lorsqu’un MTA transmet des messages depuis des sources non autorisées vers des destinations non locales. Une configuration sûre décide donc séparément des domaines de destinataires locaux, des réseaux sources de confiance, de la soumission authentifiée et des connecteurs explicites. Une liste d’autorisation IP est une autorisation réseau et ne remplace pas une identité utilisateur ; avec NAT, une sortie cloud ou des relais partagés, elle peut autoriser un ensemble d’expéditeurs bien plus large que prévu.

Ce n’est qu’une fois le rôle et le port définis que la politique TLS appropriée peut être déterminée : la soumission doit être protégée et authentifiée, tandis que le transport MTA ouvert nécessite des politiques de domaine supplémentaires.

Politique TLS pour SMTP

STARTTLS protège la connexion individuelle lorsque les deux parties effectuent la mise à niveau. Dans le transfert MTA ouvert, STARTTLS seul reste toutefois opportuniste : un attaquant actif peut supprimer l’offre ou manipuler les destinations DNS, et un expéditeur sans politique supplémentaire peut revenir au clair. DANE pour SMTP lie les données TLSA au choix de la destination MX via DNSSEC. MTA-STS publie via DNS et HTTPS une politique MX et TLS fondée sur PKIX. TLS-RPT signale les erreurs agrégées relatives à de telles politiques. L’article TLS traite les détails cryptographiques, les chaînes de certificats et les procédures de test.

La soumission est différente : ici, le client et le service sont administrativement associés, et l’utilisateur ne doit pas revenir silencieusement au clair. RFC 8314 recommande le TLS implicite pour la soumission et l’accès au courrier et exige que le clair soit considéré comme obsolète. SMTP AUTH avec des mécanismes de mot de passe ou Bearer nécessite un canal suffisamment protégé ; un serveur ne devrait même pas proposer de mécanismes faibles avant STARTTLS (RFC 8314, section 3, RFC 4954, section 14).

Livraison locale avec LMTP

Le Local Mail Transfer Protocol (LMTP) utilise un dialogue semblable à SMTP pour la remise à un système sans propre file d’attente de courrier à long terme, par exemple un service de boîtes aux lettres. La différence essentielle apparaît après le contenu du message : LMTP fournit une réponse finale distincte pour chaque destinataire préalablement accepté. Le stockage de courrier peut ainsi livrer avec succès à un destinataire et rejeter un autre à cause d’un quota ou d’une erreur locale, sans que le MTA en amont doive traiter toute la transaction de manière uniforme (RFC 2033, section 4.2).

LMTP ne déplace pas la responsabilité hors du système. Si le stockage de courrier rejette temporairement un destinataire, le MTA en amont doit conserver ce destinataire dans sa file d’attente. Avec les sockets Unix, le chemin réseau IP disparaît certes, mais la nécessité de surveiller les autorisations des sockets, la contre-pression, les délais d’attente, les réponses par destinataire et la limite de persistance demeure.

Pile d’implémentation et de technologies

SMTP définit le protocole sur le fil, non l’architecture logicielle interne. En pratique, un MTA associe plusieurs couches techniques :

Les implémentations organisent ces couches différemment. Postfix répartit la réception, le nettoyage, le gestionnaire de file d’attente et les agents de livraison en processus coopérants et distingue incoming, active et deferred comme états de file d’attente. Exim stocke l’enveloppe/les en-têtes et le corps dans le spool, puis laisse les queue runners traiter les tentatives de livraison arrivées à échéance. Apache James s’exécute sur la JVM et associe serveur de protocole, file d’attente et pipeline Mailet avec des backends de stockage interchangeables. Tous trois parlent SMTP, mais leurs modèles de processus, de file d’attente, d’extensions et de récupération ne sont pas interchangeables.

Le langage de programmation et le runtime influencent le packaging, le processus de correctifs, le profil mémoire et l’extensibilité, non la sémantique du dialogue SMTP. Postfix est construit avec une chaîne d’outils C native pour les systèmes de type Unix (Postfix INSTALL) ; la documentation Exim cite ANSI C comme langage d’implémentation. Apache James se décrit en revanche comme une plateforme Java/Scala sur la JVM (Apache James). Un service cloud peut représenter les mêmes rôles RFC via des microservices propriétaires, des files d’attente distribuées et des API. Pour la validation opérationnelle, il faut donc documenter non seulement les capacités EHLO, mais aussi l’engagement de persistance, le modèle de nouvelles tentatives, l’export de file d’attente, la sauvegarde, la gestion des clés, les limites de mise à l’échelle et les domaines de défaillance.

Du déroulement de livraison découle une méthode de recherche d’erreurs fixe : déterminer la destination, vérifier la connexion et le dialogue SMTP, évaluer la réponse, puis suivre la file d’attente et le saut suivant.

Diagnostic du DNS à la file d’attente

Un diagnostic SMTP fiable suit le chemin de livraison et sépare les niveaux d’observation. Les tests doivent être réalisés avec des domaines de test et des destinataires autorisés ; des serveurs tiers ne doivent pas être utilisés abusivement pour des tests de relais, de validation d’adresses ou de charge.

Déterminer la cible MX et les adresses

Resolve-DnsName et dig affichent les données DNS publiées. La sortie doit être vérifiée quant à la préférence, au Null MX, aux chaînes CNAME, à IPv4/IPv6 et au résolveur effectivement interrogé. Une réponse DNS ne prouve ni le fonctionnement de l’écouteur ni celui de TLS.

Vérifier l’accessibilité TCP du saut sélectionné

Test-NetConnection et nc vérifient ici uniquement la résolution DNS et l’établissement TCP. Une réussite sur le port 25 ne dit pas si le message d’accueil SMTP arrive à temps ; une réussite sur 587 ou 465 ne dit rien de la politique TLS et AUTH.

Vérifier STARTTLS, EHLO et le certificat

openssl s_client exécute le dialogue en clair requis avec -starttls smtp, définit le nom SMTP-EHLO avec -name et SNI avec -servername. -verify_hostname et -verify_return_error transforment le simple handshake en test explicite de nom PKIX. Le résultat décrit OpenSSL avec son magasin de confiance, et non automatiquement la politique du MTA de production.

Tester de manière contrôlée l’enveloppe et la phase de réponse

swaks journalise les commandes et réponses SMTP et peut terminer délibérément le test après RCPT, sans envoyer de données de message. L’outil ne fait pas partie du système sous Windows ; swaks.exe ou une installation Perl doit provenir d’une source contrôlée. Un test RCPT ne doit être effectué que contre des systèmes et adresses propres ou explicitement autorisés, car il déclenche des politiques, des annuaires et des limites de débit.

Examiner les écouteurs et les paquets sur le serveur

Get-NetTCPConnection et ss associent les écouteurs et états TCP à des processus locaux. pktmon et tcpdump capturent des paquets ; les captures de production peuvent contenir des adresses d’enveloppe, des contenus non chiffrés et des données d’authentification, et doivent être protégées, limitées et supprimées en conséquence. Wireshark convient à l’analyse de TCP, SMTP et des handshakes TLS, mais ne remplace ni les journaux de file d’attente ni les journaux de politique.

Associer les erreurs à une limite

Observabilité et modèle opérationnel

Un moniteur SMTP ne devrait pas seulement envoyer un e-mail de test. Il doit rendre visibles les différents états du système :

• latence distincte du message d’accueil, EHLO, STARTTLS, AUTH et End-of-Data ;
• connexions, sessions, transactions actives et refus par phase ;
• capacités ESMTP proposées par écouteur et backend ;
• taux d’acceptation, nombre de destinataires, taille de message et latence d’écriture durable ;
• volume de file d’attente par âge, destination, transport, état et dernière erreur ;
• taux de nouvelles tentatives, message le plus ancien, livraisons arrivant à expiration et génération de DSN ;
• cible DNS, IP connectée, IPv4/IPv6, mode TLS, chiffrement et résultat de politique ;
• codes de réponse comme champs structurés plutôt que seulement comme texte libre ;
• corrélation de l’ID edge, de l’ID interne de file d’attente, de l’ID de file d’attente distante, de Message-ID et du destinataire ;
• état LMTP/boîte aux lettres par destinataire ainsi que chemins de quarantaine et de libération ;
• capacité du spool, latence d’E/S, état de la base de données ou du courtier et retard de réplication ;
• limites de protection pour les journaux et captures, car l’enveloppe, les en-têtes et les contenus contiennent des données personnelles ou confidentielles.

Les sauvegardes de file d’attente seules ne suffisent pas. La restauration doit prendre en compte la configuration, les tables de routage, les certificats et clés, les métadonnées de file d’attente, les blobs de messages, la quarantaine, l’état de signature et l’idempotence. Après une restauration, une copie déjà livrée à un destinataire ne doit pas être renvoyée sans contrôle ; en même temps, les destinataires encore ouverts d’un message partiellement livré ne doivent pas être perdus. Les RPO et RTO doivent donc être définis par composant d’état et testés avec une véritable file d’attente comportant plusieurs destinataires.

Histoire technique

SMTP est issu de procédures de messagerie ARPANET antérieures. La RFC 821 de Jon Postel a normalisé en 1982 le modèle encore reconnaissable aujourd’hui, composé de SMTP émetteur, SMTP récepteur, MAIL, RCPT, DATA et réponses à trois chiffres. Le format de message a été décrit séparément la même année dans la RFC 822. Cette séparation entre protocole de transfert et format de message a été conservée.

Avec MIME, SMTP a dépassé le simple texte 7 bits. Le framework ESMTP a introduit EHLO, des capacités enregistrées et des paramètres sur MAIL et RCPT ; sa version de 1995 figurait dans la RFC 1869. Des extensions fondées sur celui-ci, telles que SIZE, 8BITMIME, PIPELINING, AUTH, STARTTLS, CHUNKING, DSN et, plus tard, SMTPUTF8, ont développé le protocole de façon incrémentale sans créer une pile parallèle « SMTP 2 ».

La RFC 2821 a consolidé SMTP en 2001 et remplacé RFC 821 ainsi que plusieurs documents complémentaires. La RFC 5321 a suivi en 2008 comme nouvelle consolidation ; l’Internet Message Format correspondant figure dans la RFC 5322. La soumission de messages a d’abord été spécifiée séparément, puis consolidée dans RFC 6409. L’évolution technique s’est donc poursuivie par des rôles plus clairs, des registres d’extensions, des adresses internationalisées, des rapports de livraison et des politiques de transport, tandis que le dialogue fondamental à états est resté compatible.

Les architectures logicielles ont également évolué de façon divergente. La compatibilité historique avec Sendmail a façonné les interfaces locales en ligne de commande ; Postfix a misé sur des processus coopérants séparés par privilèges et des files d’attente explicites, Exim sur une approche très configurable de routeur/transport et de spool, et les systèmes JVM comme Apache James ont rendu le traitement extensible via des composants et des Mailets. Les plateformes cloud répartissent les mêmes rôles logiques entre frontends, courtiers, services de politique et files d’attente régionales. Pour les administrateurs, la sémantique RFC demeure donc le dénominateur commun, tandis que la persistance, la mise à l’échelle et la récupération doivent toujours être étayées de manière spécifique au produit.