Me pregunto hasta qué punto la gente debería llevar la validación de la dirección de correo electrónico. Mi campo es principalmente desarrollo web, pero esto se aplica en cualquier lugar.

He visto algunos enfoques:

• simplemente verificando si hay un "@" presente, que es muy simple pero por supuesto no tan confiable
• una prueba de expresión regular más compleja para formatos de correo electrónico estándar
• una expresión regular completa contra RFC 2822 : el problema con esto es que a menudo una dirección de correo electrónico puede ser válida, pero probablemente no sea lo que el usuario quiso decir
• Validación de DNS
• Validación SMTP

Como muchas personas pueden saber (pero muchas no), las direcciones de correo electrónico pueden tener muchas variaciones extrañas que la mayoría de las personas no suelen considerar (ver RFC 2822 3.4.1 ), pero hay que pensar en los objetivos de su validación: ¿simplemente está tratando de asegurarse de que un mensaje de correo electrónico se puede enviar a una dirección, o que es lo que el usuario probablemente quiso poner (lo cual es poco probable en muchos de los casos más oscuros de lo contrario? válido 'direcciones).

Una opción que he considerado es simplemente dar una advertencia con una dirección más esotérica, pero aún así permitir que se realice la solicitud, pero esto agrega más complejidad a un formulario y es probable que la mayoría de los usuarios se confundan.

Si bien la validación de DNS / validación de SMTP parece no tener en cuenta, preveo problemas en los que el servidor DNS / servidor SMTP está temporalmente fuera de servicio y un usuario no puede registrarse en algún lugar, o el servidor SMTP del usuario no admite las características requeridas.

¿Cómo podrían algunos desarrolladores experimentados aquí manejar esto? ¿Hay otros enfoques que los que he enumerado?

Editar: Olvidé por completo el más obvio de todos, ¡enviando un correo electrónico de confirmación! Gracias a los que respondieron por señalarlo. Sí, este es bastante infalible, pero requiere molestias adicionales por parte de todos los involucrados. El usuario tiene que buscar algún correo electrónico, y el desarrollador necesita recordar los datos del usuario antes de que incluso se confirme que son válidos.

No hay una forma 100% confiable de confirmar una dirección de correo electrónico válida que no sea enviar un correo electrónico al usuario y esperar una respuesta, como la mayoría de los foros.

Iría con la simple regla de validación "@" y luego enviaría un correo electrónico al usuario para confirmar su dirección de correo electrónico.

Aunque, esta es mi opinión personal ... espero otras sugerencias.

Una sugerencia: no rechace las direcciones con un + en ellas. Es molestamente común rechazarlos, pero es un carácter válido, y los usuarios de gmail pueden usar [email protected] para etiquetar y ordenar el correo entrante con mayor facilidad.

En tu publicación parece que cuando dices "validación SMTP" te refieres a conectarte al servidor y probar un RCPT TO para ver si es aceptado. Como lo diferencia de enviar un correo electrónico de confirmación, supongo que desea hacerlo en línea con las acciones del usuario. Además de problemas como problemas de red, fallas de DNS, etc., la lista gris puede causar estragos con este método. Los métodos varían, pero la lista esencialmente gris siempre difiere el primer intento de entregar al destinatario por IP de conexión. Como dije, esto puede variar, algunos hosts pueden rechazar direcciones no válidas en el primer intento y solo diferir las direcciones válidas, pero no hay una manera confiable de resolver las diferentes implementaciones mediante programación.

La única manera de asegurarse de que una dirección sea válida y la envíe su propietario que realmente quiere que se use para su aplicación es enviando un correo electrónico de verificación. Bueno, siempre y cuando no se filtre el spam, supongo =).

Otra debilidad de usar una expresión regular para la validación de correo electrónico es que es casi imposible capturar todos los dominios válidos de nivel superior mientras se rechazan todos los dominios no válidos.

Por ejemplo, la expresión regular básica del correo electrónico en la respuesta de Jeff Atwood:

