Résumé

  • Dans le SMTP de 1982, l'expéditeur pouvait joindre à la boîte finale une liste de relais ; chaque relais retirait son propre nom de la route aller et le plaçait dans la route de retour.
  • RFC 1123 a privilégié les noms de domaine universels et les enregistrements MX. Le récepteur devait encore accepter l'ancienne syntaxe, mais pouvait abandonner les étapes indiquées et viser directement le domaine final.
  • Aujourd'hui, comprendre la forme n'accorde ni droit de relais ni promesse d'exécution : le serveur peut ignorer la route, la refuser ou ne l'utiliser que dans un cadre exceptionnel.

Une adresse qui ne commande plus le voyage

Voici un destinataire parfaitement analysable par la grammaire SMTP :

RCPT TO:<[relais alpha, relais beta]:[boîte user du domaine gamma]>

La boîte de l'utilisateur dans le domaine gamma est la destination. Les deux domaines placés avant les deux-points décrivent une route souhaitée. Dans le modèle d'origine, ils guidaient effectivement la remise. Dans le modèle actuel, ils peuvent n'être que la trace syntaxique d'une ancienne capacité.

Un serveur peut éliminer le préfixe et chercher comment joindre gamma.example. Un autre peut refuser de relayer. Un troisième peut, pour un diagnostic strictement encadré, contacter alpha.example. Les trois ont compris la même chaîne. Leur divergence ne vient pas du parseur, mais de la politique et de l'autorité de routage.

Cette distinction révèle une forme subtile de compatibilité. Un protocole peut promettre de ne pas mal lire le passé sans promettre de lui rendre le contrôle.

Quand la route se déplaçait d'un champ à l'autre

RFC 822 appelait cette construction route-addr. La partie située avant l'adresse absolue énumérait les hôtes ou services de transmission que l'auteur souhaitait traverser. La route et la boîte étaient définies séparément.

RFC 821 donnait à cette séparation un effet dans l'enveloppe SMTP. Son exemple plaçait les relais ONE et TWO avant la boîte de JOE dans le domaine THREE : la boîte restait la destination absolue, ONE puis TWO formaient l'itinéraire.

Lorsqu'un relais nommé recevait le message, il ôtait son identifiant du forward-path, l'ajoutait au début du reverse-path, devenait à son tour expéditeur SMTP et ouvrait une connexion vers l'étape suivante. La route aller diminuait à mesure que la route de retour s'allongeait. Ce mécanisme liait la progression du message à une comptabilité des relais déjà traversés.

Le relais pouvait néanmoins rejeter la tâche. Une liste de domaines n'a jamais constitué une permission générale d'utiliser un serveur tiers. Et RFC 821 précisait que ces chemins appartenaient aux commandes SMTP : ils n'avaient pas à figurer dans To, From ou CC. L'itinéraire de transport n'était pas l'identité éditoriale du message.

Le domaine final devint le point stable

En 1989, RFC 1123 demanda aux expéditeurs de ne plus produire la forme explicite de source route. Le texte explique le choix d'architecture : préférer un nom universel au source routing. SMTP assurait la connectivité, le DNS fournissait des noms globaux indépendants de l'emplacement et MX traitait le cas principal autrefois confié à une liste de relais.

Les relais ne disparurent pas. Ce qui disparut du fonctionnement ordinaire fut le droit de l'expéditeur d'inscrire leur ordre dans l'adresse. Le domaine de destination publie ses échangeurs ; chaque serveur applique ensuite sa politique et son état courant. Une modification de topologie peut être portée par le DNS sans réécrire les carnets d'adresses de tous les correspondants.

Cette différence sépare deux durées. La boîte de l'utilisateur dans le domaine gamma peut rester longtemps utile. Une suite alpha, beta peut être obsolète dès qu'un service tombe, qu'un contrat change ou qu'une politique anti-abus se durcit.

Accepter la forme, retirer son effet

RFC 1123 ne transforma pas brutalement l'ancien destinataire en erreur de syntaxe. Le récepteur devait reconnaître la forme. S'il ne mettait pas en œuvre le relais historique, il devait tenter la livraison vers le domaine terminal de la boîte. Son exemple retire les relais ALPHA et BETA et dirige directement la boîte de JOE vers le domaine GAMMA.

RFC 2821 rendit la séparation encore plus nette. Le serveur reconnaît la route, puis devrait l'enlever et utiliser le domaine de la boîte comme si elle n'avait jamais été fournie. Les noms supprimés ne doivent pas être recopiés dans le reverse-path. L'ancien algorithme de retour n'est donc pas ressuscité par la seule présence des séparateurs.

Cette discipline évite deux fautes symétriques. Refuser de comprendre la syntaxe peut casser un ancien client ou découper incorrectement l'adresse. L'exécuter sans décision nouvelle peut laisser l'expéditeur sélectionner un intermédiaire que la politique moderne n'autorise pas. Le parseur protège la continuité ; la politique protège la frontière de confiance.

La norme actuelle garde une exception, pas un blanc-seing

RFC 5321 conserve A-d-l dans la grammaire normative. La note associée résume le compromis : cette forme doit être acceptée, ne devrait pas être produite et devrait être ignorée.

Un serveur peut refuser d'agir comme relais ou refuser une adresse qui contient une route. Il peut aussi supprimer la liste et choisir la destination finale. S'il décide réellement d'exécuter la route, il doit commencer par le premier domaine indiqué et ne peut pas inventer de raccourci. Le caractère obsolète du mécanisme ne rend pas sa mise en œuvre approximative.

Le texte signale aussi une dépendance dangereuse : certains expéditeurs plaçaient à la fin un nom invalide, en comptant sur un relais intermédiaire pour le comprendre. Un serveur conforme qui retire la route révèle alors l'erreur. La grammaire reste recevable, mais l'ancienne hypothèse de résolution ne l'est plus.

Le débogage et certaines pannes graves peuvent encore justifier une utilisation exceptionnelle. Cette possibilité place la décision chez l'opérateur du relais ; elle ne rétablit pas l'autorité générale de l'auteur de l'adresse.

L'en-tête a gardé un fossile distinct

RFC 5322 range la route des adresses d'en-tête dans la syntaxe obsolète et recommande de l'ignorer lors de l'interprétation. Le parseur peut ainsi lire une archive ancienne sans convertir sa ponctuation en commande de transport.

Cette règle rappelle que l'enveloppe et le contenu n'ont pas la même fonction. Une route visible dans un ancien champ ne prouve ni les destinataires SMTP réels ni les relais effectivement empruntés. Pour ceux-ci, il faut l'état de transport et les traces produites pendant le passage.

Sources et limites

RFC 821, RFC 822, RFC 1123, RFC 2821, RFC 5321 et RFC 5322 établissent cette évolution normative. Ils ne mesurent pas l'usage actuel, les réglages des logiciels, les taux de filtrage ou la réussite des remises.

L'acquis historique tient dans une phrase : SMTP a conservé le devoir de comprendre une route après avoir retiré à cette route le droit d'être suivie par défaut.