Résumé

  • Une source route SMTP était un état d’enveloppe mutable : chaque relais consommait sa position dans le forward-path et la transférait vers le reverse-path.
  • L’itinéraire se distinguait de la boîte absolue, comme l’enveloppe SMTP se distingue des champs To: et From: lus dans le message. Aucun de ces chemins ne constituait une preuve authentifiée du trajet.
  • MX et les noms de domaine globalement interprétables ont déplacé la décision de routage ordinaire vers le MTA, DNS et la politique locale. Les serveurs ont continué à comprendre l’ancienne syntaxe sans lui rendre automatiquement son ancien pouvoir.

Une adresse qui perdait un relais et gagnait une responsabilité

Plaçons le dialogue SMTP au moment où ONE reçoit la commande suivante :

RCPT TO:<@ONE,@TWO:JOE@THREE>

Dans RFC 821, l’argument de RCPT est le forward-path. JOE@THREE est la boîte absolue. @ONE,@TWO est la route indiquant comment l’atteindre. Le texte insiste : route et boîte ne sont pas la même notion.

ONE reconnaît son identité dans le premier élément. Il supprime donc @ONE; le chemin restant commence par TWO. Mais l’information ne s’évapore pas. ONE place son propre identifiant au début du reverse-path fourni par la commande MAIL. L’étape destinée à guider l’aller devient une étape disponible pour le retour d’une erreur de livraison.

Le mécanisme fabrique deux mouvements simultanés. La partie encore prescriptive se contracte. La partie qui matérialise la responsabilité déjà traversée s’accumule. Une source route n’était donc pas une décoration accolée au destinataire : c’était une petite machine d’état exécutée par les relais.

Le reverse-path ne signait pas le champ From

Les mots « expéditeur » et « destinataire » recouvrent plusieurs surfaces. Le reverse-path de MAIL FROM appartient à la transaction SMTP. Il sert notamment à retourner une notification lorsqu’un système a accepté le message puis ne parvient pas à le remettre. Il n’est ni le champ From: visible, ni Reply-To:, ni une déclaration authentifiée d’auteur.

De même, le forward-path de RCPT TO n’est pas nécessairement le champ To:. Une enveloppe peut contenir plusieurs destinataires, y compris un destinataire absent du texte par l’effet d’une copie cachée. Un en-tête peut citer quelqu’un qui n’est pas un destinataire de cette transaction.

RFC 822 séparait déjà, dans route-addr, la route de l’addr-spec et déconseillait la source route hors besoin particulier. Cette proximité historique de syntaxe n’abolit pas la frontière entre format de message et transport. Modifier l’enveloppe à ONE ne signifie pas réécrire ce que le lecteur verra.

La conséquence probatoire est sévère. Une archive qui ne conserve que le message et ses champs lisibles peut avoir perdu l’itinéraire reçu. À l’inverse, un reverse-path ne prouve pas qui a rédigé le contenu. Les données doivent être nommées selon la couche qui leur confère leur fonction.

Un relais devait changer de nom en changeant de monde

RFC 821 ne demandait pas à ONE de recopier mécaniquement le nom reçu. Lorsqu’il se plaçait dans le reverse-path, il devait utiliser le nom par lequel il était connu dans l’environnement vers lequel il envoyait. Cette nuance importait aux passerelles qui reliaient des espaces de noms différents.

L’itinéraire explicite semblait remettre à l’usager une carte complète. En réalité, chaque frontière pouvait exiger une traduction locale de l’identité du relais. La route dépendait autant du contexte d’interprétation que de la suite de caractères.

Si le serveur qui reçoit le message n’est pas l’élément gauche du forward-path, il ne peut pas supprimer arbitrairement ce premier nom. Celui-ci peut servir à choisir le prochain SMTP. Le droit de consommer une étape naît de la concordance entre position et identité, pas du seul fait d’avoir reçu le message.

Cette concordance ne devient pas pour autant une preuve cryptographique. La source route ne certifie pas que l’auteur contrôlait les domaines cités, que chaque relais a vraiment été traversé, ou que le reverse-path constitue un journal infalsifiable. Elle prescrit un traitement ; elle ne notarise pas son exécution.