\ b [A-Z0-9 ._% + -] + @ [A-Z0-9 .-] +. [AZ] {2,4} \ b

aceptará cualquier TLD de dos a cuatro caracteres. Entonces, por ejemplo, .spam será aceptado, pero .museum y .travel (ambos TLD válidos) serán rechazados.

Solo una razón más por la que es mejor buscar la @ y enviar un correo electrónico de confirmación.

Con nombres de dominio internacionales, casi todo es posible:

• Håkan.Söderström@malmö.se
• [email protected]
• 试 @ 例子. 测试 .مثال.آزمایشی

Si desea hacer alguna prueba, primero debe convertirla a punycode.

Sin punycode, todo lo que debe hacer es probar que allí:

• es al menos una @
• es al menos un personaje en la parte local
• es al menos un punto en la parte del dominio
• tiene al menos cuatro caracteres en el dominio (suponiendo que nadie tenga una dirección en el tld, que el tld tenga al menos 2 caracteres)

function isEmail(address) {
    var pos = address.lastIndexOf("@");
    return pos > 0 && (address.lastIndexOf(".") > pos) && (address.length - pos > 4);
}

Es mejor que solo busque cosas simples como @ y. en JavaScript, y luego enviarles una verificación a su correo electrónico. Si verifican su cuenta, usted tiene una dirección de correo electrónico válida. De esa manera, sabrá con certeza que tiene una dirección de trabajo y no tiene que ser demasiado mandón en el formulario.

Use un validador de código abierto que no dé falsos negativos. Esfuerzo cero para usted y validación sólida para su aplicación.

Ahora he recopilado casos de prueba de Cal Henderson, Dave Child, Phil Haack, Doug Lovell y RFC 3696. 158 direcciones de prueba en total.

Ejecuté todas estas pruebas contra todos los validadores que pude encontrar. La comparación está aquí: http://www.dominicsayers.com/isemail

Intentaré mantener esta página actualizada a medida que las personas mejoren sus validadores. Gracias a Cal, Dave y Phil por su ayuda y cooperación en la compilación de estas pruebas y críticas constructivas de mi propio validador .

Las personas deben ser conscientes de la errata contra RFC 3696 en particular. Tres de los ejemplos canónicos son, de hecho, direcciones no válidas. Y la longitud máxima de una dirección es de 254 o 256 caracteres, no 320.

Considerando las respuestas (dado que me olvidé por completo de los correos electrónicos de confirmación), me parece que un compromiso adecuado para una solución de baja fricción sería:

1. Use regex para verificar que la dirección de correo electrónico parezca válida, y avise si es más oscura, pero evite rechazarla por completo.
2. Use la validación SMTP para asegurarse de que la dirección de correo electrónico sea válida.
3. Si la validación SMTP falla, entonces, y solo entonces , use un correo electrónico de confirmación como último recurso. Los correos electrónicos de confirmación parecen requerir demasiada interacción fuera de su aplicación para que se consideren de baja fricción, pero son una alternativa perfecta.

RegexBuddy ofrece las siguientes expresiones regulares relacionadas con el correo electrónico de su biblioteca:

Dirección de correo electrónico (básica)

\b[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}\b

Dirección de correo electrónico (RFC 2822, simplificado)

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

Pero tiendo a estar de acuerdo con las respuestas de Peter y SuperJoe; la única "prueba" real es enviar un correo electrónico de validación.

He trabajado en 4 compañías diferentes donde alguien en la mesa de ayuda recibió un grito de alguien llamado O'Malley o O'Brien o alguna otra dirección de correo electrónico con un apóstrofe. Como se sugirió anteriormente, no todas las expresiones regulares capturarán todo, pero ahórrese algunas molestias y acepte un apóstrofe sin generar una advertencia.

-
bmb

Podría llevar la validación del correo electrónico aún más lejos para probar realmente si existe un buzón. Esta técnica tiene sus inconvenientes (tiempo de desarrollo y también posibilidad de quedar en la lista negra por mal uso). http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/

