Análisis profundo de las direcciones de correo electrónico

 (lasans.blog)
4 puntos por GN⁺ 2 시간 전 | Aún no hay comentarios. | Compartir por WhatsApp
  • Una dirección de correo electrónico no es solo una combinación simple de nombre de usuario y dominio, sino un sistema que incluye estructuras y reglas complejas definidas en los estándares RFC, además de trampas de seguridad
  • En la parte local (antes de @) existen diversos formatos válidos poco conocidos, como comillas, comentarios y Unicode, aunque la mayoría no se soporta en entornos reales
  • Todo correo electrónico tiene dos direcciones de remitente: el Envelope Sender y el encabezado From, y esta diferencia es la causa fundamental del spoofing y el phishing
  • El comportamiento propio de cada proveedor, como la política de Gmail de ignorar puntos (dot), el direccionamiento con plus y los alias de dominio, afecta directamente la seguridad y la validación
  • Al construir sistemas para recopilar o validar direcciones de correo electrónico, es imprescindible entender con precisión la brecha entre los estándares RFC y el comportamiento real

Estructura básica

  • Una dirección de correo electrónico se compone de tres partes: la parte local (antes de @), el separador @ y el dominio (después de @)
  • Aunque parece simple a primera vista, cada parte tiene reglas y casos límite que afectan la seguridad, la privacidad y la validación

