Resumen

  • RFC 9873 permite que un contacto conserve el correo base y añada otro ASCII o SMTPUTF8, incluso señalado como principal, sin afirmar que ambos representen una identidad única.
  • El reenvío y la respuesta pueden cruzar las dos rutas; la negociación EPP, el almacenamiento, la entrega y la publicación pública requieren pruebas distintas.

La comunicación no siempre regresa por el camino de ida. RFC 9873 admite que un mensaje dirigido a una de las direcciones sea reenviado a la otra y que la contestación utilice otro correo o escritura. Así, el dato adicional es útil para continuidad lingüística y operativa. Pero una respuesta distinta tampoco demuestra, por sí sola, suplantación ni equivalencia personal.

El contacto sigue teniendo el campo de correo exigido por RFC 5733. La extensión aporta exactamente una dirección más, no una lista ilimitada. Su atributo opcional primary ordena el tratamiento del contacto extendido; no borra el dato base, no consulta la zona DNS y no abre una sesión con el buzón.

Antes de usarla hay una compuerta verificable. El saludo y el inicio de sesión de RFC 5730 permiten que servidor y cliente negocien el espacio de nombres. Si ambos lo aceptan, han de validar, guardar y devolver el correo adicional y soportar SMTPUTF8 al enviar o recibir. Si no lo negocian al comenzar la sesión, ninguno debe proporcionar la extensión. El resultado prueba una capacidad bilateral acotada.

También existe un estado nulo inequívoco. El elemento vacío elimina el valor en una actualización o comunica su ausencia en una consulta, y no puede llevar primary. Una dirección no vacía, en cambio, sigue sin probar MX operativo, buzón creado, reenvío correcto, entrega final, lectura, contestación o control humano. El servidor SMTP puede aceptar un mensaje que después rebota o nunca llega al destinatario previsto.

Los caracteres internacionales elevan el riesgo de comparación. RFC 6530 establece el marco y RFC 6531 amplía SMTP. RFC 9873 aconseja repertorios limitados, dominios conformes con IDNA2008 y ensayos de almacenamiento para secuencias combinadas. RFC 5895 trata el mapeo para interfaces, mientras las tablas IDNA de IANA registran el estado de los puntos de código. Superar esas validaciones no vuelve idénticas dos formas visualmente parecidas.

La privacidad une lo que el transporte separa. La regla de divulgación del correo base debe abarcar cualquier dirección adicional. En cambio, mostrar un mecanismo público es otra decisión. Las direcciones pueden procesarse en RDAP bajo el marco de STD 95, pero eso no obliga a reproducir todo dato EPP. El aviso de ICANN de 2026 ofrece contexto normativo para formularios o correos seudonimizados; no demuestra adopción de RFC 9873.

La doctrina de capas de realidad de Heng Lu permite leer la secuencia sin atajos: capacidad negociada, valor configurado, almacenamiento, decisión de divulgación, intento SMTP, aceptación de transporte, reenvío, acción del destinatario y proyección RDAP. Su especificación inicial mínima favorece el pequeño contrato común de la extensión, dejando explícitas las decisiones locales. La primacía del código operativo exige trazas reproducibles en cada salto.

El fallo de liderazgo sería convertir una flexibilidad lingüística en una certeza inexistente. Una etiqueta «principal», una aceptación SMTP o un formulario público responden preguntas diferentes. Ninguna es el recibo de la otra.

Fuentes