Si desea verificar un correo electrónico (es decir, asegurarse de que el usuario posee la dirección de correo electrónico), lo único que puede hacer es un correo electrónico de confirmación. Por otra parte, muchas personas tienen direcciones de correo no deseado dedicadas o utilizan servicios como OneWayMail y, si no quieren darle su dirección de correo electrónico real, no lo harán. Entonces, básicamente, estás creando una obstrucción del usuario.

Cuando se trata de la validación , para asegurarse de que el usuario no ingresa involuntariamente una dirección de correo electrónico incorrecta, definitivamente es la motivación correcta. Sin embargo, al menos para los formularios HTML (que son, con mucho, la forma más común de recopilar direcciones de correo electrónico), no es el instrumento adecuado.

Por un lado, no podrá reconocer los errores tipográficos en las "palabras" reales de la dirección de correo electrónico. No tiene forma de descubrir que [email protected]está mal, únicamente en función del formato.
Pero lo más importante, desde el punto de vista del usuario, solo hay una (o una mano llena) de direcciones de correo electrónico que posiblemente desee ingresar. Y probablemente ya lo hayas ingresado.
Por lo tanto, en lugar de intentar validar una dirección, debe centrarse en garantizar que todos los navegadores reconozcan el campo de correo electrónico y, por lo tanto, eliminen la necesidad de escribir la dirección de correo electrónico en primer lugar. Por supuesto, esto no se aplica, si está creando el tipo de sitio que probablemente sea afectado por usuarios que nunca antes ingresaron su dirección de correo electrónico en su navegador. Pero supongo que el menor de nosotros estamos en esa posición.

Creo que depende del contexto para el que estés usando el correo electrónico. Los proyectos más serios requieren una validación más estricta, pero creo que para la mayoría de las cosas, enviar un correo electrónico a la dirección proporcionada con un enlace de conformación garantizará que la dirección de correo electrónico sea válida.

@ Mike : creo que parte de la razón por la cual se envían correos electrónicos de confirmación no es solo para garantizar que la dirección de correo electrónico sea válida, sino que sea accesible para el usuario que la envió. Una persona podría ingresar fácilmente un error tipográfico de una letra en la dirección de correo electrónico que conduciría a una dirección de correo electrónico válida diferente, pero eso sería un error, ya que sería la dirección incorrecta .

La expresión regular más completa y precisa que he encontrado para la validación de correo electrónico es la que se documenta aquí . No es para gente impresionable; es lo suficientemente complicado como para dividirse en partes para que sea más fácil de analizar por los humanos (el código de muestra está en Java) Pero en los casos en que merece la pena llegar hasta el final con la validación, no creo que mejore mucho.

En cualquier caso, sugeriría que use pruebas unitarias para confirmar que su expresión cubre los casos que considera importantes. De esa manera, mientras analizas, puedes estar seguro de que no has roto algún caso que funcionó antes.

Lo que elija, creo que es necesario errar por el lado de la creencia de que el 99% de las veces, el usuario no sabe realmente cuál es su dirección de correo electrónico es. Como alguien de Australia, todavía encuentro muy ocasionalmente una validación de correo electrónico tan inteligente que me dice que no puedo tener un dominio .com.au. Solía ​​suceder mucho más en los primeros días de Internet.

Enviar un correo electrónico de confirmación en estos días es aceptable para los usuarios, y también es útil en términos de suscripción, así como para validar su dirección proporcionada.

En algunos sitios desarrollados en lugares en los que he trabajado, siempre hemos usado correos electrónicos de confirmación. Sin embargo, era sorprendentemente común que los usuarios escribieran mal su dirección de correo electrónico de una manera que posiblemente no hubiera funcionado, y luego sigan esperando el correo electrónico de confirmación que no llegaría. Agregar un código ad-hoc (o, para la parte del nombre de dominio, verificación DNS) para advertir al usuario en estos casos podría ser una buena idea.

