Résumé

  • La commande facultative TURN de la RFC 821 échangeait les rôles client et serveur sur le canal SMTP existant. Elle aidait les sites intermittents, mais laissait un nom d’hôte non authentifié décider où partait le courrier stocké.
  • La RFC 1985 réduisit la portée avec ETRN : le client déclenche une file nommée, tandis que le serveur garde l’autorisation locale, ouvre une autre connexion sortante et répond avant de connaître la livraison.

Une liaison rare devait travailler dans les deux sens

Un petit site ne disposait pas toujours d’un chemin entrant permanent. Lorsqu’il appelait son fournisseur, il voulait déposer son courrier sortant puis profiter de la même fenêtre pour récupérer les messages accumulés hors ligne. Attendre le prochain temporisateur de reprise pouvait gaspiller toute la période de joignabilité.

La RFC 821 proposa TURN. Après un succès 250, l’émetteur SMTP devenait récepteur et l’ancien récepteur devenait émetteur sur le même canal. Le premier envoyait une nouvelle salutation de disponibilité, puis le fournisseur vidait sa file vers lui. Le serveur pouvait refuser avec 502 ; la fonction restait optionnelle.

La connexion était réutilisée, mais la confiance l’était aussi au-delà de ce qu’elle avait démontré.

Dire un nom dans HELO ne donnait pas la garde du courrier

Pour choisir les messages à renvoyer, le serveur devait croire l’identité déclarée par le correspondant. Or le SMTP ancien n’authentifiait pas le nom annoncé. Une machine malveillante pouvait prononcer le nom d’un autre site, demander TURN et recevoir le courrier qui lui était destiné.

La conséquence dépassait une fausse ligne d’en-tête : la garde de messages entiers pouvait changer. La RFC 1985 qualifia le défaut de grave brèche et constata que de nombreuses implémentations avaient évité TURN faute de vérification prescrite.

Une seule assertion produisait trop d’effets : identité supposée, inversion des rôles, changement du sens du canal et destination de la file étaient fusionnés dans un même 250.

ETRN demandait une action sans recevoir les messages

La RFC 1985 conserva le besoin opérationnel et diminua l’autorité accordée. Le serveur annonce ETRN après EHLO. Le client nomme un nœud et demande le démarrage de la file correspondante. La commande peut suivre l’établissement de la session, mais ne peut pas couper une transaction entre MAIL FROM et la fin de DATA.

Le serveur examine la portée et décide localement de l’accepter. S’il l’autorise, il lance ses reprises et ouvre une autre connexion SMTP vers le site nommé. Le demandeur reste demandeur sur le canal de contrôle. Connaître un nom ne lui remet aucun message.

Cette seconde connexion n’est pas une authentification parfaite. Elle crée une frontière de preuve distincte : DNS, routage, ouverture de connexion et transaction SMTP détermineront la destination et l’acceptation de chaque message, au lieu de dépendre uniquement du nom prononcé par le déclencheur.

Le succès du déclencheur n’était pas un reçu

Le traitement peut prendre un temps indéterminé. La RFC 1985 n’exige ni qu’une connexion se produise, ni qu’elle ait lieu dans un délai donné. ETRN répond donc immédiatement.

Un 250 indique que la demande est jugée recevable et que le traitement commence. Il ne prouve pas que la file contient du courrier, qu’une connexion sortante a réussi ou qu’un destinataire a accepté quoi que ce soit. Les réponses facultatives 251, 252 et 253 donnent davantage d’information locale, sans devenir des preuves de livraison de bout en bout.

Confondre le 250 avec « livré » détruit l’incertitude conservée par le protocole. Acceptation du déclencheur, tentative de connexion, transfert SMTP et livraison finale sont quatre événements.

Les noms de files restaient locaux

Le paramètre ordinaire est un nom de nœud complet. @domaine peut réveiller les files du domaine et de ses sous-domaines ; #nom peut désigner une file définie localement, par exemple une file UUCP.

Ces raccourcis augmentent la portée. Un suffixe tel que @com peut déclencher une masse de travail et provoquer de la congestion. Les noms # n’ont aucun catalogue mondial. Le serveur doit donc autoriser des couples précis entre client et portée selon son propre modèle de stockage.

IANA coordonne le mot ETRN; elle n’attribue pas les droits sur les files.

La dépréciation réduisit le budget de confiance

La RFC 2821 déprécia TURN, et la RFC 5321 maintint le jugement : ne pas l’utiliser sans authentification forte du client qui réclame l’inversion. Chiffrer la liaison ne suffit pas ; il faut savoir si le principal authentifié peut recevoir ce courrier précis.

La RFC 5321 décrit aussi une optimisation plus petite. La réception d’un message provenant d’un hôte peut devenir un indice local pour accélérer les reprises vers cet hôte. Le calendrier change sans que le correspondant prenne possession de la file.

Le registre IANA actuel conserve TURN et ETRN comme traces de l’histoire, mais interdit leur usage dans le service de soumission. Un utilisateur de la porte 587 n’obtient pas, par cette seule relation, le droit de réveiller une file de livraison SMTP.

ETRN n’a pas supprimé le problème des sites intermittents. Il a séparé trois pouvoirs : le client suggère le travail, le serveur autorise et planifie, puis une connexion indépendante éprouve la livraison. Aucun de ces faits ne doit se faire passer pour les autres.

Sources