Parte local (Local Part)

  • Caracteres permitidos

    • Caracteres permitidos en el formato estándar sin comillas (dot-atom): letras a-z, A-Z, números 0-9, caracteres especiales . _ - + ! # $ % & ' * / = ? ^ { | } ~
    • La longitud máxima es de 64 octetos (octet); en ASCII estándar equivale a 64 caracteres, pero en partes locales con Unicode puede haber diferencias
      • Un octeto significa exactamente un grupo de 8 bits y se usa en redes (IPv4) para representar valores de 0 a 255
      • 64 octetos equivalen a un bloque de datos de 512 bits

  • Distinción entre mayúsculas y minúsculas

    • Según RFC 5321, la parte local técnicamente distingue entre mayúsculas y minúsculas, y User@example.com y user@example.com pueden ser buzones distintos
    • En la práctica, todos los principales proveedores de correo no distinguen mayúsculas de minúsculas, así que normalizar a minúsculas antes de guardar o comparar es el valor predeterminado más seguro
    • La parte del dominio nunca distingue entre mayúsculas y minúsculas

  • Direccionamiento con punto (Dot)

    • El punto está permitido en la parte local, pero tiene tres restricciones: no puede ir al inicio, no puede ir al final y no se permiten puntos consecutivos
    • Normalización de puntos en Gmail: Gmail ignora por completo los puntos en la parte local, por lo que johndoe@gmail.com, john.doe@gmail.com y j.o.h.n.d.o.e@gmail.com llegan al mismo buzón
      • Es un comportamiento propio de Gmail, no del estándar RFC
      • Es un vector de ataque real que un atacante puede aprovechar al crear direcciones variantes con puntos para evadir límites de una sola cuenta u obtener pruebas gratuitas duplicadas

  • Subaddressing (direccionamiento con plus)

    • Se pueden añadir etiquetas a la parte local usando un delimitador, y el servidor de correo entrega el mensaje a la dirección base conservando la etiqueta (RFC 5233)
    • El delimitador más común es +, y lo soportan Gmail, Outlook, ProtonMail y Fastmail, entre otros
      • En algunas configuraciones de Yahoo y ciertos ajustes de Postfix se usa -
      • En qmail, = es el delimitador predeterminado, y por eso en VERP se codifica @ como =
    • Casos de uso más comunes:
      • Rastreo de filtraciones: registrarse con una etiqueta única por servicio (por ejemplo, tunombre+servicio@gmail.com) para identificar el origen de una fuga si luego llega spam
      • Filtrado de bandeja de entrada: clasificar automáticamente mensajes dirigidos a una dirección con una etiqueta específica mediante reglas de correo
      • Múltiples cuentas: en servicios que no normalizan el plus, se pueden crear cuentas separadas con un solo correo
    • Muchos validadores de correo de sitios web rechazan +, pero eso es un bug del código de validación, no una limitación del correo electrónico

  • Formato de cadena entre comillas (Quoted String Form)

    • Si la parte local se encierra entre comillas dobles, se flexibilizan la mayoría de las restricciones de caracteres y se permiten espacios, @, puntos consecutivos y puntos al inicio o al final
    • Ejemplos: "john doe"@example.com, "user@name"@example.com, " "@example.com
    • En la práctica, casi ningún proveedor de correo acepta partes locales entre comillas, así que aunque es válido según RFC, no sirve en entornos reales

  • Comentarios (Comments)

    • Pueden aparecer comentarios entre paréntesis al inicio o al final de la parte local, y el servidor de correo los elimina sin afectar la entrega
    • Es técnicamente válido según RFC 5322, pero ya no se usa en la actualidad
    • Un validador que rechaza paréntesis es más estricto que la RFC

  • Parte local con Unicode (EAI)

    • La internacionalización de direcciones de correo electrónico (EAI), definida en RFC 6530, 6531 y 6532, permite caracteres UTF-8 en la parte local
    • Requiere usar la extensión SMTPUTF8 en la sesión SMTP, y tanto el servidor emisor como el receptor deben soportarla
    • A partir de 2026, la adopción sigue siendo limitada, y como los caracteres Unicode usan de 2 a 4 octetos, se puede alcanzar el límite de 64 octetos con menos caracteres visibles

  • Formatos históricos

    • Bang path (UUCP): método de enrutamiento usado antes del DNS en redes de máquinas Unix conectadas por módem, con rutas de host separadas por ! (machine1!machine2!user); por eso ! aparece en la lista de caracteres permitidos. Hoy está completamente en desuso
    • Percent hack: truco de enrutamiento por relay con formato user%otherdomain@relay.com; el carácter % sigue siendo válido en la parte local aunque ese mecanismo de enrutamiento fue retirado en RFC 5321
    • Source routing: lista explícita de saltos de relay en el comando SMTP RCPT TO (@relay1,@relay2:user@domain). Retirado en RFC 5321

  • VERP (Variable Envelope Return Path)

    • Técnica usada en sistemas de correo masivo para rastrear al destinatario exacto que provocó un rebote
    • Codifica la dirección del destinatario en el remitente del sobre (MAIL FROM), reemplazando @ del destinatario por =
      • Ejemplo: bounces+alice=gmail.com@newsletter.com
    • Mailchimp, SendGrid y Amazon SES, entre otros, usan VERP o variantes para procesar rebotes a gran escala

  • SRS (Sender Rewriting Scheme)

    • Formato de dirección que aparece cuando un servidor reenvía un correo y reescribe el remitente del sobre para hacer pasar la verificación SPF
    • Tiene la forma SRS0=HASH=TT=originaldomain.com=originaluser@forwardingdomain.com
    • En reenvíos con múltiples saltos, toma la forma SRS1=HASH=encodedSRS0@forwardingdomain.com
    • Es una dirección de correo estructuralmente válida, pero es un artefacto de infraestructura, no una dirección usada por personas
    • El componente HASH es un HMAC sobre la marca de tiempo y la dirección original, y sirve para prevenir falsificaciones y limitar la vigencia del token

