¿Qué caracteres están permitidos en una dirección de correo electrónico?


641

No estoy preguntando sobre la validación completa del correo electrónico.

Solo quiero saber qué caracteres están permitidos user-namey serverpartes de la dirección de correo electrónico. Esto puede estar demasiado simplificado, tal vez las direcciones de correo electrónico pueden tomar otras formas, pero no me importa. Solo pregunto sobre esta forma simple: user-name@server(por ejemplo, wild.wezyr@best-server-ever.com) y los caracteres permitidos en ambas partes.


185
El +está permitido. Me vuelve loco cuando los sitios web no lo permiten porque mi correo electrónico tiene contenido +y muchos sitios no lo permiten.
Dan Herbert el

42
Creo que es importante dar enlaces a las especificaciones, ya que realmente quieres hacerlo bien, y ahí es donde entra la especificación. Si eres demasiado vago para leer y comprender la especificación, deja de buscar los caracteres permitidos en las direcciones de correo electrónico a las personas que se preocupan por ese material.
jhwist

99
Pregunta anterior sobre el mismo material: stackoverflow.com/questions/760150/ . Lo triste es que, aunque esa pregunta es casi 8 meses mayor que esta, la pregunta anterior tiene respuestas mucho mejores. Casi todas las respuestas a continuación ya estaban desactualizadas cuando se publicaron originalmente. Vea la entrada de Wikipedia (y no se preocupe, tiene referencias oficiales relevantes ).
John Y

10
Contrariamente a varias respuestas, se permiten espacios en la parte local de las direcciones de correo electrónico, si se citan. "hello world"@example.comes válida.
user253751

3
@LaraRuffleColes: para Gmail, cuando crea una cuenta de correo electrónico, no le permite crear direcciones que contengan un signo "+". El signo "+" ("direccionamiento más") permite a cualquier persona con una dirección de Gmail agregar un signo "+" seguido de una "cadena" al final de su nombre de usuario para crear una dirección de correo electrónico "alternativa" ("alias") para usar para su cuenta. Ejemplo: "ejemplo@gmail.com", "ejemplo+tag@gmail.com". Un uso típico (y probablemente "primario") de esto es poder crear direcciones de correo electrónico con alias para su cuenta que le permitan etiquetar y filtrar los mensajes de correo electrónico entrantes, teóricamente filtrados por el remitente.
Kevin Fegan

Respuestas:


797

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 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 usar cualquiera de estos caracteres ASCII:

  • letras latinas mayúsculas y minúsculas Aa Zy apara z;
  • dígitos 0a 9;
  • personajes 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 (por ejemplo, John..Doe@example.comno está permitido pero "John..Doe"@example.comestá permitido);
  • el espacio y los "(),:;<>@[\]caracteres están permitidos con restricciones (solo se permiten dentro de una cadena entre comillas, como se describe en el párrafo a continuación, y además, una barra invertida o una comilla doble debe ir precedida de una barra invertida);
  • se permiten comentarios con paréntesis en cualquier extremo de la parte local; por ejemplo, john.smith(comment)@example.comy (comment)john.smith@example.comson equivalentes a john.smith@example.com.

Además de los caracteres ASCII, a partir de 2012 puede usar los caracteres internacionales anterioresU+007F , codificados 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 .

La domainparte se define de la siguiente manera :

Los estándares de Internet (Request For Comments) para los protocolos exigen que las etiquetas de nombre de host de componentes pueden contener sólo las letras ASCII aa través z(de una manera sensible a las mayúsculas), los dígitos 0través 9, y el guión ( -). La especificación original de los nombres de host en RFC 952 , ordenaba que las etiquetas no pudieran comenzar con un dígito o con un guión, y no deberí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.


15
@WildWzyr, no es tan simple. Las direcciones de correo electrónico tienen muchas reglas para lo que está permitido. Es más sencillo consultar las especificaciones que enumerarlas todas. Si desea la Regex completa, marque aquí para tener una idea de por qué no es tan simple: regular-expressions.info/email.html
Dan Herbert

66
no hay una lista simple, solo porque quieras algo simple no significa que sea así. algunos personajes solo pueden estar en ciertos lugares y no en otros. No puedes tener lo que quieres todo el tiempo.