MX ne remplaça pas une liste de relais par une autre

RFC 974 décrit un enregistrement MX comme l’association d’un domaine de destination avec des échangeurs de courrier et leurs préférences. Le MTA émetteur interroge le domaine et tente des candidats selon les règles. L’usager peut rester à user@domain sans inscrire la topologie du jour dans l’adresse.

Ce changement découple une identité relativement stable d’un chemin variable. Le domaine peut remplacer ses serveurs de courrier ; le MTA peut tenir compte d’un échec ou d’une politique locale ; les carnets d’adresses n’ont pas à être réécrits à chaque modification.

RFC 974 met aussi en garde contre la poursuite récursive de MX de MX pour bâtir un parcours extravagant. Les préférences MX ne forment pas une chaîne de points obligatoires. Elles proposent des destinations de remise pour un domaine. Les lire comme @ONE,@TWO stocké dans DNS réintroduirait précisément la confusion que l’architecture cherchait à enlever.

L’autorité a donc changé de lieu. L’expéditeur nomme la destination ; le système de transport choisit la prochaine action avec une information plus fraîche. Une route devient le résultat d’une décision observable, et non une partie durable de l’identité du destinataire.

En 1989, ne plus produire sans cesser de comprendre

RFC 1123 demande au Sender-SMTP de ne pas émettre de source route explicite @...: dans RCPT. Le choix architectural est formulé en faveur de noms universels : un domaine globalement significatif et MX couvrent le besoin principal.

Le même document impose néanmoins au Receiver-SMTP d’accepter la syntaxe. « Accepter » doit ici être lu avec précision. Le parseur doit reconnaître la forme ; le serveur n’est pas obligé d’accorder un service de relais à n’importe quel client. S’il n’implémente pas la route demandée, il peut, dans les conditions prévues, tenter une remise directe au domaine situé après le @ le plus à droite.

La migration est volontairement asymétrique. Les nouveaux émetteurs cessent d’ajouter des objets obsolètes, tandis que les files, passerelles, alias et logiciels existants ne sont pas rendus illisibles du jour au lendemain. La capacité de lire survit plus longtemps que l’autorité de générer.

Cette distinction est une technique de retrait, pas une hésitation. Supprimer simultanément grammaire et usage casserait l’installé. Conserver indéfiniment la force normative de la route empêcherait tout retrait. Entre les deux, le serveur peut comprendre l’intention ancienne puis appliquer une décision moderne et explicite.

Un parseur tolérant n’était pas un relais ouvert

Une source route explicite ressemble à une demande de transit, mais la syntaxe et l’autorisation ne sont pas le même contrôle. Un serveur peut analyser correctement l’adresse, constater que la destination n’est pas locale, puis refuser le relais selon l’authentification, l’origine de la connexion, les domaines permis ou sa politique anti-abus.

RFC 2821 qualifie les source routes de deprecated. Les serveurs doivent être prêts à recevoir la syntaxe, devraient normalement ignorer la route et peuvent refuser le relais. Les clients ne devraient plus la produire.

Quand la route est ignorée, ses noms ne doivent pas être copiés dans le reverse-path. Le mouvement décrit par RFC 821 appartient au mode historique où la route est réellement utilisée. Le présenter comme une réécriture universelle de SMTP moderne serait faux.

Si un serveur décide exceptionnellement d’utiliser la route, il doit aller vers le premier domaine indiqué et ne pas deviner un raccourci. Cette règle évite un état hybride où l’implémentation prétend respecter l’instruction tout en réordonnant silencieusement les étapes.

Une supervision sérieuse doit donc séparer quatre résultats : syntaxe reconnue, relais autorisé, prochaine destination choisie, remise finalement réussie. Un même succès syntaxique ne répond pas à ces quatre questions.

Les îlots de courrier rendaient la carte de l’usager utile

RFC 1711, en 1994, décrit la source route explicite comme l’intégration, dans l’adresse, du MTA par lequel l’usager veut faire passer le message. À l’arrivée, ce MTA s’enlève lui-même et traite le reste.

