Resumen

  • draft-ietf-mailmaint-smtputf8-syntax-05, publicado el 10 de septiembre de 2026, sustituye una lista interna de clases permitidas por IdentifierClass de PRECIS y exige cumplir toda regla contextual aplicable.
  • La nueva versión excluye de forma ilustrada U+3164 HANGUL FILLER, que puede no dejar rastro en pantalla, y U+0640 ARABIC TATWEEL, que alarga la letra anterior y multiplica grafías visuales.
  • Superar este control solo habla de la cadena. No acredita que el buzón exista, que el solicitante lo controle, que toda la ruta admita SMTPUTF8 ni que el mensaje se entregue.
  • La redacción vigente conserva una discrepancia literal alrededor de un espacio entre comillas y la puntuación de la dirección. Corresponde aclararla públicamente, no ocultarla detrás de interpretaciones incompatibles.

El carácter que desapareció del panel

Un equipo antifraude compara dos altas. El panel presenta la misma dirección, pero una consulta de bytes revela una diferencia: una de las cadenas incorpora U+3164. En la tipografía del panel, HANGUL FILLER no ocupa nada visible. El dato no desapareció; desapareció la capacidad humana de verlo.

El registro puede guardarlo, el buscador puede retirarlo y el flujo de recuperación puede rechazarlo. Si el registro de auditoría conserva únicamente el texto renderizado, los tres comportamientos terminan bajo una sola apariencia. El operador ya no puede distinguir una transformación de un error de validación.

La revisión 05 de SMTPUTF8 Email Addresses añade precisamente ese ejemplo y lo declara no permitido. También incorpora U+0640 ARABIC TATWEEL. Aunque Unicode lo clasifica como letra, su función es prolongar el trazo anterior; repetirlo crea múltiples secuencias para formas que un lector puede considerar equivalentes.

El registro del Datatracker lo sitúa como Internet-Draft activo del grupo Mail Maintenance con destino Proposed Standard. El historial fecha la versión el 10 de septiembre. No es todavía un RFC, una decisión final del IETF, un certificado de producto ni el parte de un incidente.

Una referencia sustituye a la lista copiada

La revisión 04 enumeraba las clases A, H y K, algunos puntos de F y los signos de la dirección. La 05 formula el control de otro modo: solo admite puntos de código válidos según IdentifierClass y obliga a satisfacer la regla contextual cuando la clasificación la requiere.

La diferencia importa porque PRECIS no devuelve únicamente sí o no. El RFC 8264 define cuatro disposiciones: válido, requiere contexto, no permitido y sin asignar. Un join control puede necesitar inspeccionar sus vecinos. Un programa que se limita a preguntar por la categoría general de Unicode no ha ejecutado el control completo.

IdentifierClass fue diseñado para cadenas que identifican o direccionan entidades de red y prioriza seguridad sobre expresividad. Admite letras, números y ASCII imprimible dentro de sus reglas; rechaza, entre otros, jamo coreano antiguo, controles, propiedades ignorables, espacios, formas de compatibilidad y varias clases inadecuadas para identificadores.

El marco deja trabajo al perfil de la aplicación: mapeo de anchura, mapeos adicionales, mayúsculas, normalización y dirección. Por eso, apuntar a PRECIS no elimina el gobierno local. Obliga a separar la base compartida de las decisiones que cada servicio añade.

El caso de TATWEEL rompe el atajo de «es una letra»

El RFC 5892 coloca U+0640 en su tabla explícita de excepciones con resultado DISALLOWED. Sin esa excepción, el cálculo general por propiedades habría dado PVALID. Una etiqueta «Letter» en un informe de depuración es cierta, pero insuficiente para justificar la admisión.

Los ensayos públicos de los autores extienden la muestra a controles bidireccionales, letras de ancho completo y jamo combinable, y contrastan este último con una sílaba coreana precompuesta. El corpus ayuda a repetir una implementación; no prueba que formularios, APIs, directorios, recuperación y transporte usen la misma compilación.

El tercer requisito del borrador impide más de una escritura no ASCII en una dirección, ignorando ASCII al contar. La Unicode Standard Annex #24 define la propiedad Script usada en esa operación. Es una restricción propuesta para interoperabilidad, no una declaración sobre la identidad de una persona multilingüe.

La frase del espacio no debe corregirse en secreto

La versión actual deja una costura textual. Su regla 2 menciona literalmente los puntos válidos de IdentifierClass y un espacio entre comillas. Los ejemplos inmediatos se refieren además al punto, la barra y la arroba. La fuente pública conserva la misma frase.

Puede ser una errata, una dependencia implícita de la producción mailbox o texto pendiente de revisión. Las fuentes no permiten elegir. Dado que la puntuación separa partes con funciones distintas, una regla de repertorio no sustituye a la gramática.

Hasta que haya aclaración, cada implementación debe identificar qué versión y qué lectura ejecuta. Hacer una corrección silenciosa puede producir software razonable, pero no produce consenso ni una prueba portable de conformidad.

Sintaxis, posesión y entrega son afirmaciones distintas

El RFC 6532 habilita UTF-8 directo en cabeceras y direcciones del correo internacionalizado. El borrador actual busca restringir el conjunto a formas más interoperables. Ninguno autentica al titular.

Una cadena permitida puede apuntar a un buzón inexistente. Un desafío respondido puede demostrar control momentáneo, no identidad jurídica. Un servicio puede admitir el valor y dañarlo al exportarlo. Una primera conexión compatible con SMTPUTF8 no certifica todos los saltos. Quien pega un signo prohibido tampoco es necesariamente malicioso: puede no saber que estaba allí.

La historia anterior de BTW sobre SMTPUTF8 estudia la custodia del local-part internacionalizado a lo largo de la ruta y la ausencia de una degradación genérica. Este artículo cubre un objeto anterior y distinto: el predicado que deja entrar la cadena.

Conservar la explicación de la decisión

Un recibo de admisión debería unir los bytes UTF-8 con la secuencia de puntos de código, su posición en la gramática y la disposición IdentifierClass de cada signo no ASCII. Para los casos contextuales, anotaría la regla, los vecinos examinados y el resultado. Añadiría el cálculo de escritura y las políticas de mapeo, caso, normalización y bidi.

El registro debe nombrar la versión de datos Unicode/PRECIS, la compilación del validador, la superficie que llamó, la hora, la acción y el mecanismo de corrección. En la consola, una forma escapada puede acompañar a la forma legible; el original completo debe quedar protegido.

Es una propuesta editorial de Daniel Kade, no texto normativo del IETF. El recibo no impone una sola política de cuentas. Hace comparable el razonamiento de registro, inicio de sesión, recuperación y pasarela, sin convertir la apariencia en autoridad.

Fuentes