Resumen

  • El cliente solo podía declarar BODY=8BITMIME y enviar octetos con el bit alto después de que el servidor anunciara 8BITMIME en el EHLO de esa sesión.
  • La aceptación imponía preservar cada bit; ante un siguiente salto incapaz, el relé debía producir MIME válido de siete bits sin pérdida o declarar un fallo permanente.

El formato no ensanchaba el camino

MIME resolvió cómo nombrar tipos de contenido, juegos de caracteres y codificaciones. No modificó automáticamente el transporte SMTP. RFC 2045 distingue los dominios 7bit, 8bit y binary: un cuerpo correctamente descrito podía contener octetos que el siguiente sistema nunca había prometido conservar.

Así apareció una pregunta de autoridad operativa. No bastaba con saber qué significaba el mensaje. Había que saber quién había aceptado su representación exacta y hasta dónde llegaba ese compromiso.

Una promesa estrecha sobrevivió a tres RFC

RFC 1426 publicó la primera extensión en febrero de 1993. RFC 1652 la sustituyó en julio de 1994, y RFC 6152 sustituyó a RFC 1652 en marzo de 2011. La secuencia demuestra continuidad documental, no un porcentaje actual de uso.

El servidor incluye 8BITMIME en una respuesta EHLO 250. El registro de extensiones SMTP de IANA conserva la palabra clave sin parámetro EHLO y remite a RFC 6152. No se añade un verbo nuevo.

El cliente puede añadir BODY=7BIT o BODY=8BITMIME a MAIL FROM. BODY describe el dominio de octetos que llegará por DATA; no declara idioma, tipo de medio ni juego de caracteres. Transporte y significado siguen siendo capas diferentes.

El permiso pertenecía a la sesión presente

Antes de enviar un cuerpo de ocho bits, el cliente debe obtener una respuesta EHLO exitosa que contenga la capacidad. Si falta, no puede transmitir octetos fuera del rango US-ASCII. Que TCP mueva bytes arbitrarios o que el mismo producto los aceptara ayer no sustituye la evidencia de esta conexión.

El alcance termina en ese salto. Un relé que acepta el mensaje puede encontrar después otro servidor sin 8BITMIME. La promesa del primero no certifica al segundo ni garantiza que el programa del destinatario sepa representar los caracteres.

Aceptar significaba custodiar todos los bits

El servidor capaz debe preservar todos los bits de cada octeto recibido mediante DATA y mantenerlos al entregar o retransmitir. El compromiso atraviesa el spool, los filtros, las colas y el proceso saliente. Si un componente interno recorta el bit alto, el anuncio del frontal era falso en la práctica.

La obligación no autentica al remitente, no hace seguro el contenido y no garantiza entrega. Solo fija una responsabilidad verificable: los octetos aceptados no pueden mutar por una vieja suposición de siete bits.

Ocho bits no eran binario arbitrario

DATA mantiene el relleno de puntos, la línea con un punto como terminador y la estructura CRLF. También conserva límites de línea; RFC 6152 permite que un servidor limite una línea a 1.000 octetos, CRLF incluido.

Por eso 8BITMIME permite la codificación MIME 8bit, pero no binary. Amplía los valores dentro de la línea sin eliminar la línea. CHUNKING y BINARYMIME pertenecen a otra transición de encuadre.

La frontera siguiente exigía transformar o fallar

Cuando el próximo servidor no anuncia la extensión, el relé no puede enviar el cuerpo ocho bits por intuición. Puede transformarlo en MIME válido de siete bits sin perder información, usando una codificación de transferencia adecuada, o tratar la barrera como un error permanente.

RFC 6152 no prescribe el convertidor. Una reescritura segura debe mantener cabeceras, límites multipartes, finales de línea y coherencia de las etiquetas. También puede afectar firmas. Producir bytes bajos no basta si el lector recibe otro significado. Allí donde no existe prueba de conversión, el fallo explícito protege mejor el mensaje.

Una declaración organizaba pruebas

BODY=8BITMIME es una afirmación del cliente, no verdad automática. La operación debe registrar lo anunciado por el servidor, lo declarado por el cliente, el dominio realmente observado y la decisión tomada ante el próximo salto. Solo esa cadena permite localizar una corrupción.

La contribución histórica fue hacer local la promesa. MIME describía la carga; 8BITMIME decía si este custodio aceptaba su representación; la siguiente conexión volvía a preguntar.

Fuentes y límites

La historia normativa está en RFC 1426, RFC 1652 y RFC 6152. RFC 2045 define los dominios MIME y el registro IANA mantiene la entrada. Las fuentes no miden adopción, volumen ni fallos modernos.