Résumé

  • RFC 5259 impose de laisser intactes les données du message stocké, tandis que le serveur renvoie un dérivé demandé ou choisi par sa propre politique ; son utilité ne prouve ni l’identité des octets ni l’authenticité de la signature.
  • Un statut final OK peut accompagner des conversions partielles en échec, et une conversion par défaut peut supprimer des détails ou remplacer des caractères : la preuve doit donc rester attachée à chaque élément retourné.

Une preuve visuelle qui n’était plus une preuve cryptographique

Un membre du comité a ouvert sur téléphone un document contractuel. Le serveur avait transformé la pièce jointe dans un format pris en charge, réduit l’image et restitué une page nette. Le sceau visuel figurait toujours au bas du document. Le lecteur a conclu que le fichier affiché était celui qui avait été signé.

RFC 5259 trace précisément la limite. Quand un serveur convertit une partie signée, le client ne peut plus vérifier l’authenticité du contenu converti au moyen de la signature d’origine. S’il ne fait pas confiance au serveur pour cette opération, il doit télécharger l’objet signé, vérifier sa signature, puis effectuer lui-même la conversion.

La conversion n’est pas défectueuse pour autant. Elle résout un problème d’accès. Mais l’accessibilité du dérivé n’emporte pas les propriétés probatoires de la source. Une interface qui masque ce passage transforme un service pratique en attribution d’autorité.

La source stockée et le résultat livré sont deux objets

Le texte exige que la conversion n’affecte que ce qui est envoyé au client. Les données originales du magasin de messages ne doivent pas être modifiées. Cette règle préserve l’accès des autres clients, la matière des réponses et transferts, la structure MIME stockée et la possibilité de vérifier la signature de la source.

Le résultat peut pourtant changer de type MIME, de structure, d’encodage, de dimensions, de jeu de caractères et de taille. Il appartient à une exécution, pas au message canonique. Archiver uniquement le dérivé ne démontre pas que l’original a été remplacé ; l’appeler simplement « la pièce jointe » efface l’opération décisive qui l’a produit.

Il faut donc conserver deux identités : celle de la partie source, avec UID et empreinte, et celle de la sortie, avec requête, politique, paramètres et empreinte propres.

Découvrir une capacité ne prouve pas son exécution

Le serveur annonce CONVERT et BINARY. La commande CONVERSIONS indique les couples MIME source/cible et les paramètres pris en charge ; AVAILABLECONVERSIONS peut indiquer les cibles proposées pour une partie précise.

Ces réponses décrivent une surface de possibilités. Elles ne prouvent pas qu’une opération ultérieure disposera des ressources nécessaires, utilisera la même version du transcodeur, honorera tous les paramètres ou produira un affichage accepté par le terminal. Un chemin annoncé entre deux formats n’est pas une empreinte du résultat.

La disponibilité doit être horodatée séparément de l’exécution. Une panne temporaire, une valeur invalide ou un format propriétaire sans convertisseur peut faire échouer une demande pourtant plausible.

La conversion par défaut délègue un choix éditorial

Le client peut désigner un type cible ou fournir NIL et laisser le serveur choisir. Ce dernier peut utiliser les caractéristiques du terminal, les préférences de l’utilisateur ou de l’administrateur, sa configuration et son estimation des formats courants. La sélection exacte n’est pas entièrement définie par le RFC.

Le serveur peut supprimer un niveau de détail qui excède les capacités supposées de l’appareil, par exemple redimensionner une image. Il devrait limiter la perte en l’absence de renseignement fiable, mais cette recommandation n’est pas une garantie d’équivalence sans perte.

Le RFC conseille au client d’éviter ce mode s’il n’a pas communiqué ses capacités, car le serveur peut se tromper. Demander NIL, c’est déléguer le choix de ce que verra l’être humain, pas seulement déléguer du calcul. Le reçu doit nommer la cible retenue et les données de politique qui ont conduit à ce choix.

Une réussite peut intégrer une perte volontaire

