Résumé

  • RFC 3516 autorisait un serveur IMAP à retirer le Content-Transfer-Encoding MIME et à renvoyer la section décodée avec BINARY, y compris des octets NUL dans un literal8. Cette vue n’était pas la sérialisation originale du message.
  • La taille, les décalages partiels, les fins de ligne, la représentation stockée, les en-têtes encodés et la frontière cryptographique restaient attachés à des états de données distincts.

Base64 rendait transportables des données arbitraires sur des chemins qui ne supportaient pas tous les octets. Mais un client IMAP pouvait alors télécharger une représentation agrandie pour la décoder aussitôt. Sur une liaison radio lente ou pour un média diffusé en continu, RFC 3516 voyait là un coût évitable.

Publié en avril 2003 sur le Standards Track, le document déplaçait la transformation vers le serveur. Un serveur annonçant la capacité BINARY pouvait recevoir FETCH BINARY, retirer l’encodage de transfert de la section MIME demandée, puis envoyer le résultat au client. Le gain de bande passante ne transformait pas ces octets en preuve du message original.

Toute section de corps IMAP possède un Content-Transfer-Encoding, déclaré dans le message ou implicitement fixé à 7bit. Dans MIME, ce champ ne désigne pas seulement un algorithme à inverser. Il indique aussi le domaine des données après décodage. Base64 et quoted-printable transforment visiblement la séquence. D’autres valeurs peuvent être identitaires tout en annonçant un domaine que le littéral IMAP de base ne peut pas exprimer.

Le serveur accomplissait donc deux opérations logiques. Il appliquait d’abord le décodage lié au CTE. Il déterminait ensuite le domaine du résultat. Obtenir une suite d’octets ne suffisait pas à choisir le bon élément de protocole pour la transporter.

RFC 3516 introduisit literal8 pour ce domaine plus large. La syntaxe commence par un tilde, annonce une longueur, puis accepte des octets quelconques, notamment NUL. Si la section décodée tient dans le domaine 8 bits sans NUL, le serveur devrait préférer une chaîne ordinaire. Le client peut ainsi connaître la restriction sans parcourir tout le flux à la recherche d’un zéro.

Le comptage du littéral est précis, mais il ne raconte pas le stockage. Il prouve la longueur de cet élément dans cette réponse IMAP. Il ne dit pas si le serveur conservait déjà la charge utile décodée, s’il vient de la reconstruire depuis base64, s’il a harmonisé des fins de ligne ou s’il emploie une autre représentation interne conforme.

BINARY.PEEK séparait encore une autre propriété. Comme BODY.PEEK, il évitait de positionner implicitement l’indicateur \\Seen. Cette garantie porte sur l’état de la boîte, pas sur l’origine des octets. Une réponse peut être correcte et ne pas marquer le message comme lu tout en restant une vue produite par le serveur.

BINARY.SIZE annonçait la taille de la section après décodage, donc le nombre d’octets promis par le FETCH BINARY correspondant. Ce n’était ni la longueur de la forme encodée, ni l’espace occupé dans le stockage, ni la taille du message complet. Le calcul pouvait coûter cher lorsqu’un serveur devait décoder toute la section uniquement pour la compter.

Les extractions partielles rendaient le référentiel essentiel. Les valeurs de <partial> s’appliquent à la section décodée. Une position dans le texte base64 ou dans une réponse FETCH BODY ne vise pas nécessairement le même contenu. Reprendre un transfert avec le compteur d’une autre représentation peut produire un fragment syntaxiquement valide mais logiquement déplacé.

Le protocole refusait d’inventer un résultat lorsque le décodeur ne savait pas agir. Pour un CTE inconnu, BINARY et BINARY.SIZE devaient échouer avec NO [UNKNOWN-CTE]. Ce reçu ne prouvait pas une corruption. Il établissait l’incapacité de ce serveur à exécuter la transformation demandée sous l’étiquette fournie.

RFC 4466 a ensuite remanié le cadre des codes de réponse IMAP, et RFC 9051 a intégré ces mécanismes à IMAP4rev2. Ces évolutions comptent pour interpréter une trace moderne. Elles ne rendent toujours pas identiques la forme encodée, la section décodée et la représentation conservée.