Parte del dominio (Domain Part)

  • Reglas de las etiquetas

    • Un dominio está compuesto por etiquetas separadas por puntos, y en cada etiqueta se permiten letras a-z, números 0-9 y guion -
    • No puede comenzar ni terminar con un guion, y no se permiten guiones consecutivos en la 3.ª y 4.ª posición (excepto las etiquetas Punycode que comienzan con xn--)
    • Máximo 63 caracteres por etiqueta, máximo 253 caracteres para el dominio completo y máximo 254 caracteres para la dirección de correo completa (addr-spec)

  • Subdominios

    • Un dominio puede tener varios niveles y, aparte del límite total de 253 caracteres, no existe un límite estricto para la profundidad de subdominios
    • Usos comunes: infraestructura de correo (mail., smtp., mx.), separación organizacional (sales.company.com), envíos de ESP (email.company.com)

  • Literales de dirección IP

    • En lugar de un nombre de dominio, se puede usar una dirección IP entre corchetes: user@[192.168.1.1], user@[IPv6:2001:db8::1]
    • Es válido según RFC 5321, pero casi nunca se acepta en servidores de correo públicos, y se usa para sistemas de correo internos y pruebas de SMTP

  • Dominios de una sola etiqueta

    • Un dominio sin puntos (por ejemplo, user@localhost) es técnicamente válido en algunos contextos, pero los servidores de correo públicos lo rechazan
    • postmaster@localhost es un caso especial convencional del correo local del sistema en sistemas tipo Unix

  • Nombres de dominio internacionalizados (IDN) y Punycode

    • Como DNS solo admite ASCII, los caracteres no ASCII se codifican en Punycode (RFC 3492), y todas las etiquetas codificadas comienzan con el prefijo xn--
    • Los clientes de correo los muestran en escritura nativa y SMTP los envía en formato Punycode
    • Ataque de homógrafos: se pueden registrar dominios parecidos a dominios conocidos usando caracteres visualmente idénticos de otros alfabetos Unicode. Los navegadores tienen defensas que muestran Punycode para IDN sospechosos, pero la mayoría de los clientes de correo no tienen esas defensas, por lo que el ataque es más efectivo en el correo electrónico

  • Punto final (Trailing Dot)

    • En DNS, técnicamente todos los dominios terminan con un punto final que representa la zona raíz, pero en correo electrónico siempre está implícito y se omite
    • La mayoría de los validadores rechazan formas como user@example.com.

  • Registros MX

    • El dominio de una dirección de correo no tiene que ser necesariamente donde está el servidor de correo; el servidor emisor consulta los registros DNS MX (Mail Exchanger) para identificar el nombre real del host del servidor de correo
    • Un número de prioridad más bajo significa mayor prioridad, y si no hay ningún registro MX, se hace fallback al registro A del dominio
    • Si un dominio nunca debe recibir correo electrónico, se puede publicar un registro null MX (MX 0 .) para indicar explícitamente a los servidores emisores que no intenten hacer la entrega (RFC 7505)

