Résumé

  • RFC 1524 proposait des fichiers mailcap communs à plusieurs lecteurs : le type MIME venait du message, tandis que l’ordre des règles locales décidait de l’action de visualisation, composition, édition ou impression.
  • Sous UNIX, la règle retenue devenait une commande Bourne shell enrichie de valeurs et parfois d’un fichier temporaire. Une correspondance ou un code de sortie nul ne prouvait ni l’authenticité du contenu, ni son innocuité, ni l’intention du destinataire.

Le même message, deux politiques effectives

MIME avait rendu transportables des corps de message qui n’étaient plus du simple texte. Un en-tête pouvait annoncer une image, un son ou un ensemble multipartie. Restait une difficulté très concrète : les postes ne partageaient ni les mêmes logiciels, ni les mêmes terminaux, ni le même matériel.

RFC 1524 n’a pas imposé un lecteur universel. Il a proposé une indirection. Lorsqu’un agent de courrier rencontrait un type non familier, il consultait une configuration externe décrivant les programmes installés localement. Ajouter un binaire et une ligne pouvait étendre plusieurs agents utilisateurs sans les réécrire tous.

Le message apportait donc un vocabulaire interopérable. Il n’apportait pas une autorisation d’exécuter le programme préféré de l’expéditeur. Cette seconde décision appartenait au poste destinataire.

La première règle applicable décidait

La configuration effective résultait de la concaténation virtuelle de plusieurs fichiers mailcap. Une entrée devait correspondre au Content-Type, fournir l’action demandée et réussir son éventuel champ test=. La première entrée qui réunissait ces conditions l’emportait.

L’ordre faisait partie du comportement. L’annexe UNIX plaçait le fichier de l’utilisateur avant plusieurs emplacements du site ; la variable MAILCAPS pouvait remplacer tout le chemin de recherche. L’administrateur disposait d’un défaut commun, mais l’utilisateur pouvait le compléter ou le supplanter. Pour expliquer une ouverture, conserver seulement /etc/mailcap était insuffisant.

La commande de visualisation était obligatoire. Des champs distincts pouvaient lancer composition, composition typée, édition, impression et test. needsterminal décrivait l’environnement nécessaire ; copiousoutput conseillait une sortie paginée ou défilable. Une machine pouvait savoir afficher un format sans savoir le créer. « Pris en charge » recouvrait plusieurs capacités et plusieurs pouvoirs.

Le test ne jugeait pas les octets reçus. Il pouvait vérifier la présence d’un système de fenêtres, d’une architecture ou d’un périphérique audio. Un retour zéro signifiait que la règle convenait à cet environnement. Il ne transformait pas le corps du message en contenu sûr.

Le descripteur devenait du texte exécutable

Dans la sémantique UNIX proposée, chaque action était une ligne de commande complète destinée au Bourne shell, comme si /bin/sh -c la précédait. %t recevait le type, %{paramètre} une valeur du Content-Type, %n le nombre de parties et %F une suite de types et de noms de fichiers. %s représentait un fichier contenant le corps.

La chaîne comportait alors plusieurs décisions : analyser la déclaration, choisir une règle, interpréter les protections, substituer les valeurs, construire les arguments puis démarrer le processus. Une valeur bien formée pouvait encore être mal groupée. Un programme pouvait démarrer et produire un résultat faux. Aucun maillon ne recevait automatiquement l’autorité du précédent.

L’usage de %s modifiait aussi le support. Sans lui, visualisation et édition lisaient l’entrée standard. Avec lui, l’agent pouvait créer un fichier temporaire. RFC 1524 précisait que ce fichier ne devait pas être considéré comme durable après la fin de la commande ; un outil poursuivant en arrière-plan devait copier les données nécessaires.

Le champ nametemplate pouvait donner une extension attendue, par exemple .gif. Cette extension facilitait le travail d’un logiciel dépendant du nom. Elle ne contrôlait pas les octets, l’identité de l’expéditeur ou le danger du contenu.

Composer n’était pas seulement afficher à l’envers

Une commande compose produisait des données que le logiciel de courrier étiquetait avec le type configuré. composetyped, lui, pouvait produire son propre Content-Type et d’autres en-têtes MIME. L’encodage de transport restait normalement à la charge de l’appelant.

La provenance d’un nouveau message exigeait donc plusieurs reçus : règle choisie, programme producteur, octets émis, type annoncé, encodage appliqué et message final. La réussite de l’éditeur ne prouvait pas la réussite de ces handoffs.

L’extensibilité gardait une limite d’autorité

La section sécurité de RFC 1524 avertissait que le mécanisme pouvait faciliter les problèmes décrits par MIME et recommandait la prudence dans le choix des programmes exécutés automatiquement. Elle ne documentait ni vulnérabilité nommée ni incident réel. Elle montrait une frontière : un identifiant portable n’acquiert un effet local que parce qu’une politique contrôlée lui associe une action.

Les RFC MIME ultérieures ont consolidé formats, encodages, types et enregistrement. Un type enregistré donne un nom et une documentation partagés. Il ne prouve pas qu’un programme est installé chez le destinataire, que la première règle est approuvée ou que son exécution sera sûre.

Pour enquêter, il faut relier les octets et le type déclaré, les fichiers mailcap effectifs et leur ordre, l’action demandée, la règle et son test, la commande développée, le flux ou fichier temporaire, le processus, le rendu et la décision humaine. « La pièce jointe s’est ouverte » efface précisément le lieu où la description est devenue pouvoir.

Sources