Resumen

  • RFC 1524 hizo que varios lectores consultaran reglas mailcap: el mensaje declaraba un Content-Type, pero la precedencia local escogía la orden de ver, componer, editar, imprimir o probar.
  • En UNIX, la regla aplicable podía transformarse en una línea para el Bourne shell con parámetros y archivos temporales sustituidos. Coincidir, superar un test o terminar con éxito no probaba autenticidad, seguridad ni intención humana.

La extensión era una necesidad del programa, no una prueba

El correo multimedia exigía algo más que transportar octetos. MIME podía llamar image/gif a una parte, pero el receptor todavía necesitaba un programa disponible y una manera común de encontrarlo. Cada lector de correo codificado con su propia lista de aplicaciones habría convertido cada formato nuevo en una campaña de actualizaciones.

RFC 1524 propuso que lectores distintos compartieran una descripción externa de las capacidades instaladas. Una línea mailcap asociaba un patrón de tipo con una acción local. Así, incorporar un binario y una regla podía ampliar varios agentes sin obligar al remitente a conocer la plataforma receptora.

La solución funcionaba precisamente porque el acuerdo era pequeño. Internet compartía el nombre del tipo; la máquina conservaba el poder de elegir el programa.

La política era la secuencia completa

El agente construía su configuración mediante la concatenación virtual de varios archivos. Buscaba la primera entrada cuyo tipo coincidiera, que ofreciera la operación necesaria y cuyo test= opcional devolviera éxito. No bastaba fotografiar una sola línea: el orden de todas las fuentes decidía cuál era efectiva.

En la propuesta para UNIX, el archivo personal aparecía antes que los del sistema. Además, MAILCAPS podía sustituir la ruta de búsqueda. El diseño permitía que una persona ampliara o anulara la política del sitio. También significaba que dos usuarios, con el mismo mensaje y el mismo software de correo, podían ejecutar herramientas diferentes sin que el encabezado cambiara.

La entrada distinguía capacidades. Había un comando obligatorio para visualizar y campos separados para componer, producir contenido con tipo propio, editar, imprimir y probar el entorno. needsterminal pedía un terminal; copiousoutput avisaba al agente que debía paginar o permitir desplazamiento. Poder abrir no implicaba poder editar ni crear.

El test podía verificar una pantalla X, una arquitectura o un dispositivo de audio. Un cero decía que la regla era aplicable a esa máquina. No decía que el objeto recibido hubiera sido examinado o fuera benigno.

Los valores del mensaje entraban en una orden local

La semántica UNIX trataba cada acción como una línea completa para el Bourne shell, equivalente a anteponer /bin/sh -c. La plantilla aceptaba %t para el tipo, %{nombre} para un parámetro, %n para el número de partes y %F para una lista de tipos y archivos. %s representaba el fichero con el cuerpo.

Por eso la trazabilidad debía atravesar varias capas. El analizador obtenía metadatos, elegía una regla, resolvía escapes, insertaba valores, construía argumentos y entregaba texto ejecutable al sistema. Un encabezado sintácticamente válido no demostraba que el agrupamiento de argumentos fuera el previsto. Que el proceso arrancara tampoco demostraba que leyera o mostrara el objeto correcto.

Sin %s, ver o editar consumía el cuerpo por la entrada estándar. Con %s, el agente podía crear un archivo temporal. El RFC advertía que no debía suponerse que ese archivo sobreviviría al final de la orden; un programa que continuara en segundo plano tenía que guardar su propia copia.

nametemplate daba al temporal una forma útil, como una terminación .gif. Era una convención para satisfacer al visor. No comparaba la etiqueta con el contenido, no autenticaba al autor y no concedía permiso para ejecutar.

Crear contenido también repartía responsabilidades

Un programa compose entregaba datos que el cliente etiquetaría con el tipo de la regla. composetyped podía emitir su propio Content-Type y otros encabezados. La codificación necesaria para atravesar el correo seguía siendo responsabilidad del programa llamante, salvo declaración explícita.

La creación quedaba separada en productor, bytes, etiqueta, codificación de transporte y mensaje enviado. El éxito de uno no certificaba los demás.

El aviso de seguridad no contó un incidente

RFC 1524 señaló que el mecanismo podía facilitar problemas de seguridad de MIME y pidió cautela al elegir programas para ejecución automática. No atribuyó un ataque, una vulnerabilidad concreta o un comportamiento universal. Su evidencia es arquitectónica: un dato remoto puede alcanzar una acción potente sólo porque una política local decide conectarlos.

RFC 2045, 2046 y 2048 revisaron MIME; RFC 6838 actualizó el registro de tipos. Registrar un nombre mejora documentación e interoperabilidad. No instala un visor, no prueba qué regla ganó y no autoriza abrir el contenido.

Una investigación rigurosa conserva el mensaje, tipo y parámetros; las fuentes mailcap y su precedencia; la acción solicitada; la entrada y el test seleccionados; la orden expandida; el canal por stdin o temporal; el proceso, su salida y los efectos; y la decisión del destinatario. Reducir todo a «se abrió el adjunto» borra el momento en que la descripción adquirió autoridad.

Fuentes