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 sencilla 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 direcciones con un + en ellas. Resulta molesto rechazarlos, pero es un carácter válido, y los usuarios de gmail pueden usar [email protected] para etiquetar y clasificar el correo entrante más fácilmente.

En tu publicación, parece que cuando dices "validación SMTP" te refieres a conectarte al servidor e intentar una RCPT TO para ver si se acepta. Dado que lo diferencias de enviar un correo electrónico de confirmación, asumo que quieres 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 en este método. Los métodos varían, pero la lista esencialmente gris siempre difiere el primer intento de entrega 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 ordenar las diferentes implementaciones mediante programación.

La única forma en la que podrá estar seguro de que una dirección es válida y que sea enviada por su propietario, quien realmente quiere que se use para su aplicación, es enviar un correo electrónico de verificación. Bueno, mientras 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 detectar todos los dominios de nivel superior mientras se rechazan todos los inválidos.

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

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

aceptará cualquier TLD de dos a cuatro caracteres. Así, por ejemplo, se aceptará .spam, pero se rechazarán .museum y .travel (ambos TLD válidos).

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

Con los nombres de dominio internacionales casi todo es posible:

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

Si desea realizar alguna prueba, primero debe convertirla en punycode.

Sin Punycode, todo lo que debes hacer es probar que existe:

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

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

Es mejor que compruebes cosas simples como @ y. en JavaScript, y luego enviarles una verificación a su correo electrónico. Si ellos verifican su cuenta, usted tiene una dirección de correo electrónico válida. De esa manera, seguro 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. Cero esfuerzo para ti y robusta validación para tu 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.

Corrí todas estas pruebas contra todos los validadores que pude encontrar. La comparación está aquí: enlace

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 la crítica constructiva de mi propio validador .

Las personas deben conocer 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 (ya 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 se vea válida, y dé una advertencia 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, simplificada)

[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 en realidad enviar un correo electrónico de validación.

He trabajado en 4 compañías diferentes donde alguien de la mesa de ayuda fue gritado por 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 lo captará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 para probar si realmente existe un buzón. Esta técnica tiene sus inconvenientes (tiempo de desarrollo y también posibilidad de ser incluida en la lista negra por mal uso). enlace

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. Entonces, nuevamente, muchas personas tienen direcciones de correo no deseado dedicadas o utilizan servicios como OneWayMail y si no desean proporcionarle su dirección de correo electrónico real, no lo harán Así que básicamente estás creando la obstrucción del usuario.

Cuando se trata de validation , para garantizar que el usuario no lo intencionalmente ingresar una dirección de correo electrónico incorrecta, es definitivamente 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] es incorrecto, únicamente en función del formato.
Pero, lo que es 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.
Entonces, en lugar de intentar validar una dirección, debe concentrarse 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 serán afectados por usuarios que nunca antes ingresaron su dirección de correo electrónico en su navegador. Pero supongo que los más pequeños 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, en la mayoría de los casos, enviar un correo electrónico a la dirección proporcionada con un enlace de confirmación garantizará que la dirección de correo electrónico sea válida.

@ Mike : creo Esa parte del motivo por el que se envían los correos electrónicos de confirmación no es solo para garantizar que la dirección de correo electrónico sea válida, sino también para que sea accesible para el usuario que la envió. Una persona podría colocar fácilmente un error tipográfico de una letra en la dirección de correo electrónico que llevaría a una dirección de correo electrónico diferente y válida, pero aún 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 documentada aquí . No es para gente impresionable; es lo suficientemente complicado como para dividirse en partes para facilitar el análisis de los humanos (el código de muestra está en Java). Pero en los casos en los que se merece todo el proceso de validación, no creo que mejore mucho.

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

Lo que elijas, creo que debes equivocarte al creer que el 99% de las veces, el usuario realmente sabe cuál es su dirección de correo electrónico. Como alguien de Australia, todavía encuentro muy ocasionalmente una validación de correo electrónico tan inteligente que me dice que posiblemente no pueda tener un dominio .com.au. Solía suceder mucho más en los primeros días de internet, por supuesto.

