Résumé

  • Le RFC 2076 était un catalogue informatif, non une homologation générale : courrier, Usenet, passerelles X.400 et usages non normalisés y gardaient des statuts différents.
  • Il excluait l'enveloppe SMTP, UUCP ou NNTP ainsi que les attributs internes aux corps PEM et MOSS ; un champ de message ne représentait donc pas toute la transaction.
  • L'enquête doit suivre présence, définition, protocole, statut, traitement local puis résultat. Aucune étape ne prouve automatiquement la suivante.

Le tableau du RFC 2076 ressemblait à un inventaire, mais sa valeur se trouvait dans les limites. Un champ pouvait être normalisé, expérimental, controversé, déconseillé, réservé à Usenet ou utile seulement lors d'une conversion X.400. Certains noms étaient seulement courants.

Cette prudence répondait à une illusion de la syntaxe. Deux lignes construites comme « nom : valeur » paraissent comparables. Pourtant, leur institution d'origine, leur domaine d'application et leur effet possible peuvent être entièrement différents.

Un même dictionnaire, plusieurs juridictions

Le catalogue s'appuyait notamment sur le RFC 822 pour le courrier, le RFC 1036 pour Usenet et le RFC 1327 pour les passerelles X.400. Il notait que des champs Usenet apparaissaient parfois dans des courriels sans y être normalisés. X400-Received ou Alternate-Recipient transportaient un contexte de passerelle, pas une autorité universelle.

Le RFC 3864 a ensuite créé des registres permanents et provisoires où un même nom peut avoir plusieurs entrées de protocole. Une inscription provisoire ne vaut pas approbation de l'IETF ou de l'IANA. Le RFC 4021, puis le registre IANA actuel, ont conservé les colonnes protocole, statut et référence.

Les exclusions empêchaient de confondre les couches

Le RFC 2076 laissait hors de son périmètre les attributs d'enveloppe transmis par SMTP, UUCP ou NNTP, les champs internes des corps PEM ou MOSS et les en-têtes exclusivement HTTP. Une ligne visible ne pouvait donc pas remplacer le journal de transaction ni une preuve cryptographique placée dans le corps.

Pour reconstituer un incident, il faut le message brut, l'enveloppe, la trace des relais, les transformations de passerelle et la décision du client. Les fusionner dans un objet « headers » pratique efface l'origine des faits.

Apparently-To révélait le prix de l'inférence

Des versions de sendmail ajoutaient Apparently-To à partir des destinataires de l'enveloppe quand To manquait. Le RFC le qualifiait de non normalisé et déconseillé : l'opération pouvait dévoiler des destinataires en copie cachée. L'agent convertissait ainsi une connaissance privée du transport en contenu visible.

Le parseur constatait correctement le champ, mais ne prouvait ni qui l'avait créé, ni la politique de divulgation, ni son autorité. La présence était un reçu, pas une permission.

Normalisation et intention restaient séparées

Reply-To avait une base normative, tout en étant décrit comme controversé. Une réponse personnelle, une réponse au groupe et la pratique d'une liste ne traduisent pas la même intention. Le gestionnaire de liste et le client prennent chacun une décision de politique.

Errors-To et Return-Receipt-To, eux, étaient non normalisés et déconseillés. Une demande de notification n'attestait ni la livraison, ni la lecture, ni l'effet produit. Le RFC renvoyait les erreurs de livraison vers l'enveloppe et des mécanismes dédiés.

La chaîne probante devient alors : occurrence → texte de référence → protocole → statut → décision locale → résultat observé. C'est cette chaîne, et non le nom seul, qui permet d'agir sans inventer une juridiction.

Sources