15
@WildWezyr Bueno, el carácter completo está permitido en la parte local. Pero no al principio o al final. O con otro punto final. Entonces, la respuesta NO ES tan simple como una lista de caracteres permitidos, hay reglas sobre cómo se pueden usar esos caracteres: .ann..other.@example.comno es una dirección de correo electrónico válida, pero lo ann.other@example.comes, aunque ambos usan los mismos caracteres.
Mark Pim

14
Además, recuerde que con la entrada de nombres de dominio internacionalizados, la lista de caracteres permitidos explotará.
Chinmay Kanchi

50
Esta ya no es la respuesta válida, debido a las direcciones internacionalizadas. Ver la respuesta de Mason.
ZacharyP

329

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

Para evitar rechazos falsos positivos de direcciones de correo electrónico reales en el mundo actual y futuro, y desde cualquier parte del mundo, debe conocer al menos el concepto de alto nivel de RFC 3490 , "Internacionalización de nombres de dominio en aplicaciones (IDNA)". Sé que la gente en 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 las partes no dominadas por el inglés).

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

No sabía mucho sobre este desarrollo hasta que me mudé a Japón y comencé a ver direcciones de correo electrónico como hei @ や る .ca y URL de Amazon como esta:

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

Sé que no quieres enlaces a especificaciones, pero si confías únicamente en el conocimiento desactualizado de los piratas informáticos en los foros de Internet, tu validador de correo electrónico terminará rechazando las direcciones de correo electrónico que los usuarios que no hablan inglés esperan trabajar cada vez más. 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.

Por lo tanto, no digo que no sea una molestia, pero la lista completa de caracteres "permitidos bajo algunas condiciones / ninguna / ninguna" es (casi) todos los caracteres en todos los idiomas. Si desea "aceptar todas las direcciones de correo electrónico válidas (y también muchas inválidas)", debe tener en cuenta 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 a Punycode .

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


17
Derecha; detrás de escena, los nombres de dominio siguen siendo solo ASCII. Pero, si su aplicación web o formulario acepta la entrada ingresada por el usuario, entonces debe realizar el mismo trabajo que el navegador web o el cliente de correo cuando el usuario ingresa un nombre de host IDN: para convertir la entrada del usuario en un formulario compatible con DNS. Luego validar. De lo contrario, estas direcciones de correo electrónico internacionalizadas no pasarán su validación. (Los convertidores como el que vinculé para modificar solo modifican los caracteres no ASCII que se les dan, por lo que es seguro usarlos en direcciones de correo electrónico no internacionalizadas (solo se devuelven sin modificar).)
Mason

2
Para los desarrolladores de Javascript , ahora estoy investigando métodos para hacerlo, y Punycode.js parece ser la solución más completa y pulida.
wwaawaw

55
Tenga en cuenta que el correo electrónico internacionalizado (como se define actualmente) no convierte las direcciones que no son ASCII usando punycode o similar, sino que extiende grandes porciones del protocolo SMTP para usar UTF8.
IMSoP

2
¿Me estoy perdiendo algo o esto no responde la pregunta? Estoy leyendo 'la otra respuesta es incorrecta, debe aceptar más caracteres' pero luego no indica qué caracteres adicionales. Tampoco pude (fácilmente) ver en ese RFC si significa todos los puntos de código Unicode o solo el BMP.
Samuel Harmer

3
Esto parece estar en el camino correcto para ser la respuesta correcta. Apuesto a que obtendría muchos más votos si incluyese detalles sobre los personajes reservados y permitidos.
Sean

59

El formato de la dirección de correo electrónico es: local-part@domain-part(máx. 64 @ 255 caracteres, no más 256 en total).

El local-party domain-partpodrí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:

  • minúsculas letras latinas: abcdefghijklmnopqrstuvwxyz,
  • mayúsculas letras latinas: ABCDEFGHIJKLMNOPQRSTUVWXYZ,
  • dígitos: 0123456789,
  • caracteres especiales: !#$%&'*+-/=?^_`{|}~,
  • punto: .(no primer o último carácter o repetido a menos que se cite),
  • signos de puntuación tales como: "(),:;<>@[\](con algunas restricciones),
  • comentarios: ()(están permitidos entre paréntesis, por ejemplo (comment)john.smith@example.com).

