Summary

  • La RFC 1845, expérimentale en 1995, faisait annoncer CHECKPOINT par le serveur SMTP et ajouter TRANSID à MAIL FROM pour identifier une transmission particulière.
  • Son exemple donne la réponse 355 avec un décalage de 6 135 octets. Le compteur porte sur les octets du message réellement stockés, sans les commandes d’enveloppe ni les octets ajoutés par le bourrage de points SMTP.

Le message était gros, la connexion moins solide. SMTP tel que le décrivait sa spécification d’origine savait recommencer l’envoi après une rupture, mais pas retrouver le milieu d’une transaction interrompue. Chaque tentative perdue pouvait donc remettre tout le contenu sur le fil. En septembre 1995, D. Crocker, N. Freed et A. Cargille ont proposé un compte plus précis : que le serveur dise ce qu’il avait effectivement gardé, et que l’expéditeur n’envoie que le reste. Le document était expérimental; son dialogue d’exemple illustre les réponses du protocole.

La reprise commence par un nom. Après EHLO, le serveur annonce CHECKPOINT s’il accepte ce service. L’expéditeur place alors TRANSID sur la commande MAIL FROM. Cet identifiant sensible à la casse désigne la copie en cours de transmission sur ce lien, pas simplement le message tel qu’il apparaîtra dans une boîte aux lettres. Une même lettre peut être dédoublée et partir par plusieurs chemins. Son Message-ID serait alors partagé par plusieurs transactions distinctes. RFC 1845 demande au serveur de traiter TRANSID comme une chaîne opaque : sa fonction est de retrouver le bon travail en cours, pas d’interpréter un nom séduisant.

Il faut ensuite que la promesse survive à la panne. Le serveur enregistre l’identifiant et son état le plus récent sur un stockage non volatil. Les auteurs recommandent de garder l’état d’une transaction interrompue au moins 48 heures, tout en laissant la durée effective à l’administrateur. Le client attend que l’ancienne connexion soit libérée, consulte le DNS, essaie d’abord l’adresse du serveur initial si elle reste admissible, puis les autres adresses possibles. Si l’un de ces autres serveurs ne possède pas le point de reprise, le client retransmet toute la transaction. Il n’attend pas indéfiniment que l’ancienne machine revienne.

Dans l’exemple, le client répète exactement MAIL FROM avec le même TRANSID. Le serveur répond 355 6135 is the transaction offset. Les 6 135 octets sont les données du message reçues et stockées. Les commandes MAIL FROM et RCPT TO ne figurent pas dans le compte. Les octets que SMTP ajoute pour protéger les lignes commençant par un point n’y figurent pas non plus. Quand le transfert utilise DATA, le point de reprise doit tomber au début d’une ligne. On ne peut donc pas ouvrir un fichier quelconque à sa position 6 135 et déclarer l’affaire réglée : la référence est le flux canonique des données SMTP.

Le dernier acte est presque comique par sa simplicité. Le client envoie DATA, saute la partie déjà détenue par le serveur, finit le message et reçoit 250 OK. La RFC autorise même un expéditeur à reconstruire localement le flux complet puis à ne rien émettre avant le décalage indiqué. L’astuce évite une nouvelle traversée du réseau sans déléguer au hasard la définition du décompte.

Ce reçu de 6 135 octets a un périmètre net. Il parle d’un état stocké pour une transmission identifiée. Il ne vaut ni accusé de lecture par une personne ni identité universelle du courrier. C’est précisément cette modestie qui lui donne sa force : après la coupure, l’expéditeur dispose d’une preuve assez étroite pour poursuivre sans refaire tout le trajet.