Dominio de nivel superior (TLD)

  • TLD generales originales

    • Los 7 gTLD del internet inicial: .com (comercial, hoy sin restricciones, operado por Verisign), .net (redes, sin restricciones), .org (organizaciones, sin restricciones), .edu (instituciones educativas acreditadas de EE. UU., restringido), .gov (gobierno de EE. UU., restringido), .mil (fuerzas armadas de EE. UU., restringido), .int (organizaciones internacionales basadas en tratados, muy restringido)
    • .arpa es un TLD de infraestructura administrado por IANA, usado en búsquedas DNS inversas

  • TLD de código de país (ccTLD)

    • Códigos de 2 letras basados en los códigos de país ISO 3166-1 alpha-2; existen unos 250
    • Algunos ccTLD fueron reutilizados por otras industrias:
      • .io (Territorio Británico del Océano Índico → empresas tecnológicas), .tv (Tuvalu → medios y streaming), .ai (Anguila → empresas de IA), .co (Colombia → alternativa a .com), .me (Montenegro → sitios personales), .ly (Libia → acortadores de URL), .sh (Santa Elena → proyectos de software)
    • Usar un ccTLD reutilizado significa que, técnicamente, queda bajo la jurisdicción del registro de ese país, y el dominio es controlado por el registro del país original, no por ICANN

  • TLD patrocinados (sTLD)

    • TLD con una organización patrocinadora y requisitos de elegibilidad: .aero (transporte aéreo, patrocinado por SITA), .coop (cooperativas), .museum (museos), .jobs (empleo), .xxx (adultos), .post (correo postal), .cat (lengua y cultura catalanas)

  • Nuevos TLD generales (desde 2012)

    • En 2012, ICANN abrió la postulación para nuevos gTLD y se delegaron más de 1,200 TLD nuevos
    • Impacto importante en la validación de correo: los validadores que limitan la longitud del TLD a 4~6 caracteres se rompen (.photography, .international, .construction, etc.)
    • Relacionados con desarrolladores: .app, .dev, .web, .code / comerciales: .shop, .store, .online / contenido: .blog, .news, .media / negocios: .tech, .agency, .cloud
    • Los nuevos gTLD están sobrerrepresentados en spam y phishing debido a sus bajos costos de registro y a las políticas débiles contra abusos de algunos registros

  • TLD de marca

    • En la expansión de ICANN de 2012, grandes empresas solicitaron sus propios TLD: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
    • La mayoría no se usa para direcciones de correo públicas; suelen ser para uso interno o directamente no se usan

  • TLD geográficos y de ciudades

    • TLD propios de ciudades y regiones: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
    • Al registrarlos, normalmente se requiere demostrar vínculo con esa región

  • TLD internacionalizados

    • Muchos países tienen TLD en escrituras no ASCII, codificados en DNS como Punycode
      • .xn--p1ai (Rusia, cirílico), .xn--fiqz9s (China, caracteres simplificados), .xn--mgberp4a5d4ar (Arabia Saudita, escritura árabe), .xn--h2brj9c (India, escritura devanagari)

  • TLD reservados y de documentación

    • TLD reservados por RFC 2606 y RFC 6761 para pruebas y documentación:
      • .test (nunca existe en el DNS público, seguro para pruebas de software), .example (para ejemplos en documentación), .invalid (cuando se necesita un dominio que con certeza no se resuelva), .localhost (para loopback)
    • IANA registró example.com, example.net y example.org para documentación y ejemplos, por lo que pueden usarse libremente en ejemplos de código sin preocuparse de llegar a un buzón real

  • TLD retirados

    • ccTLD eliminados por desaparición de países: .yu (Yugoslavia, eliminado en 2010), .cs (Checoslovaquia, eliminado en 1995), .dd (Alemania Oriental, eliminado en 1990), .tp (Timor Oriental, reemplazado por .tl y eliminado por completo en 2015)
    • Excepción: .su (Unión Soviética) sigue teniendo dominios activos pese a la disolución de 1991, y aunque IANA ha discutido durante años su transición, continúa activo

Dominios de segundo nivel en ccTLD

  • Muchos ccTLD agregan categorías funcionales de segundo nivel entre el nombre registrable y el TLD
    • Reino Unido: .co.uk, .org.uk, .gov.uk / Australia: .com.au, .edu.au / Japón: .co.jp, .ac.jp / India: .co.in, .gov.in / Brasil: .com.br, .gov.br
  • Cuando un sistema de verificación de correo electrónico necesita encontrar el dominio organizacional, esto afecta la validación y la detección del dominio organizacional

  • Public Suffix List (PSL)

    • Lista mantenida por la comunidad en publicsuffix.org que recoge todos los sufijos de dominio donde los usuarios de Internet pueden registrar nombres directamente
    • Incluye tanto delegaciones oficiales (.co.uk, .com.au) como registros privados (github.io, wordpress.com, herokuapp.com)
    • Usa notación con comodines (por ejemplo, *.ck), y las excepciones se marcan con ! (por ejemplo, !www.ck)
    • Los validadores de correo y filtros antispam la usan para identificar el dominio organizacional dentro de la cadena completa del dominio
    • No es un estándar del IETF, pero sí el estándar de facto para este problema