Les en-têtes relevaient d’un autre encodage. Les mots encodés de RFC 2047 permettent d’insérer du texte non ASCII dans certaines zones d’en-tête ; ils ne sont pas le CTE du corps MIME. RFC 3516 interdisait donc leur conversion lors d’un BINARY FETCH ou d’un APPEND. Décoder une section ne donnait pas pouvoir de réécrire tout ce qui ressemblait à un encodage.

Le texte subissait une normalisation contrôlée supplémentaire. Les sections orientées ligne devaient être transmises avec les fins de ligne CRLF d’IMAP, quelle que soit leur forme sur disque. Cette règle rendait l’interface cohérente, mais empêchait de présenter la réponse comme une photographie médico-légale des octets de fin de ligne locaux.

Le document explicitait même que l’interface ne révélait pas le stockage. Un serveur pouvait conserver le contenu binaire sans encodage. Pourtant, BODYSTRUCTURE devait décrire le message comme si les sections binaires portaient un CTE acceptable pour l’IMAP de base, et FETCH BODY devait produire cette forme annoncée. Le protocole exposait un contrat, pas la mémoire interne.

APPEND parcourait la frontière dans l’autre sens. Le client pouvait ajouter des données contenant NUL avec literal8. Si la boîte ne savait pas stocker le binaire, le serveur devait refuser avec UNKNOWN-CTE. Sinon, il pouvait changer le CTE des données ajoutées, à condition de ne perdre aucune donnée de charge utile.

L’absence de perte ne garantissait pourtant pas la même sérialisation. Base64, quoted-printable et une forme identitaire peuvent représenter la même charge utile avec des suites différentes. Le pliage des champs, les fins de ligne et l’étiquette CTE appartiennent au message sérialisé. Une transformation fidèle au contenu peut donc invalider une empreinte ou une signature portant sur cette forme.

RFC 3516 le signalait sans détour : des changements gratuits d’encodage rendraient inutiles la plupart des opérations cryptographiques déjà effectuées sur le message. Les deux promesses ne se contredisent pas. L’une concerne la récupération de la charge utile ; l’autre dépend des octets exacts et des champs inclus. Noter seulement « conversion sans perte » ne préserve pas l’entrée du vérificateur.

L’extension ne dispensait pas non plus les clients de savoir décoder. Elle optimisait certaines situations, elle ne créait pas un nouveau format de conservation universel. Même un client BINARY devait rester capable d’effectuer lui-même les décodages CTE fondamentaux. Une capacité annoncée améliore le chemin rapide ; elle ne justifie pas l’impossibilité de traiter le chemin ordinaire.

La distinction de Heng Lu entre réalité symbolique et réalité opérationnelle ordonne les preuves. BINARY dans CAPABILITY est une déclaration symbolique. BINARY.SIZE promet la longueur d’une réponse décodée. Le littéral compté montre une séquence sur une connexion. Les octets stockés, le message RFC 5322, la charge MIME, le rendu et l’entrée d’une signature appartiennent à des couches liées mais non substituables.

Une chaîne de reçus utile fixe l’identifiant du message et le contexte de lecture, puis conserve BODYSTRUCTURE, section, CTE, commande, effet sur \\Seen, réponse, domaine, longueur, décalage et empreinte des octets renvoyés. Si l’identité du message importe, elle ajoute une extraction brute et son empreinte. Si une signature importe, elle note exactement la canonisation et les octets consommés.

Deux assertions honnêtes cessent alors de paraître incompatibles. Le serveur a bien livré le corps décodé ; le fichier reçu n’a pourtant pas l’empreinte du message stocké ou transmis. RFC 3516 ne rendait aucune de ces observations fausse. Il définissait la transformation qui les sépare.

Son succès historique était concret : le contenu binaire n’avait plus à payer à chaque consultation IMAP la surcharge de l’encodage de transport. Sa leçon durable tient à la précision du reçu. Le serveur a décodé le corps. Le client a obtenu des octets utiles. Le message original exigeait encore sa propre extraction et sa propre preuve.

Sources