Le document restitue surtout la raison historique. Dans un monde composé d’îlots de courrier faiblement connectés, connaître une passerelle reliée à l’îlot lointain pouvait faire la différence entre une adresse théorique et un message livrable. La connaissance topologique de l’usager compensait l’absence d’un routage universel.

Avec l’interconnexion, cette connaissance devint superflue pour l’usage courant et fragile dans les adresses conservées. RFC 1711 mentionne également le traitement incohérent d’un relais à l’autre comme motif de découragement.

Il s’agit d’une analyse historique datée, non d’une mesure actuelle. Elle ne prouve ni la disparition simultanée de toutes les passerelles, ni l’absence de tout besoin de diagnostic. Elle montre le renversement de la charge : la carte autrefois nécessaire à l’usager devient une copie périssable d’une topologie que les systèmes peuvent choisir eux-mêmes.

Le percent-hack, les bang paths UUCP et certaines conversions de passerelles partagent ce décor. Ils ne suivent pas nécessairement la grammaire @relay1,@relay2:user@host ni sa transformation du forward-path. Les citer comme contraste ne permet pas de fusionner leurs mécanismes.

Obsolète, mais encore lisible en 2008

RFC 5321 explique que MX a supprimé le besoin normal de routes explicites et que l’exigence de noms de domaine pleinement qualifiés a éliminé la dernière justification générale importante. Un client ne devrait les générer que dans des circonstances inhabituelles, telles qu’un diagnostic ou un grave problème DNS temporaire.

Le serveur doit pourtant continuer à reconnaître la syntaxe. Il peut refuser le relais, ignorer la route et viser la destination finale, ou, dans un cadre exceptionnel, utiliser la route selon les contraintes du protocole. Obsolete ne veut donc pas dire inexistant dans la grammaire ; cela veut dire privé de statut normal dans la production de nouveaux messages.

Ignorer la route n’assure pas toujours la délivrance. Certaines anciennes adresses dépendaient de noms qui n’étaient résolus que dans un environnement intermédiaire. Après suppression, le domaine final peut ne rien signifier dans DNS global. La compatibilité ne fournit pas un oracle capable de reconstruire un espace de noms local disparu.

Le diagnostic ne doit donc pas se limiter à « supporté » ou « non supporté ». Il faut savoir si la forme a été reconnue, si l’original a été conservé, si la route a été utilisée, ignorée ou refusée, si le domaine final se résolvait et à quel moment la responsabilité de remise avait été acceptée.

Une instruction de route n’est pas une preuve de parcours

Voir @ONE,@TWO dans une valeur sauvegardée établit seulement que cette valeur contient ces noms. Sans trace de session, on ne sait pas si un SMTP l’a acceptée, si ONE a consommé son élément, si TWO a été contacté, ni si le message est arrivé à THREE.

À l’inverse, ne retrouver que JOE@THREE dans un journal normalisé ne prouve pas l’absence de source route à l’entrée. Un MTA de bord a pu la retirer ; un collecteur a pu ne conserver que la boîte analysée ; les en-têtes du message ont pu ne jamais la porter.

La preuve exploitable réunit l’argument brut de la commande, les extrémités de session, l’horodatage, la décision de politique, la réponse SMTP, la résolution du prochain saut et la trace de file. La forme normalisée est utile pour l’indexation, à condition d’être conservée comme dérivé et non comme remplacement de l’entrée.

Même le reverse-path accumulé ne constitue pas une attestation. Il soutient un mécanisme de retour d’erreur, sans authentifier l’identité des relais ni garantir que chaque nom correspond à un passage honnête et unique. Il faut borner toute inférence à la fonction que le protocole attribue au champ.

Limite des sources

RFC 821, RFC 822, RFC 974, RFC 1123, RFC 1711, RFC 2821 et RFC 5321 ferment la grammaire, les transitions normatives et l’interprétation historique. Ils ne mesurent pas l’usage actuel, les taux d’acceptation, la conformité des produits, les relais ouverts ou les incidents de sécurité.

Ils ne permettent pas non plus de confondre la source route SMTP avec LSRR ou SSRR d’IPv4. Le vocabulaire de l’itinéraire est commun ; la couche, l’objet, le processeur et l’autorité ne le sont pas.