Résumé

  • RFC 3462 imposait à multipart/report une place extérieure et un ordre précis : d’abord une explication lisible, puis un enregistrement interprétable par une machine, enfin, de façon facultative, le message d’origine ou un extrait utile.
  • La structure rendait le rapport reconnaissable, pas authentique. Le paramètre report-type annonçait le type de la deuxième partie, mais une contrefaçon bien formée pouvait encore tromper un lecteur ou déclencher une automatisation dangereuse.

Deux destinataires, trois fonctions

Un texte libre sait expliquer une panne avec nuance. Il change toutefois avec la langue, le logiciel et le jugement de celui qui le rédige. Un enregistrement structuré se prête au tri automatique, mais devient vite opaque pour la personne qui cherche à savoir si elle doit corriger une adresse ou patienter. Le problème n’était donc pas de choisir entre prose et données. Il fallait préserver les deux, avec des responsabilités distinctes.

Publié en janvier 2003, le RFC 3462 définit ce cadre. Le texte brut, la notice du RFC Editor, la fiche Datatracker, son historique, ses références, ses citations ultérieures et la recherche d’errata délimitent le dossier normatif. Le texte remplaçait le RFC 1892, mais conservait l’intuition essentielle : plusieurs régimes de preuve pouvaient voyager ensemble sans devenir interchangeables.

Le type multipart/report devait être le type MIME le plus extérieur du message. Il exigeait le paramètre boundary des multiparties décrit par le RFC 2046, ainsi qu’un paramètre report-type. Ce dernier nommait le sous-type MIME attendu dans la deuxième partie. Un agent pouvait donc reconnaître le genre de rapport dans l’en-tête avant d’avoir parcouru tout le corps.

L’ordre faisait partie du contrat

La première partie était obligatoire et destinée à une personne. La norme autorisait tout type MIME inscrit dans une norme, la langue et le jeu de caractères appropriés, voire multipart/alternative pour plusieurs présentations. Cette souplesse n’était pas un oubli : une explication utile dépend du lecteur.

La deuxième partie était elle aussi obligatoire, mais destinée au traitement automatique. Elle consignait un événement de traitement dans un type de média enregistré. Pour une notification d’état de remise, le RFC 3464 employait message/delivery-status. Le contenant générique ne décidait pourtant ni quand demander un avis ni ce que signifiait chaque code. Le RFC 3461 portait la négociation SMTP des notifications; le RFC 3463 définissait les codes d’état enrichis. RFC 3462 organisait la preuve, il ne créait pas à lui seul l’événement attesté.

Une troisième partie pouvait restituer le message original ou seulement une portion utile au diagnostic. Sans préférence explicite, le rapport devait en principe restituer le message complet. Ce choix avait un coût de bande passante et de divulgation. Si un trajet ne permettait pas de garantir le transport de données huit bits ou binaires, le générateur pouvait produire un encodage MIME légal en sept bits ou ne renvoyer que text/rfc822-headers. Ces en-têtes héritaient du format du RFC 822, mais ne constituaient pas un message complet; les appeler message/rfc822 aurait affirmé davantage que ce qui était conservé.

La séparation empêchait trois raccourcis. Une phrase persuasive n’était pas un champ d’état. Un champ d’état n’était pas la copie de l’objet concerné. Quelques en-têtes ne remplaçaient pas le contenu perdu. Le contenant associait ces matériaux, sans effacer leurs limites.

Une forme détectable n’était pas une origine prouvée

Placer multipart/report au niveau extérieur permettait aux logiciels de détecter rapidement un rapport. Le registre IANA des types de médias fournissait le vocabulaire commun. D’autres formats ont ensuite utilisé cette enveloppe : les notifications de disposition du RFC 3798, révisées par le RFC 8098, et les états de remise internationalisés du RFC 6533.

Mais le texte avertissait que la syntaxe n’authentifiait rien. Un faux rapport négatif pouvait conduire un gestionnaire de liste ou d’annuaire à supprimer une adresse valide : une routine de nettoyage devenait alors un déni de service. Un faux rapport positif pouvait installer une croyance erronée dans la réussite de la remise. Une signature couvrant toute la structure aurait pu réduire ce risque, mais son mécanisme restait hors du périmètre.

La distinction révèle la limite de toute automatisation fondée sur la seule forme. Le parseur peut constater qu’un objet respecte une grammaire. Il ne peut en déduire ni son auteur, ni l’événement réel, ni la lecture humaine. Transformer cette reconnaissance en suppression irréversible revient à donner du pouvoir à une apparence.

La discipline des couches de réalité proposée plus tard par Heng Lu aide à séparer le document reçu, son interprétation, l’événement du système de messagerie et l’action de l’opérateur. Sa priorité donnée au code effectivement exécuté invite à examiner l’arbre MIME, le générateur, les contrôles et le consommateur automatique. Ce sont des grilles éditoriales postérieures, non une attribution d’intention privée aux auteurs du RFC.

RFC 3462 n’a pas promis la vérité. Il a mieux fait pour une infrastructure : il a rendu visibles les places respectives de l’explication, de l’enregistrement et de la pièce retournée. La confiance restait une décision supplémentaire.

Sources