Résumé

  • La révision d’août 1982 définit SMTP comme un échange fiable en flux, capable de relayer du courrier même si les deux extrémités ne partagent pas le même service de transport.
  • MAIL fournit un chemin retour et RCPT un ou plusieurs chemins destinataires ; la RFC 822 définit séparément le format du message, si bien qu’un échange SMTP accepté ne prouve pas la remise en boîte ni la lecture.

Un courriel peut franchir une frontière de réseau sans que son contenu sache quel réseau l’a transporté. C’est le problème de conception que rend visible la spécification Simple Mail Transfer Protocol publiée par Jonathan B. Postel en août 1982. La RFC 821 n’impose pas de sous-système de transmission particulier. Elle exige un flux fiable et ordonné, puis décrit l’échange de commandes et de réponses entre processus SMTP.

Le relais fait partie du modèle. Si les hôtes d’envoi et de destination partagent un service de transport, l’émetteur peut joindre directement le processus SMTP destinataire. Sinon, un ou plusieurs serveurs intermédiaires peuvent relier leurs environnements de transport. Postel précise l’échelle : un service de transport peut couvrir un réseau, plusieurs réseaux ou une partie d’un réseau. « Réseau » et « environnement de transport » ne sont pas deux noms interchangeables.

La transaction rend le relais observable. L’émetteur ouvre un canal bidirectionnel et le récepteur répond. MAIL commence la transaction avec un chemin retour, destiné notamment aux avis de non-remise. Chaque commande RCPT fournit un chemin destinataire et peut être répétée. DATA transporte ensuite le message. Les réponses numériques du serveur rendent visibles les acceptations et échecs à chaque étape. L’enveloppe SMTP porte ainsi des instructions de remise qui ne se confondent pas avec le texte du message.

La comparaison avec la RFC 822, publiée le même mois, éclaire cette séparation. La RFC 822 normalise le format des messages texte de l’Internet ARPA ; la RFC 821 définit la conversation de transfert. Une ligne From: appartient à la représentation du message, tandis que MAIL FROM est un élément de la transaction SMTP. Confondre les deux reviendrait à prendre une adresse écrite dans le texte pour une preuve du chemin suivi ou de la décision de remise, ce que ces spécifications n’établissent pas.

La RFC 821 est une révision, pas l’acte de naissance de SMTP. Son en-tête remplace les RFC 788, 780 et 772 ; la RFC 788 de novembre 1981 décrivait déjà SMTP. Le plan de transition RFC 801 mentionne le service SMTP dans le contexte du changement de réseau, sans fournir de décompte d’adoption ni de mesure de remise aux utilisateurs. La date d’une révision ne dit pas quand chaque hôte l’a mise en œuvre.

Le modèle n’est pas limité à TCP. Les annexes de la RFC 821 décrivent plusieurs services, dont NCP, TCP et NITS ; l’annexe TCP attribue le numéro de socket 25 à SMTP. Cela concrétise le protocole sans faire d’un port ouvert la preuve d’un service opérationnel. Il faut encore un serveur actif, des commandes acceptées, des chemins valides, une transaction de données et un traitement local après le canal.

L’apport historique est une frontière réutilisable. SMTP définit une conversation commune pour déplacer le courrier et permet à un relais de franchir des environnements de transport ; le format du message et le comportement de la boîte locale restent d’autres questions. À la lumière de la Note 64 de Heng Lu, le protocole illustre la valeur d’une spécification commune limitée à l’interopérabilité, laissant le choix du transport et du déploiement aux systèmes qui l’exécutent. C’est une grille d’analyse, pas une intention attribuée à Postel.

Sources