Resumen

  • RFC 5259 obliga a mantener intactos los datos originales del almacén mientras devuelve un derivado solicitado o seleccionado por el servidor; que se vea bien no prueba identidad de bytes, autenticidad de firma ni sustitución permanente.
  • Un OK final puede coexistir con fallos parciales, y la conversión predeterminada puede quitar detalle o reemplazar caracteres, por lo que la evidencia debe conservarse por elemento y por salida.

El comité aprobó la versión que el servidor había decidido mostrar

La tableta no podía abrir el formato original. El servidor eligió otro, redujo las imágenes y devolvió un contrato perfectamente legible. El sello visual seguía en la página. La reunión continuó como si los bytes mostrados fueran los que habían recibido la firma.

El RFC separa esas capas. Tras convertir en el servidor una parte firmada, el cliente no puede verificar la autenticidad del contenido convertido con la firma original. Si no confía en el servidor, debe descargar y verificar el objeto firmado y convertirlo localmente.

La utilidad del resultado no está en duda. Lo que no puede hacerse es transferir por apariencia la autoridad criptográfica de la fuente. La representación accesible y el objeto autenticado son hechos distintos.

El mensaje guardado no es la salida de una ejecución

La conversión solo afecta lo enviado al cliente. Los datos del almacén no deben alterarse. Así otros clientes conservan el original, las respuestas y reenvíos pueden usarlo, la BODYSTRUCTURE almacenada permanece y la firma puede comprobarse sobre su objeto real.

El derivado puede tener otro tipo MIME, estructura, codificación, dimensiones, caracteres y tamaño. Pertenece a una solicitud concreta. Guardarlo en un archivo no demuestra que el original cambiara; mostrarlo sin decir “convertido” borra la procedencia que permite interpretarlo.

La organización necesita una identidad de fuente y una identidad de salida, cada una con su hash. Ninguna descripción visual reemplaza esa pareja.

Disponibilidad no es ejecución

El servidor anuncia CONVERT y BINARY. CONVERSIONS descubre pares fuente/destino y parámetros; AVAILABLECONVERSIONS enumera destinos para una parte. Es un mapa de posibilidades, no un recibo de bytes.

La operación posterior puede encontrar falta de recursos, un servicio caído, parámetros inválidos o un formato sin transcodificador. También puede ejecutarse con otra versión o política. Que una ruta exista no demuestra que se recorrió ni qué se produjo.

Registre por separado el inventario anunciado y la ejecución observada, con tiempos y revisiones propios.

NIL entrega al servidor la selección de lo visible

El cliente puede pedir un tipo exacto o usar NIL para una conversión predeterminada. El servidor puede decidir con conocimiento del dispositivo, preferencias del usuario o administrador, configuración y formatos que considere comunes. El algoritmo exacto queda fuera del contrato.

Además puede retirar detalle que supere las capacidades del dispositivo, como reducir una imagen. Debe intentar minimizar la pérdida cuando carece de información, pero eso no promete equivalencia sin pérdida.

El propio RFC advierte que el servidor puede adivinar mal. La elección predeterminada delega una decisión de presentación con consecuencias editoriales: cuál versión verá la persona. El recibo debe explicar el tipo elegido y las señales que gobernaron la elección.

Una conversión válida puede perder información

La conversión textual necesita un charset. Si un carácter no cabe en él, unknown-character-replacement permite sustituirlo. Una salida correcta según la petición puede haber eliminado la diferencia entre dos nombres, símbolos o cantidades.

Las palabras codificadas de cabeceras y los parámetros MIME también se decodifican y vuelven a codificar. Puede preservarse una lectura sin conservar los octetos. La fidelidad debe descomponerse en bytes, texto, estructura, diseño, dimensiones y detalle omitido.

Los rangos parciales de CONVERT BINARY se refieren a datos transcodificados y decodificados, no a offsets del original. Citar la posición del derivado como coordenada fuente produce una referencia falsa.

El verde de la orden puede contener errores

Las respuestas CONVERTED incluyen resultados o errores como TEMPFAIL, BADPARAMETERS y MISSINGPARAMETERS. Si al menos una conversión funciona, la respuesta final debe ser OK; incluso si todas fallan, puede ser OK o NO.

Por eso el estado de la orden no resume los elementos. Una parte puede convertirse y otra no; puede llegar estructura sin bytes. El cliente debe reconciliar cada petición con cada valor o error recibido.

BODYPARTSTRUCTURE suele mostrar si se respetó exactamente la solicitud, aunque no siempre explique la causa. Debe guardarse con los parámetros y el hash, no reducirse a una insignia de éxito.

Convertir no marca leído ni crea un nuevo canon

CONVERT nunca establece \Seen. Marcar el mensaje requiere un STORE separado. Haber producido bytes no demuestra que una persona los leyó ni que el estado del buzón cambió.

El servidor puede almacenar resultados en caché, con límites contra abuso. Esa caché no es un adjunto alternativo duradero ni asegura que la misma petición devuelva mañana lo mismo. Versiones del codec, fuentes, políticas y servicios externos pueden variar.

Si una decisión depende de la salida, conserve la salida real y todo el contexto que la hizo reproducible.

El transcodificador ocupa una frontera privilegiada

Un mensaje diseñado y enviado por APPEND antes de CONVERT puede atacar un parser vulnerable. Un escalado extremo puede agotar recursos. Una transformación peligrosa puede generar ejecutables. El RFC pide evitar conversiones riesgosas o costosas, verificar resultados cuando sea posible, registrar la identidad autenticada y aislar las bibliotecas del almacén privilegiado.

Un servidor externo añade una transferencia de custodia. Estar en el mismo dominio de confianza reduce, pero no elimina, ese límite. Deben quedar el servicio, la entrada y la salida.

SASL/TLS autentica al servidor y protege el canal. No autentica los nuevos bytes con la firma aplicada a los antiguos.

Un recibo que una fuente y derivado sin confundirlos

Conserve buzón, UIDVALIDITY, UID, parte fuente, MIME, tamaño y hash; tipos y parámetros solicitados; objetivo explícito o predeterminado; capacidades declaradas; preferencias, política, versión y transcodificador; instante y dominio de ejecución.

Añada todos los elementos CONVERTED, errores y estado final; MIME, tamaño y hash derivados; reducciones y reemplazos; caché; verificación de la firma fuente y no herencia en la salida; resultado del visor; \Seen; y la decisión posterior.

“El servidor produjo estos bytes para esta solicitud” es comprobable. “Este es el adjunto firmado” necesita autenticación sobre esos bytes. “La conversión fue exitosa” requiere que cada elemento tenga su propio resultado.

RFC 5259 hizo posible adaptar contenido para clientes limitados. La disciplina institucional consiste en usar esa comodidad sin permitir que el derivado suplante a la fuente autenticada.

Fuentes