El envío de 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 aceptación y validación de la dirección proporcionada.

En algunos sitios desarrollados en lugares en los que he trabajado, siempre hemos utilizado correos electrónicos de confirmación. Sin embargo, fue 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 esperaran 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, la verificación de DNS) para advertir al usuario en estos casos podría ser una buena idea.

Los casos comunes que he visto:

• Bajando una letra en medio del nombre de dominio, o varias otras variantes simples de errores tipográficos.
• confusión de TLD (por ejemplo, agregar un .br a un dominio .com , o eliminar el .br de un dominio .com.br ).
• 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 ), etc.

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

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

Depende de la meta. Si usted es un ISP y necesita validar que los usuarios están creando direcciones de correo electrónico válidas, busque el Regex que valida contra todo lo posible. Si solo desea detectar los errores de los usuarios, ¿qué le parece 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 aparecerá algo como esto:

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

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

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

  

Creo que parte de la razón por la que se envían los correos electrónicos de confirmación no es solo para garantizar que la dirección de correo electrónico sea válida, sino también para que sea accesible para el usuario que la envió. Una persona podría colocar fácilmente un error tipográfico de una letra en la dirección de correo electrónico que llevaría a una dirección de correo electrónico diferente y válida, pero aún así 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 (repetir su dirección de correo electrónico nuevamente). Otra situación en la que el tipo de sitio puede justificar enfoques diferentes.

Además, el envío de un correo electrónico de confirmación en sí mismo no da forma de indicar al usuario original que la dirección que ingresaron era incorrecta. Después de no recibir el correo electrónico de confirmación, pueden asumir que su aplicación / sitio es defectuoso; al menos, al permitir que el usuario comience a usar su cuenta inmediatamente, podrían corregir su dirección de correo electrónico, especialmente si se muestra en un lugar claramente visible.

Caballos para cursos.

Todos esos 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 justifique) que los otros. En muchos casos, varios pasos de verificación pueden ser útiles.

Si estás desarrollando un sitio web para un banco, querrás que el correo postal o la verificación telefónica aparezcan por encima de todo esto.

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 muy malo para la persona que lo participó. de personas (concurso de TV, por ejemplo) sobre asegurarse de que todos se validen correctamente en línea.

¿Hasta dónde debe llevarse la verificación por correo electrónico?

En la medida de lo necesario y garantizado.

Y no más (KISS)

He visto sitios que también protegen contra las personas que utilizan sitios de basura desechables temporales como Mailinator o MyTrashMail , que evita el correo electrónico de confirmación. No estoy diciendo que debas filtrarlos, solo lo digo.

¿Qué intentas detectar en la validación de tu 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 riesgo (como ya se mencionó muchas veces) de posiblemente rechazar direcciones reales y de entrega 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 la lista gris o los servidores que están configurados para proporcionar la menor información posible sobre sus usuarios. No tiene forma de saber si el MTA solo ha afirmado que acepta el correo para una dirección falsa, luego simplemente lo dejó caer en el piso como parte de una estrategia antispam.

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

Con la llegada de HTML5, al menos un nuevo enfoque se agrega 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 son compatibles con esto (y otros navegadores simplemente lo tratan como tipo = texto, por lo que puede usarse sin problemas, por lo que no tiene validación, por supuesto).

Nunca puede (como se ha señalado 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 de usuario.

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

1) Verificación de expresiones regulares para una dirección de correo electrónico con el formato correcto [email protected]

2) comprobar el dominio del correo electrónico contra los registros MX para ver si el nombre de dominio tiene un servicio de correo electrónico

3) enviando 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 de 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 Arsofttools pero puede ser lento en Windows Server 2008 R2 como lo 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 del correo electrónico (mediante las funciones de cifrado), etc. enlace para validar la Dirección de correo electrónico cuando el usuario hace clic en él. No hay necesidad de almacenar esta url en la memoria.