La conversion de texte nécessite un jeu de caractères cible. Si certains signes ne peuvent y être représentés, unknown-character-replacement permet de fournir une chaîne de remplacement. La sortie peut être valide tout en ayant perdu une information précise.

Les mots encodés des en-têtes et les paramètres MIME ajoutent d’autres transformations. Une réécriture peut conserver un sens attendu sans conserver les octets. À l’inverse, un caractère de remplacement visuellement discret peut cacher la disparition d’un nom, d’un montant ou d’un symbole.

Les plages partielles de CONVERT BINARY portent sur les données transcodées et décodées, non sur les offsets de la source stockée. Une coordonnée du dérivé ne peut donc pas servir de référence à l’original.

OK ne signifie pas que tout a réussi

Les réponses CONVERTED peuvent contenir TEMPFAIL, BADPARAMETERS ou MISSINGPARAMETERS. Une même commande peut demander plusieurs éléments. Dès qu’au moins une conversion réussit, le résultat balisé doit être OK. Même si toutes échouent, le serveur peut répondre OK ou NO.

Le voyant vert au niveau de la commande ne suffit donc pas. Une partie peut être disponible tandis qu’une autre manque ; la structure peut avoir été retournée alors que les octets ont échoué. Le client doit rapprocher chaque élément demandé de chaque donnée ou erreur reçue.

BODYPARTSTRUCTURE indique généralement si la demande a été respectée exactement, sans toujours expliquer toute la cause. Cette structure est une pièce du reçu, pas un label abstrait de succès.

Ni état de lecture ni état canonique

CONVERT ne positionne jamais l’indicateur \Seen. Le client doit effectuer un STORE distinct s’il veut marquer le message comme lu. La production de données converties ne prouve donc ni leur affichage par une personne ni un changement d’état du courrier.

Le serveur peut mettre en cache des conversions, avec des limites recommandées contre le déni de service. Ce cache est un état d’exécution temporaire. Il ne crée pas une pièce jointe canonique ni la certitude qu’une requête identique donnera plus tard les mêmes octets.

Pour rendre une décision reproductible, il faut préserver la sortie réelle et la version du transcodeur, la politique, les codecs, les paramètres et la connaissance du terminal.

Le transcodeur est une frontière de sécurité

Une pièce conçue avec soin puis APPEND et CONVERT peut attaquer un parseur. Un redimensionnement extrême peut épuiser les ressources. Une conversion dangereuse peut produire un exécutable. Le RFC recommande de refuser les opérations coûteuses ou risquées, de vérifier les sorties, de journaliser l’identité authentifiée et d’isoler le convertisseur du magasin privilégié.

Un service externe ajoute un saut de garde. Le placer dans le même domaine de confiance réduit l’exposition sans faire disparaître la transmission. L’identité du service, les octets reçus et ceux retournés doivent rester inspectables.

L’authentification SASL/TLS du serveur sécurise le canal et le pair. Elle ne rend pas le dérivé vérifiable sous la signature de la source.

Construire un reçu source-vers-dérivé

Conservez boîte, UIDVALIDITY, UID, partie source, structure MIME, taille et empreinte ; types demandés, paramètres, choix explicite ou par défaut, capacités déclarées, préférences, politique et version du serveur ; transcodeur, instant et domaine de sécurité.

Ajoutez chaque élément CONVERTED, chaque erreur et le statut final ; structure, taille et empreinte de sortie ; détails supprimés, caractères remplacés, cache ; verdict de signature de l’original, absence d’héritage de ce verdict par le dérivé ; résultat d’affichage, état \Seen et action métier déclenchée.

La formulation doit rester exacte : « ce serveur a produit ces octets pour cette requête » est testable. « voici la pièce jointe signée » exige une authentification couvrant ces nouveaux octets. « la conversion a réussi » reste incomplet tant que chaque élément n’a pas son résultat.

RFC 5259 a offert aux clients contraints une couche d’adaptation utile. La responsabilité dirigeante consiste à empêcher qu’une représentation accessible usurpe l’identité de la source authentifiée.

Sources