Resumen

  • Un Internet-Draft individual del 27 de octubre estudia nombres parecidos a los del soporte o los reclutadores en buzones internos de plataformas. Es una propuesta informativa de ingeniería, sin protocolo nuevo.
  • El texto identifica dos trampas concretas: la igualdad exacta de esqueletos Unicode puede pasar por alto imitaciones visibles y algunos validadores examinados habrían aceptado hosts conservando caracteres invisibles. Propone combinar identidad del remitente, destino del enlace e intención del mensaje.

Un usuario abre la bandeja de una plataforma de empleo. El nombre que encabeza una conversación dice «Soporte», pero esa palabra puede escribirla una cuenta ajena al equipo oficial. El nuevo borrador sobre remitentes parecidos desplaza la pregunta al mensaje individual: ¿de qué cuenta salió, qué dominio muestra, a qué host lleva el enlace y qué pide? En una conversación dentro de la aplicación, la pasarela de correo empresarial del destinatario no está entre las dos cuentas. La plataforma sí controla el buzón y sus nombres autorizados.

El documento agrupa señales en tres familias. Examinar el dominio del remitente y los hosts enlazados frente a las identidades protegidas; mirar si un nombre de marca acompaña una dirección ajena; y observar si el mensaje pide credenciales, saca a la persona de la plataforma o invoca una autoridad que no tiene. El cruce importa. Un departamento universitario de orientación puede usar palabras parecidas a las de un reclutador sin estar suplantando a nadie. Una regla que castiga solo la semejanza confunde precaución con censura automática.

La primera grieta es de caracteres. UTS n.º 39 define un «esqueleto» para comparar cadenas confundibles y describe la detección de escrituras mezcladas. El borrador muestra por qué exigir igualdad exacta entre esqueletos resulta corto: algunos caracteres visualmente próximos se proyectan sobre prototipos latinos que no son ASCII. Sus ejemplos son la kappa minúscula griega y la te minúscula cirílica. Comparar únicamente el esqueleto de un remitente con el de una marca ASCII deja fuera esa clase de imitaciones. El texto propone sumar detección de escrituras y distancia acotada entre esqueletos.

La segunda grieta no ocupa ancho visible. El autor informa de varios validadores que aceptaron hosts con caracteres de formato como U+00AD, U+200B, U+2060 y U+FEFF y los devolvieron sin quitarlos. RFC 5890 establece el marco IDNA, RFC 5892 las reglas de puntos de código y UTS n.º 46 el tratamiento de compatibilidad. El borrador pide procesar el host según IDNA2008 o UTS-46 antes de compararlo con una lista de confianza y rechazar etiquetas con caracteres de formato o ignorables por defecto. Un sello de «válido» sobre una cadena que conserva lo invisible transfiere el problema al siguiente componente.

El registro de dominios no conoce por sí solo qué cuenta de una bolsa de empleo tiene permiso para hablar como su soporte. Eso lo sabe el operador de la plataforma: conserva la lista de identidades propias, la relación entre cuentas y cargos, y el botón que advierte o bloquea. El borrador también contempla modelos de lenguaje, con una condición: el texto del mensaje es entrada no confiable y su veredicto no debe desplazar la evidencia determinista sobre el remitente. Datatracker mantiene el documento como borrador individual I-D Exists con destino Informational.

Faltan los nombres y versiones de los validadores estudiados, junto con una matriz reproducible de entradas y salidas. Publicarla permitiría medir qué parte de este hallazgo sigue vigente.