Résumé

  • Un enregistrement MX permet au domaine d’une adresse de rester stable tout en désignant un ou plusieurs hôtes de livraison différents. Changer de serveur ne demande plus de renommer chaque destinataire.
  • Chaque expéditeur exécute la règle : interroger le DNS, essayer d’abord la plus petite préférence numérique, traiter les valeurs égales comme des pairs et couper les routes qui reviendraient vers lui. Le MX d’un échangeur n’étend pas implicitement sa responsabilité.
  • Le mécanisme produit du pouvoir opérationnel, non une vérité souveraine. Le contrôle DNS peut détourner le courrier, les caches retardent les changements, plusieurs noms peuvent partager une panne et MX n’assure ni identité ni confidentialité.

Le nom de la boîte et celui de la machine

Le RFC 974 partait d’une habitude concrète. Pour une boîte à LOKI.BBN.COM, un mailer pouvait généralement ouvrir SMTP vers LOKI.BBN.COM. Le nom public et la machine de réception semblaient ne faire qu’un.

Des exceptions existaient déjà. Certains systèmes UUCP et CSNET n’étaient pas directement raccordés à Internet. Les expéditeurs portaient des règles locales, par exemple le transfert du courrier CSNET vers CSNET-RELAY.ARPA. Le SMTP du RFC 821 connaissait relais, passerelles et routes source. MX n’a donc inventé ni le stockage-transfert ni l’intermédiaire.

Le problème était la multiplication des exceptions privées. Une route copiée dans chaque configuration ne pouvait pas être modifiée par le destinataire en publiant un seul nouvel état. Avec le domaine comme adresse durable, il fallait répondre séparément à la question : quelle machine accepte aujourd’hui le courrier pour ce nom ?

MD et MF cèdent la place à un ordre

Le DNS des RFC 882 et RFC 883 rangeait les informations dans des resource records typés. Deux types servaient d’abord au courrier : MD pour la destination et MF pour le forwarder. Ils distinguaient deux rôles, mais exprimaient mal plusieurs choix ordonnés.

Le RFC 973 les remplaça par MX. Un enregistrement associait au domaine une préférence non signée sur 16 bits et le nom d’un échangeur. La plus petite valeur devait être essayée en premier ; des valeurs identiques avaient le même rang.

Cette unification changeait le modèle. MD et MF classaient des machines par fonction. MX publiait un ensemble ordonné de récepteurs possibles. L’hôte direct, un relais et un secours pouvaient partager la même grammaire. Le RFC 1035 conserva ensuite ce format compact.

Le DNS ne publiait pas un itinéraire complet, une mesure de santé ou un contrat. Il fournissait le minimum nécessaire pour que chaque mailer prenne une décision.

Une identité dont l’infrastructure devient remplaçable

Le RFC 974 rappelait qu’un domaine est souvent un hôte, mais pas toujours. Le mailer devait demander au système de noms où livrer. Le résultat pouvait être une tout autre machine, voire plusieurs possibilités.

L’organisation pouvait alors garder son domaine et les adresses de ses utilisateurs tout en remplaçant le matériel, en déplaçant les boîtes, en ajoutant un filtre ou en changeant de prestataire. Les expéditeurs n’avaient pas à connaître la migration interne ; ils lisaient le nouveau MX.

Cette indirection n’est pas innocente. Celui qui contrôle la zone faisant autorité peut rediriger les messages futurs. Mais elle sépare enfin deux durées différentes : le nom par lequel les correspondants connaissent le destinataire et la machine momentanément chargée de le servir.

Une donnée publiée, des milliers de décisions locales

Le RFC 974 recommandait une requête MX à chaque tentative. Un administrateur pouvait ainsi modifier sa zone après une panne et faire apprendre la nouvelle route aux messages déjà en attente, dès la prochaine consultation et selon l’expiration des caches.

Le mailer essayait la préférence numérique la plus faible, puis les suivantes. Plusieurs échangeurs partageant la plus petite valeur devaient tous être tentés avant de déclarer l’échec. Le RFC 5321 a conservé cette logique : le client doit essayer et réessayer les adresses pertinentes ; entre destinations de même préférence sans autre différence, il randomise afin de répartir la charge.

La préférence n’est ni une latence ni une distance ni une note de qualité. Dix précède vingt parce que le domaine l’a publié ainsi. Un secours physiquement proche reste un secours si sa valeur le place après.

Il n’existe donc pas de routeur mondial du courrier. Le DNS publie une liste mince ; les MTA indépendants exécutent l’ordre, gèrent leur file et décident localement quand un incident temporaire devient un retour à l’expéditeur.

Interdire au secours de renvoyer le message en cercle

Les alternatives créent des boucles possibles. Si le mailer local figurait dans la liste, le RFC 974 lui faisait supprimer sa propre entrée et toutes celles dont la valeur était égale ou supérieure. Il ne pouvait remettre le message qu’à un échangeur mieux placé, donc de valeur plus faible.

Un secours à 20 peut retenter le primaire à 10. Il ne doit pas envoyer vers 20 ou 30 et laisser la responsabilité revenir. La préférence définit ainsi un sens de transfert, pas seulement un ordre de disponibilité.

