Résumé

  • RFC 3974 montrait qu’un MX secondaire IPv4 pouvait accepter un message sans pouvoir le retransmettre à un primaire IPv6; la préférence MX ordonnait les candidats, elle ne créait aucun chemin entre eux.
  • Réponse DNS, connexion TCP, acceptation SMTP, état de file, relais interne et arrivée dans la boîte finale constituaient des reçus distincts.

La redondance peut réussir au premier regard et échouer un saut plus loin. Dans l’exemple central de RFC 3974, le primaire est IPv6 seulement, tandis que les MX de moindre préférence sont IPv4 seulement. Un expéditeur IPv4 atteint donc le secours. Mais le secours ne peut pas atteindre le primaire par le mécanisme de préférence MX.

Un enregistrement MX contient un rang et un nom d’hôte. Le MTA expéditeur ordonne les candidats, résout leurs adresses puis tente la livraison. Le texte insistait, dans sa note IESG, sur l’autorité de RFC 2821 pour l’algorithme complet. RFC 3974 était informative et ne créait aucun protocole; RFC 5321 a ensuite remplacé RFC 2821.

Une liste de préférences n’était pas un réseau de relais

Le trajet de l’expéditeur vers le MX choisi et le trajet de ce MX vers le stockage final sont deux relations. Inscrire deux serveurs dans la même réponse DNS ne fournit ni tunnel ni famille d’adresses commune entre eux. RFC 3974 proposait comme réparation la plus simple un primaire double pile, sans en faire l’unique solution. UUCP, traduction IPv4/IPv6 ou stockage partagé pouvaient aussi acheminer le message.

L’obligation appartenait au site destinataire : tout message accepté par ses MX devait arriver au dépôt du destinataire. Une réponse SMTP positive au secondaire transférait une responsabilité; elle ne témoignait pas encore du dernier dépôt.

Les fondations historiques passent par RFC 974, RFC 1123, le DNS de RFC 1035 et les adresses IPv6 de RFC 3596. Un seul espace IN MX servait les deux familles. Le rang d’un hôte ne décrivait donc pas la connectivité nécessaire après acceptation.

RFC 3974 séparait aussi NODATA, NXDOMAIN et SERVFAIL. NODATA déclenchait la règle du MX implicite; NXDOMAIN signalait un domaine inexistant et un échec permanent; SERVFAIL imposait une reprise ultérieure. Le retour SERVFAIL de serveurs DNS défectueux sur les requêtes AAAA mettait des messages en file. RFC 4074 a ensuite documenté ces comportements. Une erreur temporaire ne prouvait ni l’absence d’AAAA ni une tentative IPv4.

Après résolution, les étapes restaient indépendantes. On pouvait réordonner A et AAAA dans un même groupe de préférence, tenter TCP 25, recevoir un échec transitoire, une erreur permanente ou un succès SMTP. Le succès signifiait remise à ce MTA, pas arrivée automatique au primaire.

Des textes ultérieurs ont clarifié des frontières voisines : RFC 7505 définit le Null MX, RFC 3463 et le registre IANA structurent les états de livraison; RFC 6724 et RFC 8305 encadrent plus tard sélection et course de connexions. Ils n’offrent pas des mesures rétroactives de 2005.

La notice RFC Editor, la recherche d’errata et le Datatracker établissent statut et histoire documentaire, non fréquence des pannes.

L’exploitation doit donc suivre la garde du message : réponse DNS, adresse choisie, connexion, réponse SMTP, identifiant de file, relais suivant et dépôt final. Une sonde SMTP externe verte ne clôt pas la question du chemin interne. Le secondaire avait bien reçu; c’était précisément la raison pour laquelle le domaine devait prouver la suite.

Sources