Los casos comunes que he visto:

• Colocando una letra en el medio del nombre de dominio, o varias otras variantes de error tipográfico simples.
• Confusión de TLD (por ejemplo, agregar un .bra un .comdominio o quitar el .brde un .com.brdominio).
• Agregar un www.al principio de la parte local de una dirección de correo electrónico (no estoy inventando esto; vi varias direcciones de correo electrónico del formulario [email protected]).

Hubo casos aún más extraños; cosas como un nombre de dominio completo como parte local, direcciones con dos @(algo así como [email protected]@example.com), y así sucesivamente.

Por supuesto, la mayoría de ellos seguían siendo direcciones RFC-822 válidas, por lo que técnicamente podría dejar que la MTA se encargue de ellos. Sin embargo, advertir al usuario que la dirección de correo electrónico ingresada es posiblemente falsa puede ser útil, especialmente si su público objetivo no es muy experto en informática.

Toda la validación de expresiones regulares en el mundo no evitará que alguien ingrese una dirección de correo electrónico incorrecta o falsa. Es realmente molesto, de verdad.

Depende del objetivo. Si usted es un ISP y necesita validar que los usuarios están creando direcciones de correo electrónico válidas, busque la expresión regular que valida con todo lo posible. Si solo desea detectar los errores del usuario, ¿qué tal el siguiente patrón:

[Todos los caracteres, sin espacios] @ [letras y números] (. [Letras y números]) donde el grupo final aparece al menos una vez.

El RegEx para esto parecería algo como esto:

[\S]+@[\w]+(.[\w-]+)+

Y luego envíe un correo electrónico de confirmación para estar seguro.

@ Yaakov (podría responder hacer con algún tipo de 'respuesta' aquí)

Creo que parte de la razón por la cual se envían correos electrónicos de confirmación no es solo para garantizar que la dirección de correo electrónico sea válida, sino que sea accesible para el usuario que la envió. Una persona podría ingresar fácilmente un error tipográfico de una letra en la dirección de correo electrónico que conduciría a una dirección de correo electrónico válida diferente, pero eso sería un error ya que sería la dirección incorrecta.

Estoy de acuerdo, pero no estoy seguro de que valga la pena. También tenemos campos de confirmación para ese propósito (repitiendo su dirección de correo electrónico nuevamente). Otra situación en la que el tipo de sitio podría justificar diferentes enfoques.

Además, el envío de un correo electrónico de confirmación en sí mismo no le indica al usuario original que la dirección que ingresó es incorrecta. Después de no recibir el correo electrónico de confirmación, pueden suponer que su aplicación / sitio está defectuoso; al menos al permitir que el usuario comience a usar su cuenta de inmediato, puede corregir su dirección de correo electrónico, especialmente si se muestra en un lugar convenientemente obvio.

Caballos de carreras.

Todos estos son sistemas de verificación de correo electrónico completos y válidos en sí mismos, y para un sitio web determinado, uno será más apropiado (o tan bueno como se garantiza) que los demás. En muchos casos, varios pasos de verificación pueden ser útiles.

Si está desarrollando un sitio web para un banco, además de todo esto, querrá una verificación por correo o por teléfono.

Si está desarrollando un sitio web para un concurso, es posible que no desee ninguno de ellos: verifique los correos electrónicos en el procesamiento posterior y si uno falla es demasiado malo para la persona que lo ingresó, puede valorar el rendimiento del servidor dado el gran enamoramiento de las personas ( Concurso de televisión, por ejemplo) sobre asegurarse de que todos sean validados correctamente en línea.

¿Qué tan lejos se debe llevar la verificación por correo electrónico?

En la medida de lo necesario y garantizado.

Y no más (BESO)

He visto sitios que también protegen contra las personas que usan sitios temporales desechables de correo no deseado como Mailinator o MyTrashMail , que evitan el correo electrónico de confirmación. No digo que debas filtrarlos, solo digo.

