Résumé

  • La RFC 2298 de mars 1998 autorisait l’en-tête Disposition-Notification-To pour demander une notification de traitement. Le logiciel du destinataire pouvait l’ignorer ou, dans la version initiale, répondre denied.
  • La notification décrivait des opérations comme l’affichage, l’envoi ailleurs, le traitement automatique ou la suppression. Le texte recommandait fortement le consentement de l’utilisateur et limitait le logiciel à une notification par destinataire et par message. La RFC 3798 de 2004 a ensuite retiré les états denied et failed, peu utilisés.

Un carton glissé sous la porte

Imaginez un bureau de 1998. On rédige un courriel, on l’envoie, puis on voudrait savoir si le correspondant l’a vu. Le programme expéditeur ajoute Disposition-Notification-To et une adresse pour le retour. La demande traverse le réseau avec le message. De l’autre côté, un autre programme reçoit l’enveloppe. L’auteur du message a écrit la question ; le traitement du retour appartient désormais à la boîte d’arrivée.

La RFC 2298 a baptisé ce retour Message Disposition Notification, ou MDN. Dès la deuxième section, elle qualifie l’en-tête de demande. L’agent utilisateur du destinataire peut passer son chemin sans bruit. Il pouvait aussi envoyer denied, une réponse déclarant que l’information sur le sort du message resterait privée. La spécification recommandait fortement de demander l’accord de l’utilisateur avant l’envoi. Une fenêtre pour chaque courriel ou une préférence enregistrée pouvaient porter ce choix. Le protocole donnait à la curiosité de l’expéditeur un formulaire, pas un passe-partout.

Les mots du formulaire avaient une portée précise. Displayed signifiait que le logiciel avait affiché le message à quelqu’un ouvrant la boîte. Dispatched pouvait désigner une impression ou un transfert. Processed couvrait un traitement par règle ou serveur. Deleted disait qu’il avait été supprimé. La définition de 1998 s’attache à des gestes du système. Lire une phrase, la comprendre, décider quoi en faire : ces opérations humaines n’étaient pas produites par le champ displayed.

La notification distinguait encore deux histoires que le langage courant confond. L’action décrite avait-elle été déclenchée manuellement ou automatiquement ? La notification avait-elle été envoyée après une permission donnée pour ce message ou selon un réglage préalable ? Ces deux dimensions étaient des champs distincts. Un expéditeur recevait parfois le même état après des chemins locaux différents. L’enveloppe de retour pouvait raconter une partie de ce chemin.

Les rédacteurs de la RFC avaient aussi pensé aux machines trop serviables. Pour un destinataire donné, un message ne devait entraîner qu’une MDN au maximum. Une MDN ne pouvait pas réclamer sa propre MDN et sa réception ne devait pas en engendrer une autre. Sans cela, deux programmes auraient pu s’écrire des accusés d’accusés jusqu’à l’épuisement de tout le bureau. Trois règles courtes rendaient cette pièce de théâtre impossible.

Le champ d’adresse offrait une autre occasion de malveillance. Un expéditeur pouvait demander que les réponses partent vers un tiers, puis envoyer des messages en nombre pour faire travailler les boîtes des autres à son service. La RFC recommandait donc de comparer l’adresse de notification au Return-Path. Une différence, l’absence de chemin de retour ou plusieurs adresses distinctes appelaient une confirmation de l’utilisateur ou l’abstention automatique. Le document cite les boucles et le bombardement de courriels. Une demande de politesse pouvait devenir une arme de nuisance si le logiciel répondait les yeux fermés.

La répartition des rôles tenait donc en peu de choses. L’expéditeur formulait un souhait. Le logiciel récepteur examinait l’en-tête, les adresses et ses réglages. L’utilisateur autorisait, refusait ou ne répondait pas. Si une MDN repartait, elle enregistrait une opération circonscrite. Aucune ligne ne transformait la livraison du message en mandat sur l’attention d’autrui.

L’histoire réserve un sourire final. La RFC 3798, qui a remplacé le texte de 1998 en mai 2004, a supprimé denied et failed faute d’usage ou d’implémentation constatés. Le refus solennel sur formulaire a quitté la scène. Le silence, lui, n’avait besoin d’aucun formulaire. La porte de la boîte aux lettres restait du même côté.

Un accusé de lecture était ainsi un protocole de courtoisie sous tension. L’expéditeur voulait une certitude. Le destinataire gardait la réponse. Le logiciel pouvait rapporter qu’il avait affiché ou supprimé un message. Le mystère de ce qui s’était passé dans la tête du lecteur survivait très bien à la bureaucratie électronique.