Résumé

  • Avec message/partial, chaque fragment restait un message transportable à part entière ; id, number et total ne faisaient que décrire l’ensemble que l’agent destinataire pouvait tenter de reconstruire.
  • Le résultat prenait la sémantique de l’entité intérieure. Les en-têtes de la première enveloppe et certains en-têtes intérieurs étaient fusionnés, tandis que les enveloppes suivantes perdaient leurs en-têtes dans le résultat dérivé.
  • Une série apparemment complète ne prouvait ni l’origine, ni l’égalité de doublons, ni l’intégrité, ni l’affichage. Le format organisait des indices ; seul un contrôle local produisait un objet utilisable.

Plusieurs plafonds pour une seule intention

Un expéditeur pouvait considérer un document comme un tout et pourtant le voir refusé à cause d’une limite propre à un relais, une passerelle ou une boîte. SMTP ne fixait pas un maximum universel. En 1989, le RFC 1123 exigeait que les logiciels sachent envoyer et recevoir au moins 64 kilo-octets, souhaitait une capacité bien supérieure et constatait déjà l’échange de documents d’un mégaoctet ou davantage. C’était un minimum d’implémentation, pas un contrat commun à toutes les étapes.

Le courrier à relais successifs amplifiait ce décalage. Le premier système pouvait accepter, le deuxième mettre en file, le troisième refuser. Aucun seuil local ne décrivait à lui seul la possibilité d’acheminer l’objet de bout en bout. Imposer une nouvelle taille à tout l’écosystème aurait supposé une autorité et une mise à niveau synchronisée que l’Internet ne possédait pas.

MIME a retenu une solution plus fine : conserver le message comme unité de transport, mais permettre à plusieurs unités de porter une seule entité sémantique. Le destinataire n’obtenait le tout qu’après avoir vérifié les pièces dont il disposait.

Le fragment était complet comme courrier, incomplet comme contenu

Le RFC 1341, publié en juin 1992, a introduit message/partial au sein de la première architecture MIME. Un corps ainsi typé représentait un fragment d’un message plus vaste. Son enveloppe extérieure restait pourtant un véritable message : elle pouvait recevoir son propre Message-ID, ses lignes Received, son heure d’arrivée et son résultat de livraison.

Ce mécanisme ne ressemblait pas à multipart/mixed. Dans un multipart, plusieurs parties arrivent sous une même enveloppe. Avec message/partial, plusieurs enveloppes arrivent séparément et prétendent former une entité intérieure. Un serveur SMTP pouvait donc accepter la pièce 4 sans connaître la pièce 1 ; une boîte pouvait conserver trois fragments sans que le document existe encore pour son lecteur.

Cette distinction empêchait les registres intermédiaires de déclarer trop tôt une réalité qu’ils n’avaient pas. Une livraison réussie établissait l’arrivée d’une enveloppe, rien de plus. La reconstruction appartenait au logiciel qui disposait de l’ensemble et exécutait les règles.

id, number, total : une grammaire, pas un sceau

Trois paramètres coordonnaient les messages. id associait les fragments et devait être généré de manière aussi proche que possible de l’unicité mondiale. number donnait leur rang, à partir de 1. total annonçait le nombre attendu. L’ordre d’écriture des paramètres n’avait aucune importance.

Le dernier fragment devait contenir total. Les précédents pouvaient l’omettre, même si les versions ultérieures recommandaient de l’indiquer. Cette asymétrie permettait de commencer une découpe avant de connaître le nombre final, tout en donnant au destinataire une borne à l’arrivée de la dernière pièce déclarée.

Le RFC 1521, révision de 1993, a maintenu ce dispositif et en a précisé les contraintes. Mais ni l’ancien ni le nouveau texte ne faisaient de id une empreinte. Deux contenus différents pouvaient porter la même valeur, par erreur ou malveillance. Deux exemplaires du même number pouvaient diverger. Un total égal à six ne prouvait pas que les six rangs avaient été reçus, encore moins qu’ils provenaient de la même autorité.

Le champ établissait une proposition de regroupement. L’agent local devait encore vérifier une suite continue de 1 à la borne, traiter les doublons, refuser les contradictions, limiter les ressources et analyser le résultat. La coordination commune s’arrêtait là où commençait le jugement d’exécution.

L’échafaudage devait disparaître

Une fois les fragments assemblés, MIME voulait restituer une entité complète avec son propre Content-Type. Un grand contenu audio devait redevenir un contenu audio, non un message affiché comme contenant un autre message qui contenait de l’audio. L’encapsulation partielle était dite transparente.

Cette transparence séparait deux identités. Les enveloppes extérieures pouvaient avoir des Message-ID distincts parce qu’elles avaient suivi des voyages distincts. L’entité intérieure pouvait avoir son propre Message-ID et sa propre description de média. Les premiers identifiants documentaient les unités livrées ; le second nommait le message reconstitué. Les fusionner aurait confondu le chemin avec l’objet.