Formatos de direcciones de correo electrónico

  • Dirección básica (Bare Address)

    • Forma addr-spec de local@domain, usada en comandos SMTP y contextos simples

  • Formato con corchetes angulares

    • En SMTP, los comandos MAIL FROM y RCPT TO envuelven la dirección entre corchetes angulares: MAIL FROM:<sender@example.com>
    • Los corchetes angulares son parte de la sintaxis del comando SMTP, no de la dirección en sí

  • Formato de nombre para mostrar (Display Name Format)

    • En los encabezados del mensaje (From, To, Cc), puede ir un nombre legible por personas antes de la dirección entre corchetes angulares: "John Doe" <john@example.com>
    • Si el nombre para mostrar incluye caracteres especiales, las comillas son obligatorias
    • Suplantación del nombre para mostrar: el remitente puede configurar el nombre para mostrar como quiera, lo que permite ataques como "PayPal Security <paypal@paypal.com>" <attacker@evil.com>
      • Como muchos clientes de correo muestran solo el nombre para mostrar en la lista de entrada, esta es una de las técnicas de phishing más comunes

  • Sintaxis de grupo (Group Syntax)

    • Formato de grupo con nombre para múltiples destinatarios definido en RFC 5322: Marketing Team: alice@example.com, "Bob Smith" <bob@example.com>;
    • Patrón de destinatarios ocultos: To: undisclosed-recipients:; — sintaxis de grupo vacía, donde los destinatarios reales están en el sobre SMTP (RCPT TO) y no se ven en los encabezados del mensaje

  • Nombres para mostrar codificados

    • En sistemas de correo antiguos, los caracteres no ASCII del nombre para mostrar se manejaban con palabras codificadas RFC 2047: =?charset?encoding?encoded_text?=
    • La codificación es B (base64) o Q (quoted-printable)
    • Con soporte moderno de SMTPUTF8, se puede usar UTF-8 directamente en los encabezados sin este envoltorio de codificación

Los dos remitentes de todo correo electrónico

  • Remitente del sobre (Envelope Sender / MAIL FROM)

    • Se establece en el comando SMTP MAIL FROM: y no forma parte del contenido del mensaje en sí
    • Se usa para el enrutamiento de rebotes, es lo que se valida en las comprobaciones SPF, y el servidor receptor final lo guarda en el encabezado Return-Path:
    • También se le llama envelope from, reverse path o RFC5321.MailFrom

  • Encabezado From

    • Es la dirección en el encabezado From: del mensaje, la que el cliente de correo muestra como remitente
    • Es lo que protege DMARC junto con la alineación SPF o DKIM
    • El remitente puede configurarlo libremente y, en la mayoría de los servidores de correo, no tiene verificación propia
    • Estas dos direcciones pueden ser completamente distintas, y eso es un escenario normal y esperado:
      • En envíos masivos por un ESP, MAIL FROM puede ser bounce@esp.com y el encabezado From puede ser newsletter@yourbrand.com
      • En una lista de correo, MAIL FROM puede ser la dirección de rebotes de la lista y el encabezado From el autor original
      • En el reenvío de correo, el servidor de reenvío puede reescribir MAIL FROM con SRS mientras conserva en el encabezado From al remitente original
    • Si el dominio no tiene DMARC aplicado, cualquiera puede enviar poniendo ese dominio en el encabezado From mientras usa un MAIL FROM totalmente no relacionado

  • Encabezado Sender

    • Identifica al remitente real cuando quien envía el mensaje es distinto de la dirección From: Sender: mailer@sendgrid.net

  • Encabezado Reply-To

    • Especifica a dónde deben ir las respuestas y puede ser distinto de la dirección From
    • También puede abusarse como vector de phishing: el atacante hace que From parezca legítimo y pone su propia dirección en Reply-To

  • Remitente nulo

    • MAIL FROM:<> es una estructura SMTP válida e importante; el remitente vacío del sobre se usa para mensajes de rebote, respuestas automáticas y mensajes que no deben generar rebotes por sí mismos
    • Evita bucles infinitos de rebotes donde dos sistemas siguen intercambiando notificaciones de fallo

Direcciones basadas en roles (Role-Based Addresses)

  • Requisito de RFC 5321

    • postmaster@domain: según RFC 5321, todos los dominios que aceptan correo deben aceptar mensajes para esta dirección, sin excepciones

  • Recomendadas por RFC 2142

    • abuse@domain (reportes de spam y abuso), hostmaster@domain (gestión de zonas DNS), security@domain (divulgación de vulnerabilidades y reportes de seguridad), webmaster@domain (problemas del servidor web), noc@domain (operaciones de red)

  • Direcciones de rol por convención

    • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@, etc.; no son un estándar oficial, pero se usan ampliamente
    • Las direcciones de rol normalmente las comparten varias personas, así que al enviar información sensible, varios miembros del equipo podrían verla
    • abuse@ y postmaster@ reciben correos de queja, por lo que son objetivos de ingeniería social

  • Direcciones catch-all (Catch-All Addresses)

    • No son un formato específico de dirección de correo, sino una configuración del servidor de correo que acepta la entrega incluso para partes locales que no tienen un buzón específico
    • Casos de uso: capturar errores tipográficos, pruebas de desarrolladores, crear direcciones únicas por servicio sin un sistema formal de alias
    • Desventaja: como cualquier parte local se entrega, esto provoca grandes volúmenes de spam, y hace imposible validar direcciones mediante sondeo SMTP (todas las pruebas devuelven respuesta exitosa)

