Résumé

  • RFC 2017 a ajouté l’accès URL à message/external-body : le message décrit une récupération, mais ne contient pas l’objet visé.
  • Le découpage et l’encodage protègent la représentation de l’adresse dans l’en-tête ; ils ne garantissent ni l’accès, ni l’identité, ni l’autorisation.
  • Le type déclaré, le consentement explicite et Content-MD5 forment des contrôles distincts ; les sources officielles ne démontrent pas une diffusion générale du mécanisme.

Le modèle external-body de MIME partait d’une absence assumée. RFC 1521 avait déjà prévu plusieurs chemins — FTP, FTP anonyme, TFTP, fichier local et serveur de courrier — pour obtenir un corps conservé hors du message. RFC 2017 y a ajouté URL, avec un paramètre URL obligatoire et un en-tête interne déclarant le type du contenu attendu.

Ce choix ne faisait pas d’une URL un objet. Le texte limite le mécanisme aux schémas capables de récupérer directement des données. mailto est exclu : il désigne une boîte et une action de messagerie, non la ressource qui constituerait le corps externe. Deux chaînes peuvent partager la forme d’une URL sans promettre la même opération.

Le document règle ensuite un problème très concret de transport. La valeur est inscrite entre guillemets comme une suite de URL-word, chaque fragment comptant au plus quarante caractères et étant séparé par un espace linéaire. Le destinataire retire guillemets et espaces pour reconstruire l’adresse. Avant ce découpage, les espaces bruts, caractères de contrôle, guillemets, barres obliques inverses et octets élevés doivent être encodés selon les règles historiques de RFC 1738.

La reconstruction peut donc être exacte alors que la récupération échoue. La cible peut réclamer des identifiants, rediriger la requête, disparaître ou rendre des octets différents. Le protocole préserve une instruction ; il ne fournit pas la preuve de son résultat.

Un type annoncé avant de voir les octets

L’en-tête interne fixe le type du contenu que l’application s’attend à recevoir. RFC 2017 exige que la version effectivement utilisée concorde avec cette déclaration, car l’application peut déjà avoir pris des décisions irrévocables. Choisir un décodeur ou un gestionnaire avant d’avoir vérifié le résultat transforme une simple déclaration en pouvoir d’exécution.

Le « corps fantôme » de cette forme URL n’est pas utilisé et doit rester vide. Ce vide confirme que le message ne transporte aucun substitut de l’objet. Il distingue aussi ce mécanisme de mail-server, où cette zone contient une commande adressée au serveur.

RFC 2046, qui a remplacé RFC 1521 peu après, a conservé l’architecture. Il impose un Content-ID aux corps externes pour corréler cache et accusés ultérieurs. Surtout, il rappelle que résoudre un corps externe revient à exécuter, chez le destinataire, une opération indiquée par l’expéditeur. L’agent doit expliquer l’action et demander une permission explicite.

Une adresse valide ne vaut donc pas consentement. Un condensat correct ne vaut pas signature non plus. RFC 2017 permet Content-MD5 pour vérifier l’intégrité des octets récupérés et leur conformité à l’intention indiquée ; elle précise aussitôt qu’il ne s’agit pas d’une signature numérique. RFC 1864 cantonne pareillement ce champ au contrôle d’intégrité.

Le message et l’objet distant suivent ainsi deux chaînes de preuve. Authentifier le premier ne couvre pas automatiquement des données acquises ensuite par un autre protocole. Le chemin peut être détourné ; la ressource peut évoluer. L’adresse nomme une voie de récupération, pas une identité immuable de contenu.

RFC 2017 reste classée Proposed Standard dans les dossiers actuels, et la recherche d’errata n’a révélé aucune entrée correspondante lors de cette vérification. RFC 1738 est aujourd’hui obsolète ; RFC 3986 fournit le cadre URI générique ultérieur. Ces faits situent les textes, sans prouver l’adoption, l’usage réel ni une filiation avec un produit moderne.

La contribution historique tient dans cette discipline : ne jamais laisser l’interface confondre « adresse reçue » avec « objet reçu ». Entre les deux se trouvent une décision humaine, une résolution, un transfert, une validation de type et une preuve d’intégrité dont la portée doit rester visible.

Sources