Résumé

  • Un client ne pouvait annoncer BODY=8BITMIME et envoyer des octets à bit fort qu’après l’offre 8BITMIME du serveur dans la réponse EHLO de cette connexion.
  • L’acceptation obligeait à préserver tous les bits ; devant un relais suivant incapable, il fallait produire un MIME sept bits valide sans perte ou constater un échec permanent.

Le contenu n’élargissait pas le chemin

MIME permit de nommer le type d’un contenu, son jeu de caractères et son encodage de transfert. Ce vocabulaire ne modifiait pourtant pas le transport SMTP. RFC 2045 distingue les domaines 7bit, 8bit et binary : une partie MIME parfaitement décrite pouvait contenir des octets qu’un relais ancien n’avait jamais promis de garder.

La difficulté n’était donc pas seulement linguistique. Elle portait sur l’attribution d’une responsabilité. Qui avait effectivement accepté le huitième bit, sur quelle connexion, et que devait faire le relais lorsqu’un maillon suivant ne prenait pas le même engagement ?

Une petite extension, révisée trois fois

RFC 1426 publia le premier contrat en février 1993. RFC 1652 le remplaça en juillet 1994, puis RFC 6152 remplaça RFC 1652 en mars 2011. Cette chronologie établit la filiation normative, pas un taux d’adoption contemporain.

Le serveur ajoute le mot 8BITMIME à une réponse EHLO réussie. Le registre IANA des extensions SMTP conserve cette entrée, sans paramètre EHLO, et renvoie à RFC 6152. Aucun nouveau verbe SMTP n’est créé.

Le client peut ajouter à MAIL FROM un paramètre BODY, valant 7BIT ou 8BITMIME. Cette déclaration porte sur le domaine d’octets du corps à venir. Elle ne dit ni langue, ni jeu de caractères, ni type de média. Confondre transport et signification reviendrait à prendre une largeur de route pour l’adresse de la cargaison.

L’annonce locale ouvrait la voie locale

Avant d’envoyer un corps huit bits, le client doit émettre EHLO et recevoir un code 250 contenant 8BITMIME. Sans cette preuve, il lui est interdit d’envoyer des octets hors de la plage US-ASCII. TCP sait transporter huit bits, mais cette capacité de la couche inférieure ne donne pas au logiciel SMTP le droit de les accepter correctement.

L’annonce vaut pour la session et pour ce saut. Un relais peut accepter le message puis découvrir qu’un serveur suivant ne propose pas l’extension. La première promesse ne certifie pas le chemin entier, pas plus qu’elle ne garantit que le lecteur final interprétera le jeu de caractères.

Accepter signifiait garder chaque bit

Après acceptation, le serveur doit préserver tous les bits de chaque octet transmis par DATA, puis livrer ou relayer le contenu de la même manière. Cette obligation traverse le spool, l’analyse antivirus, la file et le processus de sortie. Un frontal capable qui remet ensuite les données à un composant sept bits a fait une promesse que son code ne tient pas.

La promesse reste étroite. Elle n’authentifie ni l’expéditeur ni le contenu, ne prouve pas l’innocuité du message et ne garantit pas la livraison. Elle établit une garde exacte des octets sur le périmètre accepté.

Huit bits ne voulait pas dire binaire

DATA conserve son cadrage par lignes et sa transparence au point. Un point seul termine toujours le contenu transporté, les points en tête de ligne doivent toujours être doublés, et les limites de longueur demeurent. RFC 6152 rappelle qu’un serveur peut n’accepter que 1 000 octets, CRLF compris, sur une ligne.

L’extension autorise donc l’encodage MIME 8bit, mais pas binary. Le huitième bit change la valeur admissible dans une ligne ; il ne supprime ni les lignes ni le terminateur. L’histoire de CHUNKING et BINARYMIME répond à cet autre problème.

Le prochain relais imposait une décision

Si le prochain serveur n’annonce pas 8BITMIME, le client ne peut pas « essayer quand même ». RFC 6152 lui laisse deux voies. Il peut transformer le message en MIME sept bits valide, sans aucune perte d’information, au moyen d’encodages de transfert adaptés. Ou il peut traiter l’obstacle comme une erreur permanente de livraison.

Le RFC ne dicte pas l’algorithme. Une conversion engage les en-têtes, les limites multiparties, les fins de ligne et parfois les signatures. Obtenir uniquement des octets inférieurs à 128 ne suffit pas si le destinataire reconstruit un autre message. Quand la transformation ne peut être prouvée, l’échec explicite est plus fidèle qu’un succès corrompu.

Les preuves nécessaires

Une exploitation sérieuse distingue quatre faits : la capacité annoncée par le pair, la valeur BODY déclarée, le domaine réellement observé dans le corps et l’action prise à la frontière suivante. Leur confusion rend une lettre altérée impossible à attribuer.

Le mérite durable de 8BITMIME fut cette séparation. Le format disait ce que représentait le contenu. Chaque session disait si le prochain dépositaire acceptait ses octets. L’autorité s’arrêtait à la connexion suivante.

Sources et limites

La filiation vient de RFC 1426, RFC 1652 et RFC 6152. RFC 2045 définit les domaines MIME, tandis que le registre IANA atteste l’entrée actuelle. Ces textes ne mesurent ni déploiement, ni volume, ni fréquence de conversion.