Comportamientos únicos según el proveedor

  • Gmail

    • Normalización de puntos: ignora todos los puntos en la parte local
    • Direccionamiento con plus: admite el delimitador +
    • @googlemail.com: alias histórico de @gmail.com debido a una disputa de marca registrada en Alemania y el Reino Unido; ambos dominios entregan al mismo buzón
    • Restricción de caracteres: en la parte local solo permite letras inglesas, números y puntos (incluido + para direccionamiento con plus). No admite el conjunto completo de caracteres de RFC
    • Límite de longitud de la parte local: 30 caracteres, muy por debajo del máximo de 64 caracteres de RFC

  • Microsoft (Outlook, Hotmail, Live)

    • Sin normalización de puntos: johndoe@outlook.com y john.doe@outlook.com son buzones distintos
    • Alias de dominio: @hotmail.com, @live.com y @outlook.com pueden apuntar a la misma cuenta al configurarse como alias
    • Admite direccionamiento con plus

  • Apple (iCloud)

    • Alias de dominio: @icloud.com, @me.com y @mac.com llegan al mismo buzón (historial de cambios de nombre del servicio de .mac → .me → .icloud)
    • Admite direccionamiento con plus
    • Hide My Email: genera alias aleatorios con formato randomstring@privaterelay.appleid.com, manteniendo privada la dirección real mediante un alias único por servicio o app

  • ProtonMail / Proton

    • Alias de dominio: @proton.me, @protonmail.com y @pm.me llegan al mismo buzón
    • Admite direccionamiento con plus

  • Servicios de alias de correo electrónico

    • A diferencia del correo desechable, son servicios que crean direcciones de reenvío permanentes y controlables:
      • SimpleLogin (de Proton): reenvía a cualquier buzón usando alias personalizados o aleatorios
      • Addy.io (antes AnonAddy): similar a SimpleLogin, con opción de self-hosting
      • Firefox Relay (Mozilla): alias aleatorios limitados en el plan gratuito
      • DuckDuckGo Email Protection: alias @duck.com
    • Generan direcciones estructuralmente indistinguibles de un buzón real para quien envía
    • Diferencia clave frente al correo desechable: los alias son permanentes y controlables; se puede desactivar un alias específico, verificar qué servicio envió a cada alias y reenviar al buzón que se desee

Correos desechables o temporales

  • Proporcionan buzones que no requieren registro y que por lo general expiran tras un periodo corto; ejemplos representativos son Mailinator, Guerrilla Mail, 10 Minute Mail y TempMail
  • La mayoría usa enrutamiento catch-all, por lo que cualquier parte local de ese dominio se entrega a un buzón
  • Muchos buzones son públicos, así que cualquiera que conozca la dirección puede ver los mensajes
  • Existen listas de bloqueo de dominios desechables conocidos (la referencia más usada es el repositorio de GitHub disposable-email-domains), pero siempre son incompletas y se renuevan constantemente con dominios nuevos para evadir el bloqueo

