Saltar al contenido

¿Qué caracteres se permiten en una dirección de correo electrónico?

Luego de de esta prolongada selección de información pudimos solucionar este rompecabezas que presentan algunos los lectores. Te compartimos la respuesta y nuestro deseo es servirte de gran apoyo.

Solución:

Consulte RFC 5322: Formato de mensaje de Internet y, en menor medida, RFC 5321: Protocolo simple de transferencia de correo.

RFC 822 también cubre las direcciones de correo electrónico, pero se ocupa principalmente de su estructura:

 addr-spec   =  local-part "@" domain        ; global address     
 local-part  =  word *("." word)             ; uninterpreted
                                             ; case-preserved

 domain      =  sub-domain *("." sub-domain)     
 sub-domain  =  domain-ref / domain-literal     
 domain-ref  =  atom                         ; symbolic reference

Y, como de costumbre, Wikipedia tiene un artículo decente sobre direcciones de correo electrónico:

La parte local de la dirección de correo electrónico puede utilizar cualquiera de estos caracteres ASCII:

  • letras latinas mayúsculas y minúsculas A para Z y a para z;
  • digitos 0 para 9;
  • caracteres especiales !#$%&'*+-/=?^_`~;
  • punto ., siempre que no sea el primer o el último carácter a menos que se cite, y siempre que no aparezca consecutivamente a menos que se cite (p. ej. [email protected] no está permitido pero "John..Doe"@example.com esta permitido);
  • espacio y "(),:;<>@[] se permiten caracteres con restricciones (solo se permiten dentro de una cadena entre comillas, como se describe en el párrafo siguiente, y además, una barra invertida o una comilla doble deben ir precedidas de una barra invertida);
  • los comentarios están permitidos entre paréntesis en cualquier extremo de la parte local; p.ej john.smith(comment)@example.com y (comment)[email protected] son ambos equivalentes a [email protected].

Además de los caracteres ASCII, a partir de 2012 puede utilizar caracteres internacionales arriba U+007F, codificado como UTF-8 como se describe en la especificación RFC 6532 y se explica en Wikipedia. Tenga en cuenta que a partir de 2019, estos estándares todavía están marcados como propuestos, pero se están implementando lentamente. Los cambios en esta especificación esencialmente agregaron caracteres internacionales como caracteres alfanuméricos válidos (texto) sin afectar las reglas sobre caracteres especiales permitidos y restringidos como !# y @:.

Para la validación, consulte Uso de una expresión regular para validar una dirección de correo electrónico.

los domain parte se define de la siguiente manera:

Los estándares de Internet (Solicitud de comentarios) para protocolos exigen que las etiquetas de nombre de host de los componentes solo contengan letras ASCII. a mediante z (de manera que no distingue entre mayúsculas y minúsculas), los dígitos 0 mediante 9y el guión (-). La especificación original de nombres de host en RFC 952, exigía que las etiquetas no pudieran comenzar con un dígito o con un guión, y no debían terminar con un guión. Sin embargo, una especificación posterior (RFC 1123) permitió que las etiquetas de nombre de host comenzaran con dígitos. No se permiten otros símbolos, caracteres de puntuación o espacios en blanco.

¡Cuidado! Hay un montón de conocimiento podrido en este hilo (cosas que solían ser ciertas y ahora no lo son).

Para evitar rechazos de falsos positivos de direcciones de correo electrónico reales en el mundo actual y futuro, y desde cualquier lugar del mundo, necesita conocer al menos el concepto de alto nivel de RFC 3490, “Internacionalización de nombres de dominio en aplicaciones (IDNA)”. Sé que la gente de EE. UU. Y A a menudo no está al tanto de esto, pero ya está en uso generalizado y en rápido aumento en todo el mundo (principalmente en las partes que no dominan el inglés).

La esencia es que ahora puede usar direcciones como [email protected]日本 .com y [email protected]ügen.net. No, esto todavía no es compatible con todo lo que existe (como muchos se han lamentado anteriormente, incluso las direcciones de identificación + estilo qmail simples a menudo se rechazan erróneamente). Pero hay una RFC, hay una especificación, ahora está respaldada por la IETF y la ICANN y, lo que es más importante, hay una gran y creciente cantidad de implementaciones que respaldan esta mejora que están actualmente en servicio.

Yo mismo no sabía mucho sobre este desarrollo hasta que regresé a Japón y comencé a ver direcciones de correo electrónico como [email protected]や る .ca y URL de Amazon como esta:

http://www.amazon.co.jp/ エ レ ク ト ロ ニ ク ス – デ ジ タ ル カ メ ラ – ポ ー タ ブ ル オ ー デ ィ オ / b / ref = topnav_storetab_e? ie = UTF8 & node = 3210981

Sé que no desea enlaces a especificaciones, pero si confía únicamente en el conocimiento obsoleto de los piratas informáticos en los foros de Internet, su validador de correo electrónico terminará rechazando las direcciones de correo electrónico que los usuarios que no hablan inglés esperan cada vez más que funcionen. Para esos usuarios, dicha validación será tan molesta como la forma común de muerte cerebral que todos odiamos, la que no puede manejar un + o un nombre de dominio de tres partes o lo que sea.

