Validación segura del correo electrónico

La forma más sencilla de probar esto sería intentar enviar un correo electrónico a esa dirección, desde una dirección de solo envío (es decir, desde [email protected]). Si no se puede entregar, no es válido.

El uso de una expresión regular para analizar correos electrónicos probablemente se haga mejor en el lado del cliente para informarles de antemano que pueden tener errores tipográficos en su dirección de correo electrónico, antes de que se registren.

Dice que desea tener direcciones de correo electrónico seguras . Supongo que esto significa que se colocan en tu aplicación y esperas un resultado predecible. Los desarrolladores que escriben su aplicación tienen en su cabeza colectiva alguna idea de qué esperar dentro de un campo de correo electrónico, y es mejor que no permita nada más allí. Lo que sus programadores no esperan no es muy seguro (incluso si es válido de acuerdo con algunas RFC horribles).

Entonces, si sus desarrolladores no están muy interesados en los RFC relacionados con el correo electrónico, sugiero usar "una violación intencional de RFC 5322" que existe dentro de un estándar W3C para HTML5, y se traduce a una expresión regular bastante simple:

^[a-zA-Z0-9.!#$%&'*+/=?^_'{|}~-]+@[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])?)*$

fuente enlace

En caso de que sea demasiado relajado (si crees que tus desarrolladores no esperan esos #$%&| , etc. extraños), sugiero asegurarlo un poco más:

^[a-zA-Z0-9.+/=?^_-]+@[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])?)+$

Creo que el 99.9% de las direcciones de personas reales coinciden con estas dos expresiones.

Puedes pasar demasiado tiempo preocupándote por este tipo de cosas. ¿Por qué te importa tanto?

Realmente no hay una dirección insegura como tal, lo que cuenta es lo que haces con ella / cómo lo procesas.

Si procesa la dirección de forma no segura, por ejemplo. concatenando una cadena para hacer sql en lugar de usar parámetros, entonces está pidiendo problemas, no solo en las direcciones de correo electrónico, sino en todos los campos que le permite al usuario ingresar.

Simplemente poner; siempre que tenga

[>= one char] @ [>= one char] . [>= one char]

o incluso simplemente:

[>= one char] @ [>= one char]

debes permitirlo. Realmente no importa cuáles son esos caracteres.

Las respuestas que enfatizan la necesidad de utilizar un enfoque en capas en lugar de confiar en un solo filtro o defensa están en el camino correcto. Hay montones de artículos por ahí sobre cómo escribir la expresión regular "correcta" para validar una dirección de correo. La realidad es que necesita combinar varios controles y no puede simplemente confiar en una expresión regular.

Los controles que necesite dependerán de lo que trata de hacer y de los riesgos contra los que trata de protegerse. Si solo está tratando de identificar a los remitentes de correo no deseado, es posible que también deba mirar el contenido, las líneas de asunto y los servidores de correo originales. Por otro lado, si está intentando verificar una dirección de correo para un proceso de registro, es posible que desee verificar el dominio, posiblemente agregar un proceso de confirmación que envíe un mensaje a la dirección, etc.

Mi consejo es similar a @MattWilko: pronto obtendrás rendimientos decrecientes cuando trates de obtener la expresión regular perfecta. A medida que su expresión se vuelva más compleja, capturará más direcciones erróneas, pero casi con seguridad también aumentará el número de falsos positivos. La clave es encontrar el equilibrio adecuado y ese equilibrio dependerá de su caso de uso y de los riesgos que intenta proteger.