Parte del dominio:

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

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

  • prettyandsimple@example.com
  • very.common@example.com
  • disposable.style.email.with+symbol@example.com
  • other.email-with-dash@example.com
  • x@example.com (parte local de una letra)
  • "much.more unusual"@example.com
  • "very.unusual.@.unusual.com"@example.com
  • "very.(),:;<>[]\".VERY.\"very@\ \"very\".unusual"@strange.example.com
  • example-indeed@strange-example.com
  • admin@mailserver1 (nombre de dominio local sin dominio de nivel superior)
  • #!$%&'*+-/=?^_`{}|~@example.org
  • "()<>[]:,;@\\"!#$%&'-/=?^_`{}| ~.a"@example.org
  • " "@example.org (espacio entre comillas)
  • example@localhost (enviado desde localhost)
  • example@s.solutions(vea la Lista de dominios de nivel superior de Internet )
  • user@com
  • user@localserver
  • user@[IPv6:2001:db8::1]

Y estos ejemplos de inválido:

  • Abc.example.com(sin @personaje)
  • A@b@c@example.com(solo @se permite una fuera de las comillas)
  • a"b(c)d,e:f;gi[j\k]l@example.com (ninguno de los caracteres especiales en esta parte local está permitido fuera de las comillas)
  • just"not"right@example.com (las cadenas entre comillas deben estar separadas por puntos o el único elemento que forma la parte local)
  • this is"not\allowed@example.com (los espacios, las comillas y las barras diagonales inversas solo pueden existir dentro de las cadenas entre comillas y precedidas por una barra diagonal inversa)
  • this\ still\"not\allowed@example.com (incluso si se escapa (precedido por una barra diagonal inversa), los espacios, las comillas y las barras inclinadas invertidas todavía deben estar entre comillas)
  • john..doe@example.com(doble punto antes @); (con advertencia: Gmail deja pasar esto)
  • john.doe@example..com(doble punto después @)
  • una dirección válida con un espacio inicial
  • una dirección válida con un espacio final

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


La expresión regular RFC2822 de Perl para validar correos electrónicos:

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

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

Ver también: RFC 822 Email Address Parser en PHP .


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

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

Relacionado:


55
Como precaución adicional para los posibles implementadores de esta expresión regular: no lo hagas. Simplemente verifique que siga el formato something@something.somethingy llámelo al día.
Chris Sobolewski

Si bien algo como esto no se puede mantener, es un buen ejercicio para decodificar y descubrir lo que hace
deshacer la modificación

@ChrisSobolewski permite múltiples cosas a ambos lados de la '@'
Jasen

Traté de implementar esto en postfix a través de la tabla de acceso pcre bajo una restricción check_recipient_access, primero convirtiendo los 3 pcres largos (desde la página vinculada) en una línea cada uno y rematando así: /^[...pcre ..] $ / DUNNO, luego agrega una línea final /.*/ RECHAZAR, pero todavía permite a través de direcciones de correo electrónico no válidas. Postfix 3.3.0; perl 5, versión 26, subversión 1 (v5.26.1).
scoobydoo

3
Locura, digo. ¿Quién lo usaría alguna vez en la producción? Hay un punto donde la expresión regular ya no debería usarse. Está mucho más allá de ese punto.
tomuxmon

22

Wikipedia tiene un buen artículo sobre esto , y la especificación oficial está aquí . De Wikipdia:

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

  • Letras mayúsculas y minúsculas en inglés (az, AZ)
  • Dígitos 0 a 9
  • Caracteres ! # $% & '* + - / =? ^ _ `{| } ~
  • Personaje . (punto, punto, punto final) siempre que no sea el primer o el último carácter, y siempre que no aparezca dos o más veces consecutivas.

Además, las cadenas entre comillas (es decir: "John Doe" @ example.com) están permitidas, lo que permite caracteres que de otro modo estarían prohibidos, sin embargo, no aparecen en la práctica común. El RFC 5321 también advierte que "un host que espera recibir correo DEBE evitar definir buzones donde la parte Local requiere (o usa) el formulario de Cadena entrecomillada".


@WildWezyr Nombres de host válidos, que podrían ser una dirección IP, FQN o algo que se pueda resolver en un host de red local.
Jensen murió el

Las cuerdas citadas eran esenciales para pasar por una puerta de enlace, ¿recuerda Banyan Vines?
mckenzm

13

Google hace algo interesante con sus direcciones de gmail.com. Las direcciones de gmail.com solo permiten letras (az), números y puntos (que se ignoran).

por ejemplo, pikachu@gmail.com es lo mismo que pi.kachu@gmail.com, y ambas direcciones de correo electrónico se enviarán al mismo buzón. PIKACHU@gmail.com también se entrega al mismo buzón.

Entonces, para responder la pregunta, a veces depende del implementador de cuánto de los estándares RFC quieren seguir. El estilo de dirección de gmail.com de Google es compatible con los estándares. Lo hacen de esa manera para evitar confusiones donde diferentes personas tomarían direcciones de correo electrónico similares, por ejemplo

*** gmail.com accepting rules ***
d.oy.smith@gmail.com   (accepted)
d_oy_smith@gmail.com   (bounce and account can never be created)
doysmith@gmail.com     (accepted)
D.Oy'Smith@gmail.com   (bounce and account can never be created)

El enlace de wikipedia es una buena referencia sobre lo que generalmente permiten las direcciones de correo electrónico. http://en.wikipedia.org/wiki/Email_address