Le RFC ferme aussi une extension trompeuse : on interroge le MX du domaine destinataire, pas le MX du nom trouvé comme échangeur. Être MX d’un relais ne rend pas automatiquement responsable de tous les domaines desservis par ce relais. La responsabilité de recevoir doit être publiée explicitement pour le nom initial ; elle n’est pas transitive.

Le prix assumé de la mise en cache

Les caches rendaient le DNS praticable à grande échelle, mais tous les expéditeurs ne voyaient pas une modification au même instant. Des enregistrements anciens pouvaient créer une boucle ou un faux échec pendant l’expiration.

Forcer chaque requête vers un serveur faisant autorité aurait supprimé ce retard au prix d’un coût jugé impraticable par le RFC 974. La réponse était opérationnelle : coordonner l’ajout d’un échangeur, garder des réponses complètes et refaire par circuit fiable une réponse UDP tronquée.

La mise en cache n’est pas simplement une obstruction. C’est un mécanisme de capacité qui transforme le changement global en convergence. L’exploitant contrôle le TTL, le chevauchement entre anciens et nouveaux services et le retour arrière ; il ne possède pas un bouton instantané pour tout Internet.

L’absence de MX restait une invitation

Pour préserver la compatibilité, le RFC 974 traitait une liste vide comme un MX implicite de préférence zéro pointant vers le domaine lui-même. Le RFC 5321 conserve cette règle : l’expéditeur résout alors A ou AAAA et essaie SMTP.

Un domaine sans MX pouvait donc être ancien mais fonctionnel, mal configuré ou volontairement sans courrier. Le silence ne permettait pas de distinguer ces états. Les MTA essayaient et réessayaient parfois l’adresse d’un serveur web qui n’avait jamais écouté SMTP.

À l’inverse, la présence d’un MX explicite oblige à le respecter. Si tous les MX sont inutilisables, le client signale une erreur au lieu de retomber sur A/AAAA. La cible doit résoudre directement vers une adresse ; une cible qui mène à un CNAME sort du standard SMTP moderne.

Le point qui signifie enfin « aucun service »

Le RFC 7505 ajouta en 2015 le null MX. Un domaine qui ne reçoit aucun courrier publie un seul MX de préférence zéro dont l’échangeur est la racine DNS, écrite .. Aucun autre MX ne peut l’accompagner.

Le point n’est pas une machine en panne. Il dit qu’il n’existe pas d’échangeur. Le client échoue immédiatement, sans utiliser A/AAAA et sans conserver pendant une durée décrite comme typiquement une semaine un message qui ne pourra jamais être remis.

Ce mécanisme n’appartient pas à 1986 ; il corrige vingt-neuf ans plus tard l’ambiguïté créée par la compatibilité. Un état explicite « pas de courrier » évite de demander aux expéditeurs d’interpréter le silence.

Le null MX n’est pas le null reverse-path de SMTP. Un domaine qui envoie du courrier avec une adresse de retour doit considérer que les récepteurs peuvent refuser un domaine où aucun échec ne pourra revenir.

L’indirection a ses détenteurs de pouvoir

L’adresse peut survivre à un serveur parce que le contrôle de la zone peut changer la machine. C’est aussi une capacité de détournement. Plusieurs noms MX peuvent dépendre du même fournisseur, compte, site ou réseau. Un backup peut améliorer la continuité tout en ajoutant un acteur capable de voir les messages et leurs métadonnées.

DNSSEC protège l’intégrité du record ; il ne certifie ni l’identité juridique du destinataire ni le traitement interne. Un transfert SMTP réussi prouve qu’un échangeur a accepté une responsabilité à une frontière protocolaire, non que la boîte finale a stocké le message ou que le lecteur l’a vu.

La légitimité de MX est plus étroite : publier où un domaine demande de transférer le courrier, dans quel ordre, ou qu'aucun service n'existe. Cela suffit à coordonner des systèmes indépendants, pas à faire de l’opérateur DNS le souverain de l’identité.

La plus petite carte postale utile

Trois temporalités pouvaient désormais diverger : l’adresse durable, l’infrastructure remplaçable et la connaissance mise en cache qui expire progressivement. Les correspondants ne participent pas à chaque migration, parce que le lien entre identité et machine est un état public modifiable.

Le commun reste mince : domaine, échangeurs, préférences, TTL, prévention des boucles et repli. Files d’attente, sécurité du transport, emplacement des boîtes et contrats demeurent chez les opérateurs.

L’adresse a survécu au serveur non parce que le DNS lui a trouvé une demeure éternelle, mais parce qu’il a rendu la demeure explicite et remplaçable. Le record décrit juste assez de réalité pour que le code local agisse, sans confondre la machine avec l’identité.

Sources et limites de preuve

Le contexte SMTP et domaine vient des RFC 821, RFC 882 et RFC 883. Le remplacement de MD/MF est dans le RFC 973. L’algorithme de 1986, le cache, les boucles et la responsabilité non transitive viennent du RFC 974.

Le format est conservé dans le RFC 1035, les exigences d’hôtes dans le RFC 1123. La recherche SMTP moderne et le MX implicite sont dans le RFC 5321, et l’état sans service dans le RFC 7505.

Ces documents appartiennent à des époques différentes. Les corrections tardives ne sont pas attribuées aux mailers de 1986 ; les conséquences opérationnelles au-delà des spécifications restent des inférences bornées.