Así que no estoy diciendo que no sea una molestia, pero la lista completa de caracteres “permitidos bajo algunas / cualquiera / ninguna condición” es (casi) todos los caracteres en todos los idiomas. Si desea “aceptar todas las direcciones de correo electrónico válidas (y muchas no válidas también)”, debe tener en cuenta el IDN, lo que básicamente hace que un enfoque basado en caracteres sea inútil (lo siento), a menos que primero convierta las direcciones de correo electrónico internacionalizadas (muertas desde Septiembre de 2015, solía ser así (aquí hay una alternativa funcional) a Punycode.

Después de hacer eso, puede seguir (la mayoría de) los consejos anteriores.

El formato de la dirección de correo electrónico es: [email protected] (máx. [email protected] caracteres, no más de 256 en total).

los local-part y domain-part podría tener un conjunto diferente de caracteres permitidos, pero eso no es todo, ya que hay más reglas.

En general, la parte local puede tener estos caracteres ASCII:

  • letras latinas minúsculas: abcdefghijklmnopqrstuvwxyz,
  • letras latinas mayúsculas: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • dígitos: 0123456789,
  • caracteres especiales: !#$%&'*+-/=?^_`~,
  • punto: . (no es el primer ni el último carácter ni se repite a menos que se cite),
  • puntuaciones de espacio como: "(),:;<>@[] (con algunas restricciones),
  • comentarios: () (se permiten entre paréntesis, p. ej. (comment)[email protected]).

Parte del dominio:

  • letras latinas minúsculas: abcdefghijklmnopqrstuvwxyz,
  • letras latinas mayúsculas: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • dígitos: 0123456789,
  • guión: - (no es el primer ni el último carácter),
  • puede contener una dirección IP entre corchetes: [email protected][192.168.2.1] o [email protected][IPv6:2001:db8::1].

Estas direcciones de correo electrónico son válidas:

Y estos ejemplos de inválidos:

  • Abc.example.com (no @ personaje)
  • [email protected]@[email protected] (sólo uno @ está permitido fuera de las comillas)
  • a"b(c)d,e:f;gi[jk][email protected] (ninguno de los caracteres especiales en esta parte local está permitido fuera de las comillas)
  • just"not"[email protected] (las cadenas entre comillas deben estar separadas por puntos o ser el único elemento que forma la parte local)
  • this is"not[email protected] (los espacios, las comillas y las barras invertidas solo pueden existir cuando están dentro de cadenas entre comillas y están precedidas por una barra invertida)
  • this still"not[email protected] (incluso si se escapó (precedido por una barra invertida), los espacios, las comillas y las barras invertidas deben incluirse entre comillas)
  • [email protected] (punto doble antes @); (con advertencia: Gmail permite que esto pase)
  • [email protected] (punto doble después de @)
  • una dirección válida con un espacio inicial
  • una dirección válida con un espacio al final

Fuente: dirección de correo electrónico en Wikipedia


RFC2822 de Perl para validar correos electrónicos:

(?:(?:rn)?[ t])*(?:(?:(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t]
)+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:
rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(
?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ 
t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-
31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*
](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+
(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:
(?:rn)?[ t])*))*|(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z
|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)
?[ t])*)*<(?:(?:rn)?[ t])*(?:@(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:
rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[
 t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)
?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t]
)*))*(?:,@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[
 t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*
)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t]
)+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*)
*:(?:(?:rn)?[ t])*)?(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+
|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:r
n)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:
rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t
]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31
]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](
?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?
:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?
:rn)?[ t])*))*>(?:(?:rn)?[ t])*)|(?:[^()<>@,;:\".[] 00-31]+(?:(?
:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?
[ t]))*"(?:(?:rn)?[ t])*)*:(?:(?:rn)?[ t])*(?:(?:(?:[^()<>@,;:\".[] 
00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|
\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>
@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"
(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t]
)*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\
".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?
:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[
]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*|(?:[^()<>@,;:\".[] 00-
31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(
?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)*<(?:(?:rn)?[ t])*(?:@(?:[^()<>@,;
:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([
^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\"
.[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[
]r\]|\.)*](?:(?:rn)?[ t])*))*(?:,@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".
[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]
r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 
00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]
|\.)*](?:(?:rn)?[ t])*))*)*:(?:(?:rn)?[ t])*)?(?:[^()<>@,;:\".[] 
00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?:[^"r\]|\
.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[^()<>@,
;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]]))|"(?
:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*))*@(?:(?:rn)?[ t])*
(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".
[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t])*(?:[
^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[]
]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*>(?:(?:rn)?[ t])*)(?:,s*(
?:(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\
".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(
?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[
["()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t
])*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t
])+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?
:.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|
Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*|(?:
[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".[
]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)*<(?:(?:rn)
?[ t])*(?:@(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["
()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)
?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>
@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*(?:,@(?:(?:rn)?[
 t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,
;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:.(?:(?:rn)?[ t]
)*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\
".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*)*:(?:(?:rn)?[ t])*)?
(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[["()<>@,;:\".
[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])*)(?:.(?:(?:
rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z|(?=[[
"()<>@,;:\".[]]))|"(?:[^"r\]|\.|(?:(?:rn)?[ t]))*"(?:(?:rn)?[ t])
*))*@(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])
+|Z|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*)(?:
.(?:(?:rn)?[ t])*(?:[^()<>@,;:\".[] 00-31]+(?:(?:(?:rn)?[ t])+|Z
|(?=[["()<>@,;:\".[]]))|[([^[]r\]|\.)*](?:(?:rn)?[ t])*))*>(?:(
?:rn)?[ t])*))*)?;s*)

La expresión regular completa para las direcciones RFC2822 fue de tan solo 3.7k.

Consulte también: Analizador de direcciones de correo electrónico RFC 822 en PHP.


Las definiciones formales de direcciones de correo electrónico se encuentran en:

  • RFC 5322 (secciones 3.2.3 y 3.4.1, obsoleta RFC 2822), RFC 5321, RFC 3696,
  • RFC 6531 (caracteres permitidos).

Relacionado:

  • El verdadero poder de las expresiones regulares

valoraciones y comentarios

Agradecemos que desees añadir valor a nuestro contenido informacional tributando tu experiencia en las acotaciones.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *