Le serveur ne recevait jamais de courrier. Son silence faisait patienter tout le monde.

Résumé

• La RFC 1846 de septembre 1995 décrivait des machines spécialisées qui ne recevaient jamais de courrier. Sans serveur SMTP pour répondre, les expéditeurs pouvaient conserver pendant des jours un message mal adressé. Le code expérimental 521 permettait à un relais MX ou à un petit serveur de signifier un refus définitif.
• Les auteurs constatèrent que certains clients réessayaient si le serveur fermait aussitôt après 521, mais renvoyaient le message à l’expéditeur lorsqu’il restait ouvert jusqu’à QUIT. La RFC 7504 de 2015 inscrivit ensuite 521 dans SMTP pour une machine qui ne reçoit jamais de courrier et créa 556 pour un relais connaissant d’avance le refus d’un domaine.

Une adresse plausible, une boîte inexistante

La patience est une qualité d’un réseau de messagerie. Un serveur indisponible quelques heures peut revenir, et le message attendra. Cette qualité devient une mauvaise plaisanterie si le serveur n’a jamais été chargé de recevoir du courrier. Alain Durand et Francis Dupont l’expliquèrent dans leur RFC expérimentale publiée en septembre 1995. Les machines de l’Internet se spécialisaient : certaines donnaient l’heure, d’autres répondaient aux questions DNS. Beaucoup n’offraient pas de service de courrier. Un utilisateur pouvait pourtant taper leur nom après l’arobase.

Quand le client expéditeur tentait de joindre une telle machine, aucun service SMTP ne répondait. Il devait traiter l’échec comme temporaire, conserver le message et réessayer dans l’éventualité où un serveur apparaîtrait plus tard. La RFC évoquait une attente de plusieurs jours, puis un retour accompagné d’une erreur souvent peu claire. La machine silencieuse ne stockait pas les lettres. Les files et les tentatives se formaient ailleurs, chez ceux qui essayaient de livrer et chez la personne qui attendait une réponse.

Le protocole SMTP décrit en 1982 organise un dialogue entre l’émetteur et le récepteur. Les codes de réponse permettent de décider si une opération a réussi, échoué ou doit être retentée. Durand et Dupont voulurent ajouter une réponse qui manquait à cette situation particulière : cette machine n’accepte jamais le courrier. Leur code 521 ne construisait pas une boîte de réception. Il donnait à un opérateur la possibilité de communiquer une décision permanente au lieu de laisser chaque expéditeur interpréter un silence.

Il y avait deux portes possibles pour prononcer ce refus. Un relais MX pouvait répondre 521 lorsque la conversation SMTP présentait un destinataire sur la machine sans courrier. Sinon, cette machine pouvait lancer un serveur SMTP minimal, conçu uniquement pour refuser les messages. Le premier choix confiait la parole à un intermédiaire déjà présent sur le parcours. Le second la rendait à la machine concernée. Tous deux réclamaient un responsable capable de dire que l’absence de courrier était une règle durable, et non une panne du mardi.

La voie du relais exigeait de la cohérence. La RFC 1846 recommandait aux relais MX moins prioritaires de refuser eux aussi le courrier lorsqu’un relais plus prioritaire le faisait pour cette destination. Si le premier guichet disait non et le deuxième gardait le silence, l’expéditeur avait encore une raison de tenter l’autre route. Une politique locale ne devient un signal utile qu’une fois portée aux entrées par lesquelles les messages peuvent réellement passer.

Même un refus peut être mal entendu

L’idée du petit serveur semble simple : accepter la connexion, afficher immédiatement 521 suivi du nom officiel de la machine ou de son adresse IP, puis terminer. La RFC prévoyait pourtant une autre possibilité. Après l’annonce initiale, le serveur pouvait rester à l’écoute, répondre 521 aux commandes et laisser au client le temps d’envoyer QUIT. Une machine qui envoyait cette salutation ne devait figurer dans aucun enregistrement MX. Elle ne pouvait pas s’annoncer comme récepteur de courrier tout en proclamant qu’elle n’en recevait jamais.

La raison de garder la connexion ouverte venait des logiciels déjà en service. Durand et Dupont rapportèrent que certains clients SMTP interprétaient une fermeture immédiate après le 521 comme un incident transitoire et remettaient le message dans leur file. Quand le serveur attendait, ces mêmes clients envoyaient QUIT et retournaient le message à son auteur. Le sens du code ne changeait pas ; sa place dans une conversation complète changeait son effet. Un « non » imprimé dans une spécification ne faisait pas forcément cesser les tentatives d’un logiciel ancien.

La machine sans courrier devait donc prendre en charge un minuscule service : rester joignable, s’identifier correctement, donner une réponse fixe et parfois patienter jusqu’à la fin du dialogue. Ce service ne distribuait aucun message. Il économisait le travail que son absence imposait à tous les autres. C’est le paradoxe opérationnel de 521 : héberger une porte dont l’unique fonction est de rester fermée, mais de l’annoncer clairement.

En 1995, cette proposition avait le statut expérimental. La RFC invitait les réalisateurs à rapporter leur expérience. Sa mention de « certains » clients qui réessayaient après une fermeture rapide décrit un problème d’interopérabilité observé par les auteurs, sans fournir un recensement des logiciels ou des messages touchés. Pour mesurer l’ampleur réelle cette année-là, il faudrait des journaux de files d’attente ou une enquête auprès des exploitants.

Vingt ans plus tard, le refus changea d’étage

La RFC 7504 de juin 2015 intégra le code 521 à SMTP dans un document de la voie normative. Elle indiquait que le code était largement utilisé, bien qu’il n’eût pas encore été formellement incorporé au protocole. Elle lui assigna un rôle précis au début de la connexion : signaler qu’une machine ne reçoit du courrier en aucune circonstance. Un refus 554 pouvait viser des situations plus larges, par exemple une source ou une adresse particulière. 521 devait porter une déclaration plus radicale sur le service de la machine. Ce texte mit fin à l’expérience lancée par la RFC 1846.

Entre-temps, une autre forme de refus pouvait être publiée avant même qu’une connexion soit tentée. La RFC 7505 définit le « null MX », un enregistrement DNS par lequel un domaine dit qu’il ne reçoit pas de courrier. Sans ce signal, un expéditeur qui ne trouve pas de MX peut se rabattre sur une adresse A ou AAAA et essayer d’y livrer le message, même si elle désigne un serveur web ou une autre machine étrangère au courrier. Le null MX déplace l’information au niveau du domaine, sans serveur factice à joindre.

La RFC 7504 ajouta aussi le code 556. Un relais qui sait, grâce à une information comme le null MX, qu’un domaine de destination n’accepte pas de courrier peut renvoyer ce code à celui qui lui a transmis le message, sans ouvrir de connexion vers la machine cible. Le 521 est le refus d’une machine au moment où l’on ouvre la porte. Le 556 est le refus d’un intermédiaire qui connaît déjà la règle du domaine. Confondre ces deux voix ferait perdre l’information sur le lieu où la décision a été prise.

En 1995, faire fonctionner un petit serveur pour dire « aucun courrier ici » pouvait épargner des jours de relances. En 2015, une déclaration dans le DNS offrait aussi un moyen de prévenir les relances avant la connexion. Dans les deux cas, le gain venait d’une décision explicite formulée par quelqu’un qui connaissait la destination. Le silence ne protégeait pas la machine sans courrier ; il envoyait la facture d’attente chez les autres.