2
Sí, esta es una gran respuesta sobre por qué Gmail no permite CREAR correos electrónicos con esto. Pero puede enviar y recibir correos electrónicos {john'doe}@my.serversin ningún problema. Probado con el servidor hMail también.
Piotr Kula

Puede probar su cliente enviando un correo electrónico a {piotr'kula}@kula.solutions: si funciona, recibirá un buen formulario de respuesta automática. De lo contrario no pasará nada.
Piotr Kula

3
Gmail sigue el RFC 6530 en el sentido de que todas las direcciones de correo electrónico posibles permitidas por Gmail son válidas de acuerdo con el RFC. Gmail simplemente elige restringir aún más el conjunto de direcciones permitidas con reglas adicionales y crear direcciones similares con puntos en la parte local, opcionalmente seguidas de "+" y caracteres alfanuméricos, incluso.
Teemu Leisti

Google limita los criterios de creación de la cuenta ... Me imagino que borran la cadena de la cuenta de correo electrónico entrante de la "puntuación" adicional y el signo de cadena de alias más al final para que el correo se pueda enrutar a la cuenta correcta. Pan comido. Al hacerlo, efectivamente no permiten que las personas creen direcciones de correo electrónico simplemente para ser un imbécil, de modo que las direcciones válidas creadas a menudo pasarán validaciones simples y más complejas.
BradChesney79

No es solo gmail, algunos proveedores tienen "filtros de retransmisión" que rechazan ciertas cadenas citadas, particularmente que contienen "=" como si fueran delimitadores. Esto es para evitar que los usuarios configuren puertas de enlace y aniden direcciones de spam en la cadena privada entre comillas. "@" es válido pero "= @ =" no es (considerado) válido.
mckenzm

12

Puedes comenzar desde el artículo de Wikipedia :

  • Letras mayúsculas y minúsculas en inglés (az, AZ)
  • Dígitos 0 a 9
  • Caracteres ! # $% & '* + - / =? ^ _ `{| } ~
  • Personaje . (punto, punto, punto final) siempre que no sea el primer o el último carácter, y siempre que no aparezca dos o más veces consecutivas.

11

Nombre:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!#$%&'*+-/=?^_`{|}~.

Servidor:

abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-.

44
¿Qué hay de <>y []? Por ejemplo, "()<>[]:,;@\\\"!#$%&'-/=?^_{} | ~ .a "@ example.org`?
kenorb

20
Por favor, cite las fuentes. Sin fuentes, esto parece una conjetura.
Mathieu K.

15
Esto está desactualizado y posiblemente nunca fue correcto.
Jason Harrison el

9

Verifique @ y. y luego envíe un correo electrónico para que lo verifiquen.

Todavía no puedo usar mi dirección de correo electrónico .name en el 20% de los sitios en Internet porque alguien arruinó su validación de correo electrónico o porque es anterior a que las nuevas direcciones sean válidas.


99
Incluso. no es estrictamente necesario; He oído hablar de al menos un caso de una dirección de correo electrónico en un dominio de nivel superior (específicamente ua). La dirección era <nombre> @ua - ¡sin punto!

Esta es la forma más fácil de no estropear su validación, porque casi todo está permitido, y si algo no está permitido, el servidor del destinatario se lo informará.
Avamander el

5

La respuesta corta es que hay 2 respuestas. Hay un estándar para lo que debe hacer. es decir, un comportamiento que es sabio y lo mantendrá alejado de los problemas. Hay otro estándar (mucho más amplio) para el comportamiento que debe aceptar sin causar problemas. Esta dualidad funciona para enviar y aceptar correos electrónicos, pero tiene una amplia aplicación en la vida.

Para una buena guía de las direcciones que crea; ver: http://www.remote.org/jochen/mail/info/chars.html

Para filtrar correos electrónicos válidos, simplemente pase cualquier cosa lo suficientemente comprensible para ver el siguiente paso. O comience a leer un montón de RFC, precaución, aquí hay dragones.


El enlace se ha ido. ¿Qué contenido había allí?
1919

5

Una buena lectura al respecto .

Extracto:

These are all valid email addresses!

"Abc\@def"@example.com
"Fred Bloggs"@example.com
"Joe\\Blow"@example.com
"Abc@def"@example.com
customer/department=shipping@example.com
\$A12345@example.com
!def!xyz%abc@example.com
_somename@example.com

1
Me preguntaba sobre la '@' antes de la parte del dominio. ¿Se puede usar eso?
Saiyaff Farouk

@SaiyaffFarouk según la especificación, sí. Sin embargo, la mayoría de los proveedores de correo probablemente no lo permitirán como parte de su propia validación
Luke Madhanga

ese blog enumera Joe.\\Blow@example.comsin citas. ¿Es esto realmente válido? No parece claro dadas las respuestas aquí, pero lo pregunto porque he visto casos (muy raros) de cadenas de correo electrónico DNS SoA rname que contienen barras invertidas.
wesinat0r

5

La respuesta aceptada se refiere a un artículo de Wikipedia cuando se discute la parte local válida de una dirección de correo electrónico, pero Wikipedia no es una autoridad en esto.

IETF RFC 3696 es una autoridad en este asunto, y debe ser consultado en la sección 3. Restricciones a las direcciones de correo electrónico en la página 5:

Las direcciones de correo electrónico contemporáneas consisten en una "parte local" separada de una "parte de dominio" (un nombre de dominio completo) por un signo de signo ("@"). La sintaxis de la parte del dominio corresponde a la de la sección anterior. Las preocupaciones identificadas en esa sección sobre el filtrado y las listas de nombres se aplican también a los nombres de dominio utilizados en un contexto de correo electrónico. El nombre de dominio también se puede reemplazar por una dirección IP entre corchetes, pero se desaconseja encarecidamente ese formulario, excepto para fines de prueba y solución de problemas.

La parte local puede aparecer usando las convenciones de citas que se describen a continuación. Los formularios citados rara vez se usan en la práctica, pero son necesarios para algunos fines legítimos. Por lo tanto, no se deben rechazar en las rutinas de filtrado, sino que se deben pasar al sistema de correo electrónico para su evaluación por el host de destino.

La regla exacta es que cualquier carácter ASCII, incluidos los caracteres de control, puede aparecer entre comillas o en una cadena entre comillas. Cuando se necesita una cita, el carácter de barra diagonal inversa se usa para citar el siguiente carácter. Por ejemplo

  Abc\@def@example.com

es una forma válida de una dirección de correo electrónico. También pueden aparecer espacios en blanco, como en

  Fred\ Bloggs@example.com

El carácter de barra diagonal inversa también se puede usar para citarse a sí mismo, por ejemplo,

  Joe.\\Blow@example.com

Además de las comillas utilizando el carácter de barra diagonal inversa, los caracteres de comillas dobles convencionales pueden usarse para rodear cadenas. Por ejemplo

  "Abc@def"@example.com

  "Fred Bloggs"@example.com

son formas alternativas de los dos primeros ejemplos anteriores. Estos formularios citados rara vez se recomiendan y son poco comunes en la práctica, pero, como se discutió anteriormente, deben ser compatibles con las aplicaciones que procesan direcciones de correo electrónico. En particular, las formas citadas a menudo aparecen en el contexto de direcciones asociadas con transiciones de otros sistemas y contextos; esos requisitos de transición aún surgen y, dado que un sistema que acepta una dirección de correo electrónico proporcionada por el usuario no puede "saber" si esa dirección está asociada con un sistema heredado, los formularios de dirección deben aceptarse y pasarse al entorno de correo electrónico.

Sin comillas, las partes locales pueden consistir en cualquier combinación de
caracteres alfabéticos, dígitos o cualquiera de los caracteres especiales.

  ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

También puede aparecer un punto ("."), pero no puede usarse para iniciar o finalizar la parte local, ni pueden aparecer dos o más períodos consecutivos. Dicho de otra manera, cualquier carácter gráfico (impresión) ASCII que no sea el signo de signo ("@"), barra diagonal inversa, comillas dobles, comas o corchetes puede aparecer sin comillas. Si alguno de esa lista de caracteres excluidos va a aparecer, se deben citar. Formas como

  user+mailbox@example.com

  customer/department=shipping@example.com

  $A12345@example.com

  !def!xyz%abc@example.com

  _somename@example.com

son válidos y se ven con bastante regularidad, pero se permite cualquiera de los caracteres enumerados anteriormente.

Como lo han hecho otros, envío una expresión regular que funciona tanto para PHP como para JavaScript para validar las direcciones de correo electrónico:

/^[a-z0-9!'#$%&*+\/=?^_`{|}~-]+(?:\.[a-z0-9!'#$%&*+\/=?^_`{|}~-]+)*@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-zA-Z]{2,}$/i

3

Como se puede encontrar en este enlace de Wikipedia

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

  • letras latinas mayúsculas y minúsculas Aa Zy apara z;

  • dígitos 0a 9;

  • personajes 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 (por ejemplo, John..Doe@example.comno está permitido pero "John..Doe"@example.comestá permitido);

  • el espacio y los "(),:;<>@[\]caracteres están permitidos con restricciones (solo se permiten dentro de una cadena entre comillas, como se describe en el párrafo a continuación, y además, una barra invertida o una comilla doble debe ir precedida de una barra invertida);

  • se permiten comentarios con paréntesis en cualquier extremo de la parte local; por ejemplo, john.smith(comment)@example.comy (comment)john.smith@example.comson equivalentes a john.smith@example.com.

Además de los caracteres ASCII anteriores, RFC 6531 permite caracteres internacionales por encima de U + 007F, codificados como UTF-8 , aunque los sistemas de correo pueden restringir qué caracteres usar al asignar partes locales.

Una cadena entre comillas puede existir como una entidad separada por puntos dentro de la parte local, o puede existir cuando las comillas más externas son los caracteres más externos de la parte local (por ejemplo, abc."defghi".xyz@example.como "abcdefghixyz"@example.comestán permitidas. Por el contrario, abc"defghi"xyz@example.comno lo es; tampoco lo es abc\"def\"ghi@example.com). Sin embargo, las cadenas y caracteres entre comillas no se usan comúnmente. El RFC 5321 también advierte que "un host que espera recibir correo DEBE evitar definir buzones donde la parte Local requiere (o usa) el formulario de Cadena entrecomillada".

La parte local postmasterse trata especialmente, no distingue entre mayúsculas y minúsculas y debe reenviarse al administrador de correo electrónico del dominio. Técnicamente, todas las demás partes locales distinguen entre mayúsculas y minúsculas, por lo tanto, jsmith@example.comy JSmith@example.comespecifican buzones diferentes; sin embargo, muchas organizaciones tratan las letras mayúsculas y minúsculas como equivalentes.

A pesar de la amplia gama de caracteres especiales que son técnicamente válidos; organizaciones, servicios de correo, servidores de correo y clientes de correo en la práctica a menudo no los aceptan a todos. Por ejemplo, Windows Live Hotmail solo permite la creación de direcciones de correo electrónico utilizando alfanuméricos, punto ( .), guión bajo ( _) y guión ( -). Un consejo común es evitar el uso de algunos caracteres especiales para evitar el riesgo de correos electrónicos rechazados.


0

La respuesta es (casi) ALL(ASCII de 7 bits).
Si las reglas de inclusión son "... permitidas bajo algunas condiciones / ninguna / ninguna ..."

Simplemente observando una de las varias posibles reglas de inclusión para el texto permitido en la parte de "texto de dominio" en RFC 5322 en la parte superior de la página 17 encontramos:

dtext          =   %d33-90 /          ; Printable US-ASCII
                   %d94-126 /         ;  characters not including
                   obs-dtext          ;  "[", "]", or "\"

los únicos tres caracteres faltantes en esta descripción se usan en literal de dominio [], para formar un par entre comillas \, y el carácter de espacio en blanco (% d32). Con eso se usa todo el rango 32-126 (decimal). Un requisito similar aparece como "qtext" y "ctext". Muchos caracteres de control también están permitidos / utilizados. Una lista de tales caracteres de control aparece en la página 31 sección 4.1 de RFC 5322 como obs-NO-WS-CTL.

obs-NO-WS-CTL  =   %d1-8 /            ; US-ASCII control
                   %d11 /             ;  characters that do not
                   %d12 /             ;  include the carriage
                   %d14-31 /          ;  return, line feed, and
                   %d127              ;  white space characters

Todos estos caracteres de control están permitidos como se indica al comienzo de la sección 3.5:

.... MAY be used, the use of US-ASCII control characters (values
     1 through 8, 11, 12, and 14 through 31) is discouraged ....

Y esa regla de inclusión es, por lo tanto, "demasiado amplia". O, en otro sentido, la regla esperada es "demasiado simplista".


0

En aras de la simplicidad, desinfecto el envío eliminando todo el texto entre comillas dobles y las comillas dobles que lo rodean antes de la validación, poniendo el quiste en los envíos de direcciones de correo electrónico en función de lo que está prohibido. El hecho de que alguien pueda tener el John ... "La dirección * $ hizzle * Bizzle" .. Doe@whatever.com no significa que deba permitirlo en mi sistema. Estamos viviendo en el futuro donde tal vez tome menos tiempo obtener una dirección de correo electrónico gratuita que hacer un buen trabajo limpiando su trasero. Y no es como si los criterios de correo electrónico no estuvieran pegados justo al lado de la entrada diciendo lo que está y no está permitido.

También desinfecta lo que específicamente no está permitido por varios RFC después de que se elimine el material citado. La lista de caracteres y patrones específicamente no permitidos parece ser una lista mucho más corta para probar.

No permitido:

    local part starts with a period ( .account@host.com )
    local part ends with a period   ( account.@host.com )
    two or more periods in series   ( lots..of...dots@host.com )
    &’`*|/                          ( some&thing`bad@host.com )
    more than one @                 ( which@one@host.com )
    :%                              ( mo:characters%mo:problems@host.com )

En el ejemplo dado:

John.."The*$hizzle*Bizzle"..Doe@whatever.com --> John..Doe@whatever.com

John..Doe@whatever.com --> John.Doe@whatever.com

Enviar un mensaje de correo electrónico de confirmación al resultado sobrante al intentar agregar o cambiar la dirección de correo electrónico es una buena manera de ver si su código puede manejar la dirección de correo electrónico enviada. Si el correo electrónico pasa la validación después de tantas rondas de desinfección como sea necesario, entonces active esa confirmación. Si una solicitud regresa del enlace de confirmación, entonces el nuevo correo electrónico se puede mover del estado o almacenamiento del purgatorio || temporario || para convertirse en un correo electrónico almacenado de primera clase real y de buena fe.

Si desea ser considerado, puede enviar una notificación de falla o éxito en el cambio de la dirección de correo electrónico a la dirección de correo electrónico anterior. Las configuraciones de cuenta no confirmadas pueden caerse del sistema como intentos fallidos por completo después de un período de tiempo razonable.

No permito correos electrónicos apestosos en mi sistema, tal vez eso sea solo tirar dinero. Pero, el 99.9% de las veces las personas simplemente hacen lo correcto y tienen un correo electrónico que no empuja los límites de conformidad al límite utilizando escenarios de compatibilidad de casos extremos. Tenga cuidado con regex DDoS, este es un lugar donde puede meterse en problemas. Y esto está relacionado con la tercera cosa que hago, pongo un límite a cuánto tiempo estoy dispuesto a procesar cualquier correo electrónico. Si necesita ralentizar mi máquina para que se valide, no está pasando la lógica de mi punto final de API de datos entrantes.

Editar: Esta respuesta siguió siendo criticada por ser "mala", y tal vez se la merecía. Quizás todavía es malo, quizás no.


2
Creo que esta respuesta es rechazada porque esta es una opinión, y en realidad no responde la pregunta. Además, los usuarios que obtienen su dirección de correo electrónico silenciosamente desinfectada nunca recibirán correos electrónicos de usted. Será mejor que les informe que su dirección de correo electrónico no es aceptada.
vcarel

2
Sospecho que los votos negativos se deben a que hay demasiadas ideas aquí. La lista de no permitidos, si bien estas son pruebas unitarias útiles, deben ir precedidas de lo que está permitido. El enfoque de programación parece relativamente bueno, pero probablemente encajaría mejor después de enumerar las especificaciones con las que está trabajando, etc. Las secciones y la edición de copias moderadas ayudarían. Solo mis 2 centavos.
HoldOffHunger

@vcarel - Oh, por supuesto. La validación del lado del usuario front-end les informaría qué reglas (disponibles en la información sobre herramientas) estaban incumpliendo. Tienes razón, es una opinión general. Sin embargo, la pregunta anterior es de alguien que está preguntando a X por una pregunta Y con seguridad. Esto es una guía y funciona ... no solo funciona, funciona bien. No dejo que las direcciones de correo electrónico de mierda en mis sistemas donde tome las decisiones.
BradChesney79

@HoldOffHunger Puedo ver que la idea general no se expresa de manera tan coherente como podría ser, puedo revisar en otro día donde tenga más tiempo para expresarlo mejor. Gracias por la perspicacia.
BradChesney79

-1

En mi PHP utilizo esta verificación

<?php
if (preg_match(
'/^(?:[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+\.)*[\w\!\#\$\%\&\'\*\+\-\/\=\?\^\`\{\|\}\~]+@(?:(?:(?:[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!\.)){0,61}[a-zA-Z0-9_-]?\.)+[a-zA-Z0-9_](?:[a-zA-Z0-9_\-](?!$)){0,61}[a-zA-Z0-9_]?)|(?:\[(?:(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:[01]?\d{1,2}|2[0-4]\d|25[0-5])\]))$/',
"tim'qqq@gmail.com"        
)){
    echo "legit email";
} else {
    echo "NOT legit email";
}
?>

Pruébelo usted mismo http://phpfiddle.org/main/code/9av6-d10r


-1

Creé esta expresión regular de acuerdo con las pautas de RFC:

^[\\w\\.\\!_\\%#\\$\\&\\'=\\?\\*\\+\\-\\/\\^\\`\\{\\|\\}\\~]+@(?:\\w+\\.(?:\\w+\\-?)*)+$

1
Esta versión mejora la expresión regular al verificar la longitud de dominio / subdominios. ¡Disfrutar! ^ [\\ w \\. \\! _ \\% # \\ $ \\ & \\ '= \\? \ * \\ + \\ - \\ / \\ ^ \ `\\ {\\ | \\} \\ ~] + @ (?: [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])? (?: \\. [\\ w] (?: [\\ w \\ -] {0,61} [\\ w])?) *) $
Mau

-2

Gmail solo permitirá + signo como carácter especial y, en algunos casos (.), Pero no se permiten otros caracteres especiales en Gmail. RFC dice que puede usar caracteres especiales, pero debe evitar enviar correos a Gmail con caracteres especiales.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.