Résumé

  • Après l’annonce PIPELINING dans EHLO, un client pouvait envoyer un groupe de commandes sans attendre chaque réponse, tout en conservant une décision distincte pour chacune.
  • Le gain exigeait de compter les réponses dans l’ordre, de reconnaître les réponses multilignes, de borner les groupes par l’état et la fenêtre TCP, et de garantir que le serveur ne jetterait aucun octet déjà reçu.

Le délai venait de l’aller-retour

Une session SMTP ordinaire avance comme un interrogatoire patient : identification, réponse ; expéditeur, réponse ; destinataire, réponse ; puis demande de transmettre les données. RFC 2920 constatait que, sur les liaisons à forte latence, cette alternance pouvait dominer la durée de la connexion. Les commandes étaient courtes, mais chacune attendait que la distance soit parcourue deux fois.

Le pipelining autorisa plusieurs questions à partir avant le retour de la première réponse. Il ne transforma pas ces questions en une opération unique. Le serveur continua de statuer sur chaque commande. L’amélioration reposait sur plusieurs intentions simultanément en suspens.

Ce choix déplaça le problème. En mode pas-à-pas, la réponse suivante appartient presque forcément à l’unique commande ouverte. Avec un groupe, l’appartenance doit être reconstruite sans ambiguïté.

Une capacité, pas une supposition

On aurait pu croire que TCP suffisait : les octets arrivent dans l’ordre, donc tout serveur SMTP devrait pouvoir lire plusieurs lignes. Les implémentations déployées contredisaient cette déduction.

RFC 2920 décrit des serveurs qui perdaient des octets lors d’un transfert de connexion entre processus, vidaient le tampon d’entrée après l’échec d’une commande, ou confondaient le dernier résultat RCPT TO avec l’état de tous les destinataires. Le protocole théorique permettait la séquence ; le code en service ne la préservait pas toujours.

Le client devait donc commencer par EHLO. Il ne pouvait choisir le pipelining qu’après une réponse 250 contenant PIPELINING. Le registre SMTP de l’IANA conserve ce mot-clé, sans paramètre, sous l’autorité de RFC 2920. Il ne publie ni taille de lot, ni vitesse, ni engagement de livraison.

Cette sobriété laisse la décision locale. Le serveur annonce une propriété qu’il sait tenir ; le client peut l’utiliser, former de petits groupes ou rester pas-à-pas.

La frontière suivait les changements d’état

RSET, les commandes d’expéditeur et RCPT TO peuvent se trouver au milieu d’un groupe. En revanche, RFC 2920 place notamment EHLO, DATA, VRFY, EXPN, TURN, QUIT et NOOP en dernière position. Leur résultat oblige le client à adapter la suite ; il ne peut pas écrire cette suite comme si la réponse était déjà connue.

La règle sépare ce qui peut être proposé en parallèle de ce qui crée une dépendance. Plusieurs destinataires peuvent recevoir des verdicts distincts. DATA ouvre ou refuse une nouvelle phase. NOOP, précisément parce qu’il ne demande presque rien, peut servir de point de synchronisation.

Des extensions ultérieures peuvent définir leurs propres règles. Leur silence ne donne pas le droit d’insérer une nouvelle commande n’importe où.

L’ordre attribuait les réponses

Supposons, à titre d’exemple, qu’un client envoie un expéditeur, trois destinataires et DATA. Cinq réponses sont attendues. Plusieurs peuvent porter le même code ; leur texte peut varier. Chercher l’appartenance dans le code ou la phrase serait fragile et, surtout, contraire à RFC 2920.

Le client doit compter les réponses et les associer au nombre de commandes émises. Il doit toutes les examiner. Même si tous les destinataires sont refusés, il ne peut pas présumer que DATA le sera. Si DATA est accepté à tort, la conduite prévue consiste à envoyer un point seul, pas un message à personne.

Une réponse multiligne complique le comptage. Ses lignes intermédiaires portent un tiret après le code ; la dernière n’en porte pas. Les compter comme plusieurs réponses décale tout le registre. Une réponse exacte finit alors attachée à la mauvaise commande.

Le sens explique un verdict une fois son propriétaire connu. Il ne permet pas d’en deviner le propriétaire.

TCP garantissait l’ordre, pas le progrès

Un client non bloquant peut lire les réponses pendant qu’une émission précédente n’est pas entièrement partie. Un client bloquant doit, lui, vérifier que tout son groupe tient dans la fenêtre TCP disponible. Sinon, il peut attendre de finir l’écriture tandis que le serveur attend que le client lise ses réponses : les deux côtés restent corrects localement et pourtant n’avancent plus.

RFC 2920 mentionnait une fenêtre souvent, mais pas toujours, proche de 4 Kio. Ce chiffre appartient au contexte historique ; il ne constitue pas un réglage universel. L’invariant durable est différent : borner les données en suspens ou lire et écrire concurremment.

PIPELINING économise du temps en augmentant l’intention non acquittée. Cette quantité doit devenir mesurable.

Le serveur promettait de ne rien perdre

Un serveur qui annonce l’extension doit répondre dans l’ordre des commandes. Il ne doit pas supposer ce qui n’est pas encore arrivé. Lorsque son tampon TCP local est vidé, il doit libérer les réponses en attente. Surtout, il ne doit jamais vider ni perdre le contenu de l’entrée TCP.

Un échec RCPT TO n’autorise pas la disparition d’une commande suivante déjà reçue. Un changement de processus ne transforme pas les octets prélevés en déchets. Le flux est la preuve matérielle de l’intention du client.

Certaines réponses peuvent être regroupées pour l’efficacité, mais pas celles des commandes qui ferment un groupe, ni celles d’une commande inconnue. Le serveur peut réduire les envois sans masquer l’instant où le client doit changer d’état.

Trois documents, un mécanisme

RFC 1854 introduisit l’extension en 1995. RFC 2197 la remplaça en 1997 en précisant que seuls le texte et l’édition avaient changé. RFC 2920 devint STD 60 en 2000. RFC 5321 décrit encore le dialogue SMTP comme volontairement pas-à-pas, modifiable par une extension mutuellement acceptée telle que celle-ci.

Une annonce PIPELINING ne prouve ni identité, ni acceptation de l’expéditeur, ni destinataire valide, ni stockage réservé, ni remise finale, ni support par le relais suivant. Elle autorise une forme limitée de concurrence pendant cette session.

L’apport historique est précisément cette limite. L’attente pouvait être supprimée lorsque deux programmes en fonctionnement savaient conserver les preuves nécessaires pour ne pas confondre vitesse et état.

Sources et limites

L’histoire normative vient de RFC 1854, RFC 2197 et RFC 2920. RFC 5321 fournit le cadre SMTP, et le registre IANA l’inscription actuelle. Ces sources ne mesurent pas l’adoption présente, les gains réels, les valeurs par défaut des produits ni les taux d’erreur.