Validando emails

Nunca entenderé por qué algunos programadores se preocupa hasta el paroxismo por controlar que las cuentas de correo de los formularios estén correctas.
Luego sin embargo puedes inventarte teléfonos, colocar una misma letra mil veces en el nombre, inventarte países de residencia. Todo eso parece dar igual.
function isEmail(str)
{
var regex = /^[-_.a-z0-9]+@(([-_a-z0-9]+\.)+(ad|ae|aero|af|ag|
ai|al|am|an|ao|aq|ar|arpa|as|at|au|aw|az|ba|bb|bd|be|bf|bg|
bh|bi|biz|bj|bm|bn|bo|br|bs|bt|bv|bw|by|bz|ca|cc|cd|cf|cg|
ch|ci|ck|cl|cm|cn|co|com|coop|cr|cs|cu|cv|cx|cy|cz|de|dj|dk|
dm|do|dz|ec|edu|ee|eg|eh|er|es|et|eu|fi|fj|fk|fm|fo|fr|ga|gb|
gd|ge|gf|gh|gi|gl|gm|gn|gov|gp|gq|gr|gs|gt|gu|gw|gy|hk|hm|hn|
hr|ht|hu|id|ie|il|in|info|int|io|iq|ir|is|it|jm|jo|jp|ke|kg|
kh|ki|km|kn|kp|kr|kw|ky|kz|la|lb|lc|li|lk|lr|ls|lt|lu|lv|ly|
ma|mc|md|mg|mh|mil|mk|ml|mm|mn|mo|mp|mq|mr|ms|mt|mu|museum|
mv|mw|mx|my|mz|na|name|nc|ne|net|nf|ng|ni|nl|no|np|nr|nt|nu|
nz|om|org|pa|pe|pf|pg|ph|pk|pl|pm|pn|pr|pro|ps|pt|pw|py|qa|
re|ro|ru|rw|sa|sb|sc|sd|se|sg|sh|si|sj|sk|sl|sm|sn|so|sr|st|
su|sv|sy|sz|tc|td|tf|tg|th|tj|tk|tm|tn|to|tp|tr|tt|tv|tw|tz|
ua|ug|uk|um|us|uy|uz|va|vc|ve|vg|vi|vn|vu|wf|ws|ye|yt|yu|za|
zm|zw)|(([0-9][0-9]?|[0-1][0-9][0-9]|[2][0-4][0-9]|[2][5][0-5])\.){3}([0-9][0-9]?|[0-1][0-9][0-9]|[2][0-4][0-9]|[2][5][0-5]))$/i;
}

Compra mi libro en Amazon.es o Amazon.com.

5.99€ ebook, 14.99€ libro pasta blanda.

20 comentarios en “Validando emails”

  1. Así como es también la única forma de tener un medio de hacer llegar publicidad con seguridad de ser recibida.

  2. y… elemental!
    el mail va a ser el único medio de contacto que le quede al encargado del formulario en el caso que el emisor ingrese algún dato inválido…

  3. ¿Puede ser para evitar posibles errores por parte del usuario a la hora de escribirla? Creo que será eso, más que por razones de seguridad ya que cualquier dato es fácilmente falseable, como apuntaís.

  4. No suele ser decisión nuestra, pero la razón principal siempre es la importancia. El correo electrónico casi siempre es el dato más importante, o bien a nivel de la aplicación, para la que el resto de los datos giran entorno a él, o bien para los departamentos de marketing y/o publicidad, que sólo emplean el resto de los datos para segmentar.

  5. Interesante… Probablemente dado el anonimato que brinda la web, la dirección de mail es lo más “tangible” que podemos exigir a un usuario, a través de lo cual lo vamos a spammear incesantemente luego de validar que la dirección es correcta :P
    Como desarrollador de software que soy, he visto bugs graves con las direcciones de residencia, pero no daré pistas :P

  6. Hombre esa función es algo exagerado, pero comprobar el dominio del correo con un dns mx si que lo he usado muchas veces y creo que es bastante recomendable si te lo puedes permitir.
    Así compruebas de verdad que el mail “puede” ser válido y evitas tener mails modo test@test.com como dice rsp :P. La comprobación en código son dos líneas, el tiempo debería ser menor a 500ms (pones un timeout) y consigues aumentar considerablemente la fiabilidad.

  7. Estoy de acuerdo. Creo que debe validarse que un email tenga “algo”, una arroba, otro “algo” y un “puntoalgo”. Y ya está, nada más. A partir de aquí creo que la solución pasa por mandar al email una clave de confirmación con un tiempo de vida. Si pasado ese tiempo de vida la cuenta no ha sido confirmada, eliminamos los datos de registro.
    Una posible solución para evitar quebraderos de cabeza.

  8. 1. ¿Por qué me piden mi email en este formulario?
    2. ¿Se valida?
    3. Creo que el mejor recurso para validar emails que existe es tener que introducirlos por duplicado (como las contraseñas). Esto no sólo verifica que esté bien escrito sino que aparta a algunos usuarios dolosos, pero perezosos.

  9. @Alex, hacer un ping al dominio no te dice que ese dominio tenga correo electrónico. Aparte de que es mucho más lento que una consulta dns

  10. La respuesta es muy facil, lo interesante de todos los datos es el correo electronico para poder mandar spam.
    El resto no es * (obligatorio)

  11. Hola, en el sistema que actualmente construimos en el curro, la expresión regular que utilizo, es aquella que cumple con la
    RFC2822. Sólo soporta formatos de direcciones “addr-spec” with “dot-atom”, esto es, (ATEXT_TOKEN+(\.ATEXT_TOKEN+)*) @ (ATEXT_TOKEN+(\.ATEXT_TOKEN+)*)
    La expresión regular queda como (Java regex):
    ([a-zA-Z0-9!#\$%\&’\*\+\-/=\?\^_`\{\|\}~]+(\.[a-zA-Z0-9!#\$%\&’\*\+\-/=\?\^_`\{\|\}~]+)*)@([a-zA-Z0-9!#\$%\&’\*\+\-/=\?\^_`\{\|\}~]+(\.[a-zA-Z0-9!#\$%\&’\*\+\-/=\?\^_`\{\|\}~]+)*)
    Ni que decir que no valida el dominio, pues según la RFC, no hay lista de dominios a validar, pues un correo electronico no tiene por que tener dominio de primer nivel (TLD) com, es, org, … Los correos son basicamente identificador@servidor, donde servidor puede ser cualquier cosa (un nombre de máquina).

Deja un comentario

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