Resumen

  • Una palabra codificada de la RFC 2047 representa texto no ASCII en lugares concretos de la cabecera; al decodificarla se obtiene una presentación, no la identidad del remitente.
  • La evidencia auditable separa los bytes, el análisis del campo, el charset, el buzón, la cobertura de firma y lo que finalmente mostró cada cliente.

Un mismo nombre acentuado puede llegar encerrado en UTF-8 con codificación Q, en otro juego de caracteres o dividido entre varias palabras codificadas. También puede preceder a buzones distintos. Cuando el cliente reduce todo a una ficha de contacto con el nombre en grande, los caminos anteriores desaparecen de la vista. No desaparecen del mensaje.

Ese fue el problema de compatibilidad que resolvió la RFC 2047. Publicada en 1996 y firmada por Keith Moore, forma parte de la arquitectura MIME. Las cabeceras de correo heredaban una representación ASCII y debían cruzar programas capaces de replegar líneas, reordenar campos o fallar ante rasgos legales pero poco usados. A la vez, los usuarios necesitaban asuntos, comentarios y nombres en sus propias lenguas. La norma reservó una secuencia ASCII reconocible para llevar el texto hasta un lector capaz de reconstruirlo.

La secuencia adopta la forma =?charset?encoding?encoded-text?=. El charset explica cómo interpretar los octetos. La codificación inicial es Q o B: B coincide con Base64 en MIME; Q se aproxima a quoted-printable y usa el guion bajo para representar un espacio. Cada unidad completa tiene un máximo de 75 caracteres y la línea que la contiene, 76. Una frase larga puede dividirse en varias unidades.

Nada en esos delimitadores acredita a la persona que aparece después de la decodificación. Son una factura de representación.

La gramática ocurre antes que la pantalla

RFC 2047 enumera los lugares permitidos. Una palabra codificada puede reemplazar texto en Subject y otros campos textuales, aparecer en un comentario o actuar como palabra dentro de una frase, como el nombre visible de una dirección. No puede ocupar un addr-spec, una cadena entre comillas, Received ni parámetros estructurados de Content-Type o Content-Disposition.

La restricción impide una confusión decisiva. El software analiza primero un campo estructurado y fija sus tokens. Solo después reconoce la palabra codificada y prepara su texto para mostrarlo. Si la decodificación revela un @, una coma o un ángulo, el signo puede verse igual que la puntuación del campo, pero no se vuelve sintaxis retroactivamente. El decodificador no debe enviar la salida de nuevo al analizador como si acabara de recibir otra dirección.

La RFC 5322 describe una dirección con dos componentes que la interfaz suele mezclar: un nombre de presentación opcional y un addr-spec. El primero sirve al lector; el segundo forma el buzón. La misma norma da semánticas distintas a From y Sender: el primero expresa la autoría declarada y el segundo puede identificar al agente que efectuó la transmisión cuando no coincide con el autor. Son afirmaciones dentro del formato. No prueban por sí solas que una persona controlara la cuenta o autorizara la acción descrita.

Por eso «el nombre era el mismo» no es una comparación completa. Hay que preguntar qué nombre, derivado de qué bytes, unido a qué buzón y bajo qué resultado de autenticación.

La unión invisible entre palabras

La norma permite que varias palabras codificadas representen una frase larga. El espacio lineal que las separa se ignora al mostrar el resultado. Así, un pliegue necesario para transportar la cabecera no añade un espacio artificial al nombre. La consecuencia forense es que la cadena visible no reproduce fielmente la línea original.

Cada unidad debe contener octetos y caracteres completos; no es válido comenzar un carácter multiocteto en una y terminarlo en otra. Aun con esa disciplina, dos entradas distintas pueden converger en el mismo texto: charsets distintos, Q frente a B, posiciones de pliegue diferentes o elecciones equivalentes de representación.

También una sola entrada puede divergir. Un cliente que desconoce el charset puede enseñar la secuencia sin tocar, sustituirla por un aviso o intentar una aproximación. Ante material mal formado no está obligado a producir el mismo texto que otro lector, pero tampoco debe bloquear por ello todo el mensaje. Sin la versión del parser, las tablas de charset y la política de error, el registro del servidor no reconstruye exactamente la pantalla histórica.

Cuando UTF-8 viaja sin envoltorio

La RFC 6532 permite usar UTF-8 directamente en muchos cuerpos de cabecera dentro de un entorno internacionalizado compatible. Recomienda NFC y advierte que Unicode admite formas equivalentes y apariencias confusas. Es un camino más directo que la palabra codificada, no una fusión de todos los niveles.

La transición convive con archivos, pasarelas y software anterior. Una organización puede recibir hoy mensajes RFC 2047 y UTF-8 directo. Si su telemetría guarda solo la etiqueta visible, pierde la capacidad de decir qué mecanismo actuó, si hubo conversión o sustitución y en qué punto nació una diferencia.

La firma no firma una impresión humana

La RFC 6376 trabaja sobre otra superficie. DKIM canonicaliza el cuerpo y los campos elegidos por el firmante, verifica una firma y produce como identidad responsable principal un dominio de firma. El resultado puede demostrar que la entrada cubierta sobrevivió bajo esa clave y esas reglas. No garantiza que todos los campos visibles estuvieran cubiertos ni convierte el nombre decodificado en una persona acreditada.

Una interfaz puede colocar un indicador de firma junto al nombre. La proximidad gráfica no amplía el alcance criptográfico. Para explicar la unión hay que conservar la instancia de From, los campos incluidos, la canonicalización, el dominio firmante, el buzón que analizó RFC 5322 y los pasos de RFC 2047 que terminaron en el nombre. «Firma válida» y «texto bien mostrado» pueden ser verdades simultáneas y separadas.

Un registro que permita volver atrás

La evidencia mínima comienza por el punto de observación y un hash protegido de la cabecera bruta. Añade orden de campos, pliegues, finales de línea, versión del parser, límites de tokens y posiciones reconocidas como palabras codificadas. Conserva charset, método Q o B, éxito o error, política de reemplazo, puntos de código y normalización aplicada.

El nombre visible y el addr-spec deben ocupar campos diferentes. La firma aporta su propia lista: cabeceras cubiertas, canonicalización, resultado y dominio. El último tramo registra la cadena realmente presentada, idioma, fuente de respaldo, dirección de escritura y advertencias. Si falta la entrada bruta o el contexto del cliente, el informe debe decir «no reconstruible» en vez de inferirlo del nombre.

No se trata de almacenar correo personal indefinidamente. Las cabeceras pueden ser sensibles; se requieren minimización, controles de acceso y plazos proporcionados. El objetivo es guardar solo lo necesario para justificar una decisión de identidad o atribución.

El perfil de Keith Moore en IETF documenta sus RFC. Un artículo histórico de 2008 conservado por el laboratorio ICL de University of Tennessee sitúa allí su actividad entre 1991 y 2007 y su participación en grupos de IETF desde 1990. Esos datos son históricos, no un cargo presente. Su aportación concreta en este caso fue diseñar una frontera: el texto internacional podía hacerse legible sin convertir la lectura en prueba del remitente.

Fuentes