¿Qué estás tratando de atrapar en tu validación de correo electrónico?

La validación de expresiones regulares de las direcciones de correo electrónico puede, en el mejor de los casos, verificar que la dirección sea sintácticamente correcta y relativamente plausible. También tiene el peligro (como ya se mencionó muchas veces) de posiblemente rechazar direcciones reales y entregables si la expresión regular no es del todo correcta.

La verificación SMTP puede determinar que la dirección se puede entregar, sujeta a las limitaciones impuestas por las listas grises o los servidores que están configurados para proporcionar la menor información posible sobre sus usuarios. No tiene forma de saber si la MTA solo ha afirmado aceptar correo para una dirección falsa, luego lo dejó caer al suelo como parte de una estrategia contra el correo no deseado.

Sin embargo, enviar un mensaje de confirmación es la única forma de verificar que una dirección pertenece al usuario que la ingresó. Si estoy completando tu formulario, puedo decirte fácilmente que mi dirección de correo electrónico es [email protected]. Una expresión regular le dirá que es sintácticamente válida, un SMTP RCPT TO le dirá que es una dirección entregable, pero seguro que no es mi dirección.

Con la llegada de HTML5, se agrega al menos un nuevo enfoque a las posibilidades: el uso de la entrada de tipo ' correo electrónico ' que permite la validación en el lado del cliente. Las versiones actuales de Firefox, Chrome, Safari y Opera lo admiten (y otros navegadores solo lo tratan como type = text, por lo que puede usarse sin problemas aunque no tenga validación, por supuesto).

Nunca puede (como se señala varias veces) garantizar una dirección viable, pero puede ser muy beneficioso (y eventualmente reemplazar la verificación del lado del servidor) en lugares donde solo necesita detectar posibles errores del usuario.

Los tres niveles principales de validación de correo electrónico:

1) comprobación de expresión regular para una dirección de correo electrónico con el formato correcto [email protected]

2) verificar el dominio de correo electrónico con los registros MX para ver si el nombre de dominio tiene un servicio de correo electrónico

3) enviar un correo electrónico de confirmación con un enlace o código de confirmación

Nivel 1:

En Visual Studio, puede usar el "Validador de expresiones regulares". Y en la propiedad "ValidationExpression" puede hacer clic en el botón "..." que tiene un asistente para agregar en el formato de expresión regular para las direcciones de correo electrónico.

Nivel 2:

Aquí está mi código C # a continuación para usar nslookup para verificar si un dominio de correo electrónico tiene registros MX válidos. Corre rápido y bien en Win 2008 R2 y Win 7.

using System.Net.Mail;
using System.Diagnostics;

public static bool checkMXRecords(string email) 
    {
        MailAddress addr = new MailAddress(email);
        string domain = addr.Host;

        string command = "nslookup -querytype=mx " + domain;
        ProcessStartInfo procStartInfo = new ProcessStartInfo("cmd", "/c " + command);

        procStartInfo.RedirectStandardOutput = true;
        procStartInfo.UseShellExecute = false;

        procStartInfo.CreateNoWindow = true;

        Process proc = new Process();
        proc.StartInfo = procStartInfo;
        proc.Start();
        string result = proc.StandardOutput.ReadToEnd();

        if (result.ToLower().Contains("mail exchanger"))
        {
            return true;
        }
        else return false;

     } // checkMXRecords

Otra opción es usar el paquete Nuget de Arsofttools, pero puede ser lento en Windows Server 2008 R2 como he experimentado, pero se ejecuta rápidamente en Win 7.

Nivel 3:

Para la confirmación por correo electrónico, puede generar una URL hexadecimal específica de correo electrónico (utilizando funciones de cifrado), etc. http://domain.com/validateEmail?code=abcd1234 para validar la dirección de correo electrónico cuando el usuario hace clic en ella. No es necesario almacenar esta url en la memoria.