Validación

  • Validez técnica vs. validez práctica

    • Válidos según RFC pero casi nunca aceptados por servidores reales: espacios entre comillas (" "@example.com), @ entre comillas ("user@name"@example.com), dominios con IP literal (user@[192.168.1.1]), carácter único / etiqueta única (a@b)
    • Válidos según RFC y aceptados en la práctica: user+tag@example.com, user_name@example.com, user@subdomain.example.co.uk, user@example.photography
    • En la mayoría de las aplicaciones, un validador práctico es mejor que un validador de cumplimiento RFC completo: verificar estructura básica, validar un conjunto razonable de caracteres y, opcionalmente, consultar el DNS MX del dominio

  • Errores comunes en validadores

    • Rechazar + en la parte local: user+tag@example.com es totalmente válido y este es un error muy común
    • Rechazar _ en la parte local: también es válido
    • Rechazar % en la parte local: es un carácter válido; lo obsoleto es solo el uso de enrutamiento percent-hack
    • Limitar la longitud del TLD a 4~6 caracteres: bloquea cientos de nuevos gTLD como .photography, .international y .construction
    • Validar con una lista de TLD codificada a mano: como la lista cambia constantemente, el validador se vuelve obsoleto
    • Límite total de longitud incorrecto: usar 255 o 256 en lugar de 254. La fe de erratas número 1690 de RFC 3696 corrigió a 254 el valor incorrecto 320, que se citaba ampliamente
    • Rechazar mayúsculas en la parte local: son válidas según RFC
    • Rechazar user@subdomain.co.uk: es válido; los dominios con múltiples puntos en patrones ccTLD de segundo nivel son normales
    • Rechazar .dev, .app, .io como TLD: todos son TLD delegados válidos

  • Límites de longitud

    Parte Límite
    Parte local 64 octetos
    Etiqueta de dominio 63 octetos
    Dominio completo 253 octetos
    Dirección completa (addr-spec) 254 octetos

  • El límite de la parte local se mide en octetos, no en caracteres, por lo que una dirección EAI con caracteres Unicode multibyte puede verse de menos de 64 caracteres y aun así alcanzar el límite en octetos

  • Validación basada en DNS

    • Comprobación de registros MX: valida si el dominio tiene registros MX; es rápida y de bajo riesgo. Los dominios que usan fallback a registros A (sin MX configurado) pueden fallar esta prueba
    • Comprobación de Null MX: si el dominio tiene MX 0 ., entonces explícitamente no recibe correo
    • Sondeo SMTP RCPT TO: conecta al servidor de correo y emite el comando RCPT TO para comprobar si la dirección es aceptada, pero muchos servidores responden 250 para todas las direcciones para evitar la recolección de direcciones, por lo que no es confiable. Los dominios catch-all siempre responden positivamente. También existe el riesgo de que la IP de sondeo termine en una blacklist
    • La única forma de validar una dirección de correo con total confiabilidad es enviar un mensaje real y comprobar que llegue; todo lo demás son heurísticas

Implicaciones de seguridad

  • Suplantación del nombre para mostrar

    • Cualquiera puede configurar el nombre para mostrar de un correo como quiera, y en las vistas de buzón que muestran solo ese nombre, el usuario no puede distinguir una suplantación de un remitente legítimo a menos que verifique explícitamente la dirección real

  • Ataques homográficos mediante Punycode

    • Es posible registrar dominios visualmente idénticos a dominios reales y conocidos usando caracteres de otros alfabetos Unicode
    • A diferencia de los navegadores, los clientes de correo por lo general no muestran advertencias sobre esto

  • El truco de los puntos en Gmail para evadir restricciones de cuenta

    • Como Gmail ignora los puntos, un atacante puede registrarse en un servicio usando una variante con puntos de una dirección existente de Gmail para evadir límites de una sola cuenta, obtener pruebas gratuitas duplicadas o recibir correos destinados al dueño de la cuenta original

  • Reutilización de direcciones de correo

    • Un proveedor de correo puede reasignar direcciones abandonadas a usuarios nuevos, y el nuevo titular podría recibir correos de recuperación de cuenta de servicios donde el propietario anterior estaba registrado, lo que permitiría tomar la cuenta mediante restablecimiento de contraseña
    • Gmail ha afirmado que no reasigna direcciones, pero algunos otros proveedores sí lo han hecho históricamente

  • Exposición de etiquetas de subdireccionamiento

    • Si te registras con user+newsletter@gmail.com, el servicio receptor puede ver la dirección completa, incluida la etiqueta
    • Un servicio que elimina y guarda sin la etiqueta plus expone la dirección base; uno que guarda la dirección completa tal cual puede revelar tu estrategia de rastreo en la configuración de la cuenta o en una exportación de datos

Lecturas relacionadas

Aún no hay comentarios.

Aún no hay comentarios.