Il en allait de même pour l’ordre. La pièce 3 pouvait arriver avant la pièce 1. Les heures d’arrivée renseignaient les files et les routes, mais number décidait de la concaténation. Une observation de transport n’acquérait pas, par sa seule antériorité, le pouvoir de récrire le contenu.

La première enveloppe n’était pas seulement le premier bloc

Assembler les corps ne suffisait pas. Chaque message extérieur apportait des en-têtes qui pouvaient se contredire. MIME a donc établi une règle précise de fusion et exigé que la fragmentation se fasse uniquement aux limites de ligne.

Les en-têtes ordinaires de la première enveloppe étaient conservés, à l’exception des champs commençant par Content- et de Subject, Message-ID, Encrypted et MIME-Version. Ces champs particuliers venaient de l’entité intérieure et étaient ajoutés au résultat. Les autres en-têtes intérieurs étaient abandonnés. Enfin, tous les en-têtes de la deuxième enveloppe et des suivantes étaient exclus de l’entité reconstruite.

Le RFC 2046, qui a stabilisé ces règles en 1996, attribuait donc des pouvoirs différents. La première enveloppe fournissait le contexte extérieur survivant. Le message intérieur fournissait le type et les champs sémantiques retenus. Les autres enveloppes restaient des preuves de trajets séparés, mais ne participaient pas à un vote sur l’en-tête final.

Une conservation sérieuse garde les deux niveaux. Les enveloppes brutes sont nécessaires pour expliquer un retard, une duplication ou une authentification divergente. L’entité dérivée sert à l’application. Effacer les premières parce que la seconde paraît propre transforme une opération locale en faux fait de transport.

Le chemin le plus faible imposait le 7bit

La fragmentation créait un piège particulier pour les contenus 8bit ou binaires. Une enveloppe de type message ne pouvait pas simplement recevoir un encodage extérieur base64 ou quoted-printable. Si les fragments binaires empruntaient des passerelles différentes, aucune passerelle isolée ne pouvait attendre tout l’ensemble, reconstituer le message, l’encoder puis redistribuer correctement les autres pièces qu’elle ne verrait jamais.

Le choix fut donc conservateur. Les entités message/partial devaient employer le transfert 7bit, et l’entité intérieure ne devait pas dépendre d’un encodage 8bit ou binary. Le RFC 2045 définissait le cadre général des encodages ; le RFC 2046 appliquait cette restriction plus stricte aux fragments.

Cette règle ne sacrait aucune passerelle comme point central. Elle préparait chaque fragment pour un socle commun que des routes indépendantes pouvaient transporter. Le coût était une représentation moins directe ; le bénéfice était de ne pas supposer une visibilité globale qui n’existait pas.

Des seuils différents pouvaient aussi provoquer une fragmentation imbriquée. Après un premier réassemblage, le résultat pouvait encore être un autre message/partial. La norme l’autorisait explicitement. L’agent devait reconnaître la nouvelle couche et recommencer, sous des limites locales, plutôt que supposer qu’une seule passe racontait toute l’histoire.

SIZE annonçait une limite, il ne reconstruisait rien

Le RFC 1870 a ajouté en 1995 l’extension SMTP SIZE. Un serveur pouvait annoncer son maximum fixe ; un client pouvait déclarer une estimation avant de transmettre le corps. Un refus évident pouvait ainsi intervenir avant l’envoi complet.

SIZE n’avait cependant pas la même fonction que message/partial. Il négociait l’admission d’un message sur une liaison SMTP. Le type MIME organisait plusieurs messages déjà transportés pour un agent utilisateur. L’acceptation d’une taille n’était pas une garantie absolue de transfert ou de livraison, et ne disait rien sur la capacité du lecteur à réassembler.

L’un rendait visible un plafond local plus tôt. L’autre conservait une signification à travers plusieurs plafonds. Raconter le premier comme l’abolition du second masquerait la séparation des couches qui faisait précisément leur utilité.

La bonne preuve conserve trois histoires

Pour auditer un ensemble, il faut distinguer le journal des enveloppes, celui du groupe et celui de la reconstruction. Le premier garde octets bruts, Message-ID extérieur, Received, heure et résultat de livraison. Le deuxième normalise id, rangs, bornes annoncées, doublons, manques et expiration. Le troisième note le choix de chaque rang, la concaténation, la fusion des en-têtes, le type obtenu et toute nouvelle couche partielle.

Les contrôles d’origine, d’intégrité et de sûreté viennent ensuite. Des fragments numériquement complets peuvent contenir un objet dangereux. Des résultats d’authentification peuvent différer d’une enveloppe à l’autre. Un parseur peut réussir alors qu’une signature échoue. La reconstruction ne prouve ni l’affichage ni la lecture.

Le succès historique de cette petite grammaire tient à sa modestie. Elle permettait à des acteurs indépendants de s’accorder sur l’ordre sans créer une autorité centrale sur le contenu. Elle décrivait les conditions d’un essai local ; elle ne déclarait pas l’objet vrai avant que le code du destinataire ne l’ait effectivement produit.