Résumé

  • Dès RFC 821, RSET séparait la transaction de courrier de la session SMTP : il supprimait expéditeur, destinataires et données en attente sans autoriser le serveur à fermer la connexion.
  • Cette coupure n’est ni une annulation rétroactive ni un reçu de livraison. Elle confirme seulement qu’un message inachevé ne gouvernera pas le suivant.

Un destinataire accepté de trop

Le cas le plus instructif ne commence pas par une panne spectaculaire. Un client annonce un expéditeur, propose deux destinataires, puis apprend que le premier est accepté et le second refusé. L’application impose pourtant une règle simple : le courrier doit parvenir aux deux personnes ou ne partir vers aucune.

Le refus du second destinataire n’a pas retiré le premier. Côté serveur, l’enveloppe contient encore un chemin de retour et une adresse valide. Envoyer le contenu poursuivrait donc un message que l’application vient d’abandonner. Émettre aussitôt un nouveau MAIL superposerait une nouvelle transaction à l’ancienne. Rompre TCP fonctionnerait, mais ferait payer une nouvelle connexion pour une erreur qui ne concerne qu’une enveloppe.

RSET formule exactement l’intention manquante : cette transaction-ci doit disparaître. Le 250 OK reçu en retour établit que l’autre extrémité a franchi la même limite.

L’effacement faisait partie du protocole de 1982

RFC 821 ne traitait pas la remise à zéro comme un mécanisme tardif. Le texte exigeait déjà l’abandon de l’expéditeur, des destinataires et des données mémorisées, ainsi que le nettoyage des tampons et des tables d’état. Le serveur devait répondre positivement. La même norme précisait qu’une session pouvait contenir zéro, une ou plusieurs transactions de courrier.

Ces deux règles se complètent. Une connexion réutilisable a besoin d’une frontière qui empêche le message précédent de déborder sur le suivant. Sans cette opération, la persistance de la session serait un pari sur la mémoire identique des deux machines.

RFC 821 recommandait aussi de ne pas fermer le canal après une simple réponse d’erreur. En cas de rupture prématurée, la transaction pendante devait être annulée, sans revenir sur celles qui avaient déjà abouti. Dès l’origine, SMTP distinguait donc le canal, la tentative en cours et les messages terminés.

La confirmation compte autant que la commande

Le client peut vider sa propre file d’attente, mais il ne voit pas les tampons du serveur. Il ne sait pas si un destinataire accepté subsiste tant que le pair n’a pas répondu. La réutilisation sûre dépend ainsi d’un échange, pas d’une décision locale.

RFC 5321 fixe cet échange. Un RSET sans argument reçoit 250 OK; il peut être envoyé à tout moment; s’il n’existe aucune transaction ouverte, il n’a pratiquement aucun effet. En revanche, le serveur ne doit pas fermer la connexion à cause de cette commande. La fermeture appartient à QUIT.

Le même code 250 peut apparaître à plusieurs endroits dans SMTP, mais son objet change avec la commande. Après RSET, il atteste l’action de remise à zéro. Il ne signifie ni que le message précédent a été remis, ni que son contenu a été physiquement effacé de tout journal interne. Il garantit une propriété protocolaire : l’ancienne enveloppe ne doit plus déterminer la nouvelle.

Ce que RSET ne doit pas oublier

La formule « nettoyer les tampons et tables d’état » pourrait faire croire à une amnésie complète. Le reste de la norme en délimite la portée.

La connexion TCP reste ouverte. Le serveur ne recommence pas sa bannière. Les capacités négociées par EHLO n’ont pas à être redécouvertes pour chaque enveloppe abandonnée. Une protection TLS ne disparaît pas. Une identité déjà authentifiée ne redevient pas anonyme. Les compteurs d’abus et les traces d’audit ne sont pas des destinataires ou des données de courrier.

Un nouvel EHLO accepté produit bien un effet de remise à zéro équivalent sur la transaction. RFC 5321 ajoute toutefois qu’il est plus coûteux, puisqu’il relance aussi le travail de salutation et de capacités. L’équivalence porte sur l’enveloppe ouverte, pas sur la fonction complète des deux commandes.

Le passage sous TLS illustre une frontière plus large encore. RFC 3207 impose, après la négociation cryptographique, d’abandonner les connaissances acquises avant celle-ci et de refaire EHLO. Le contexte de sécurité vient de changer; la session doit donc reconstruire ce qu’elle croit savoir. Une transaction simplement abandonnée n’exige pas ce grand nettoyage.

Une transaction terminée reste terminée

RSET agit sur la transaction courante et incomplète. Il ne remonte pas le temps.

RFC 5321 décrit une transaction comme la séquence ouverte par MAIL, poursuivie par un ou plusieurs RCPT, puis par le transfert de contenu. Après l’acceptation finale des données, la responsabilité correspond à une transaction achevée. Un reset ultérieur prépare une nouvelle enveloppe; il ne transforme pas cette acceptation en refus.

Cette limite interdit d’imaginer la session comme une transaction de base de données qui engloberait tous les messages. Chaque courrier possède son propre résultat. La persistance de la connexion ne rend pas les résultats réversibles collectivement.

Le pipeline n’a pas aboli les frontières

RFC 2920 a permis de regrouper certaines commandes pour réduire l’attente sur les liaisons lentes. RSET, les commandes d’expéditeur et RCPT TO peuvent apparaître dans un groupe. Le texte autorise même la fin du contenu d’un message et la séquence reset/nouvel expéditeur du suivant dans le même envoi TCP.

Cette proximité temporelle ne fusionne pas les transactions. Chaque commande conserve sa réponse, dans le même ordre. Le client doit distinguer l’acceptation ou le refus du contenu précédent, la confirmation du reset et le résultat du nouvel expéditeur. Vider un tampon local ne prouve jamais que le serveur a traité les trois étapes.

Le gain de vitesse dépend donc d’une comptabilité plus stricte. Lorsque plusieurs frontières sont en vol, le numéro de la réponse devient une preuve de l’état auquel elle se rapporte.

Nettoyer un transfert devenu indéterminé

L’extension CHUNKING rend cette fonction encore plus visible. RFC 3030 autorise l’envoi du contenu par blocs BDAT. Après certaines erreurs de séquence — un bloc après BDAT LAST, le mélange de DATA et BDAT, ou l’échec d’un bloc laissant l’état indéterminé — le client doit effectuer RSET avant de continuer.

Le reset écarte alors les segments déjà associés à la transaction. Il ne prétend pas que la session n’a jamais existé; il rétablit un point à partir duquel une autre enveloppe peut être interprétée sans hériter de fragments précédents.

L’authentification révèle une limite complémentaire. RFC 4954 interdit AUTH au milieu d’une transaction et impose 503. Une identité de session ne doit pas être greffée entre l’expéditeur, les destinataires et les données d’un message. Il faut d’abord fermer proprement la portée transactionnelle.

Une forme disciplinée de récupération

De nombreux protocoles hésitent entre ignorer une faute et détruire toute la connexion. RSET occupe l’espace utile entre ces extrêmes. Il nomme l’objet abandonné, conserve ce qui peut l’être et attend l’accord du pair.

Son histoire montre que la robustesse ne vient pas de l’absence d’état. Elle vient de la capacité à attribuer chaque état à une portée précise. SMTP peut oublier un message sans oublier la conversation; il peut poursuivre la conversation sans réécrire le résultat des messages déjà achevés.

Sources