Résumé

  • Après les données, SMTP accepte ou refuse la transaction comme un tout ; une réponse positive transfère au serveur la responsabilité complète du message.
  • LMTP renvoie un résultat final, dans l'ordre, pour chaque commande RCPT réussie : la file amont peut clore les destinataires acceptés et garder les autres, mais une réponse perdue laisse encore place à un doublon.

Le problème n'était pas l'adresse, mais le nombre de verdicts

Un gestionnaire de file présente deux destinataires à un agent de remise local. Les deux commandes RCPT sont d'abord acceptées. Lorsque le corps est complet, le premier dépôt réussit ; le second rencontre une limite temporaire de boîte.

Avec SMTP, ces deux faits ne peuvent pas devenir deux réponses finales à DATA. RFC 5321 maintient une règle binaire à cet endroit : la transaction est acceptée pour remise ou ne l'est pas. Le 250 final signifie que le serveur prend la responsabilité du message. Une défaillance ultérieure pour un destinataire devient son problème de file ou de notification.

Cette unité convient au transport différé entre hôtes. Le serveur SMTP récepteur possède une file persistante et peut terminer le travail plus tard. Elle devient coûteuse lorsque le client est déjà le gestionnaire de file et ne veut confier qu'une tentative locale à un agent de boîtes. Imposer une seconde file à cet agent dupliquerait stockage, reprise et politique de réessai.

RFC 2033 a déplacé cette limite en 1996. LMTP conserve l'essentiel du dialogue ESMTP, mais, après le point final de DATA, émet une réponse pour chaque RCPT précédemment réussi.

L'ordre constitue le registre des responsabilités

Les réponses ne sont pas une liste libre. Elles suivent exactement l'ordre des commandes RCPT acceptées. Un destinataire refusé avant DATA n'y figure pas. Deux commandes réussies portant le même chemin de destination exigent tout de même deux réponses. Une réponse multiligne ne compte que pour une position.

Le client peut ainsi mettre à jour sa file sans ambiguïté. Une réponse finale positive ferme sa responsabilité pour le destinataire correspondant. Une erreur temporaire laisse celui-ci dans la file. Une erreur permanente est traitée selon la politique de retour ou de suppression du gestionnaire.

L'acceptation initiale de RCPT reste provisoire. Elle autorise la poursuite de la transaction ; elle ne prouve ni dépôt final ni lecture humaine. Le transfert décisif intervient avec la réponse positive qui suit les données.

Cette cardinalité change l'architecture. La vérité locale demeure chez l'agent capable de tenter le dépôt, tandis que la mémoire durable des réessais reste chez le composant déjà conçu pour la porter.

LHLO empêchait de confondre deux contrats

Une ressemblance presque complète avec SMTP aurait pu devenir un piège. Un client SMTP attend une seule réponse finale ; il pourrait prendre la première réponse LMTP pour la fin, puis attribuer les suivantes à de futures commandes. Un client LMTP, lui, pourrait attendre des réponses qu'un serveur SMTP n'enverra jamais.

LMTP remplace donc HELO et EHLO par LHLO. Un serveur LMTP ne doit pas accepter positivement les salutations SMTP, et le protocole ne doit pas utiliser le port de service SMTP 25. Le but n'est pas de créer une marque : il est de rendre visible la grammaire des réponses avant d'y engager un message.

RFC 2033 impose aussi PIPELINING et les codes d'état améliorés. RFC 2920 conserve la correspondance ordonnée lorsque plusieurs commandes sont envoyées sans attendre. RFC 2034 et RFC 3463 précisent la nature d'un échec. Mais un code précis ne dit pas à lui seul à quelle position RCPT il appartient : le registre ordonné reste indispensable.

Si CHUNKING est négocié, BDAT LAST reçoit la même série de résultats par destinataire. Les blocs BDAT non finaux gardent une réponse unique. La pluralité appartient à l'achèvement du message, non à chacun de ses fragments de transport.

La fenêtre du doublon ne disparut pas

RFC 1047 avait décrit un intervalle irréductible de SMTP. Le récepteur peut avoir accepté ou remis le message alors que l'émetteur n'a pas encore reçu le 250. Si la liaison se rompt, le premier considère le travail accompli et le second doit supposer qu'il ne l'est pas. Un nouvel essai peut créer une seconde copie.

LMTP découpe cette incertitude par destinataire. Si la réponse positive du premier arrive et est enregistrée durablement, celui-ci sort de la file. Si le second dépôt réussit mais que sa réponse se perd, le client ne dispose d'aucune preuve transférable. RFC 2033 lui ordonne de traiter les réponses déjà reçues et de considérer les positions restantes comme des échecs temporaires.

Le serveur doit répondre et vider son tampon au plus vite ; le client doit traiter les résultats à mesure qu'ils arrivent. Ces règles réduisent le suffixe ambigu si la connexion tombe. Elles ne peuvent pas annuler un dépôt dont l'accusé n'a jamais franchi la liaison.

Voilà pourquoi RFC 2033 déconseille LMTP sur les réseaux étendus. Le protocole sert une courte frontière locale entre une file durable et un agent de remise. Allonger le chemin augmente la probabilité de séparer l'acte de son accusé.

Une réponse immédiate n'était pas une DSN

Une notification d'état de remise relate plus tard ce qui s'est produit après qu'un système a accepté la charge. La réponse finale LMTP participe au transfert de cette charge. Un 4yz signifie que le gestionnaire actuel la conserve pour ce destinataire ; un 2yz signifie que l'agent local l'a prise.

Ni l'un ni l'autre n'atteste l'identité d'une personne, l'affichage dans une interface ou la lecture du contenu. LMTP répartit une obligation de transport. Il ne transforme pas une boîte en preuve d'attention.

Sources et limites

Le corpus fermé comprend RFC 1047, RFC 2033, RFC 2034, RFC 2920, RFC 3463 et RFC 5321. Ces textes établissent la grammaire et les responsabilités, non le taux de déploiement, les défauts des produits ou une socket universelle. RFC 2033 est informatif ; il ne constitue pas un mandat général d'emploi de LMTP.