Non esiste un metodo affidabile al 100% per confermare un indirizzo email valido diverso dall'invio di un messaggio di posta elettronica all'utente e in attesa di una risposta, come la maggior parte dei forum.

Vorrei andare con la semplice regola di convalida "@" e poi inviare un'email all'utente per confermare il proprio indirizzo email.

Anche se, questa è la mia opinione personale ... attendo altri suggerimenti.

Un suggerimento: non rifiutare gli indirizzi con un + in essi. È fastidiosamente comune rifiutarli, ma è un personaggio valido e gli utenti di Gmail possono usare [email protected] per etichettare e ordinare più facilmente la posta in arrivo.

Nel tuo post sembra che quando dici "convalida SMTP" intendi la connessione al server e prova un RCPT TO per vedere se è accettato. Dal momento che la distingui effettivamente dall'invio di un'e-mail di conferma, presumo che tu voglia farlo in linea con le azioni dell'utente. Oltre a problemi come problemi di rete, guasti DNS, ecc., La lista grigia può causare il caos con questo metodo. La lista dei metodi, ma essenzialmente grigia, rimanda sempre il primo tentativo di consegna al destinatario per IP di connessione. Come ho detto, questo può variare, alcuni host potrebbero rifiutare gli indirizzi non validi al primo tentativo e solo rinviare gli indirizzi validi, ma non esiste un modo affidabile per ordinare le diverse implementazioni a livello di codice.

L'unico modo in cui sarai mai sicuro che un indirizzo è valido e che è stato inviato dal suo proprietario che lo vuole veramente utilizzato per la tua applicazione è quello di inviare un'email di verifica. Bene, finché non viene filtrato lo spam, suppongo che =).

Un altro punto debole dell'utilizzo di un'espressione regolare per la convalida della posta elettronica è che è quasi impossibile intercettare tutti i domini di primo livello respingendo tutti quelli non validi.

Ad esempio, l'email di base viene regex nella risposta di Jeff Atwood:

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

accetterà qualsiasi TLD da due a quattro caratteri. Quindi, ad esempio, .spam sarà accettato, ma .museum e .travel (entrambi TLD validi) saranno rifiutati.

Solo un altro motivo è meglio cercare la @ e inviare un'email di conferma.

Con i nomi di dominio internazionali quasi tutto è possibile:

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

Se vuoi fare dei test, devi prima convertirlo in punycode.

Senza punycode tutto ciò che dovresti fare è testarlo lì:

• è almeno uno @
• è almeno un carattere nella parte locale
• è almeno un punto nella parte del dominio
• è almeno quattro caratteri nel dominio (presupponendo che nessuno abbia un indirizzo nel tld, che il tld sia almeno 2 caratteri)

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

Stai meglio semplicemente controllando cose semplici come @ e. in JavaScript, e quindi effettivamente inviare loro una verifica per la loro e-mail. Se verificano il loro account, hai un indirizzo email valido. In questo modo sai per certo di avere un indirizzo di lavoro, e non devi essere troppo prepotente nel modulo.

Utilizza un validatore open-source che non dia falsi negativi. Impegno zero per te e valida validazione per la tua app.

Ora ho raccolto i casi di test da Cal Henderson, Dave Child, Phil Haack, Doug Lovell e RFC 3696. 158 indirizzi di test in tutto.

Ho eseguito tutti questi test contro tutti i validatori che ho trovato. Il confronto è qui: link

Cercherò di mantenere questa pagina aggiornata man mano che le persone migliorano i loro validatori. Grazie a Cal, Dave e Phil per il loro aiuto e collaborazione nel compilare questi test e critiche costruttive su il mio validatore .

Le persone dovrebbero essere consapevoli del errata contro RFC 3696 in particolare. Tre degli esempi canonici sono in realtà indirizzi non validi. E la lunghezza massima di un indirizzo è 254 o 256 caratteri, non 320.

Considerando le risposte (dato che ho completamente dimenticato le e-mail di conferma) mi sembra che un compromesso adeguato per una soluzione a basso coefficiente sarebbe:

1. Usa regex per verificare che l'indirizzo e-mail sia valido e avvisa se è più oscuro, ma evita di rifiutarlo a titolo definitivo.
2. Utilizza la convalida SMTP per assicurarti che l'indirizzo e-mail sia valido.
3. Se la convalida SMTP fallisce allora - e solo allora - usa un'e-mail di conferma come ultima risorsa. Le e-mail di conferma sembrano richiedere troppa interazione al di fuori dell'applicazione per essere considerate a basso attrito, ma sono un perfetto ripiego.

RegexBuddy offre le seguenti espressioni regolari relative alla posta elettronica dalla sua libreria:

Indirizzo email (base)

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

Indirizzo email (RFC 2822, semplificato)

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

Ma io tendo ad essere d'accordo con le risposte di Peter e SuperJoe; l'unico vero "test" è in realtà l'invio di un'email di convalida.

Ho lavorato in 4 diverse società in cui qualcuno all'help desk è stato urlato da qualcuno di nome O'Malley o O'Brien o qualche altro indirizzo e-mail con un apostrofo. Come suggerito in precedenza, non tutte le regex cattureranno tutto, ma ti risparmieranno alcuni problemi e accetterai un apostrofo senza generare un avviso.

-
BMB

Potresti ancora convalidare la posta elettronica per verificare effettivamente se esiste una casella di posta. Questa tecnica ha i suoi svantaggi (tempo di sviluppo e anche possibilità di ottenere la lista nera per uso improprio). link

Se vuoi verificare un'e-mail (ad esempio, assicurati che l'utente possieda l'indirizzo e-mail), l'unica cosa che puoi fare è una e-mail di conferma. Poi di nuovo molte persone hanno dedicato indirizzi di spam o utilizzano servizi come OneWayMail e se non vogliono darti il loro vero indirizzo e-mail, non lo faranno. Quindi in pratica stai creando l'ostruzione dell'utente.

Quando si tratta di validazione , per garantire che l'utente non involontariamente inserire un indirizzo e-mail sbagliato, è sicuramente la motivazione giusta. Tuttavia, almeno per i moduli HTML (che sono di gran lunga il modo più comune per raccogliere indirizzi e-mail), non è certo lo strumento giusto.

Per uno, non sarai in grado di riconoscere errori di battitura nelle "parole" effettive dell'indirizzo email. Non hai modo di scoprire che [email protected] è sbagliato, unicamente in base al formato.
Ma ancora più importante, dal punto di vista dell'utente, c'è solo una (o una mano piena) di indirizzi email che potresti voler inserire. E probabilmente l'hai già inserito.
Quindi, piuttosto che provare a convalidare un indirizzo, dovresti concentrarti sull'assicurare che tutti i browser riconoscano il campo email e quindi eliminino la necessità di digitare l'indirizzo email in primo luogo. Naturalmente questo non si applica, se stai costruendo il tipo di sito che potrebbe essere colpito da utenti che non hanno mai inserito il loro indirizzo e-mail nel loro browser prima. Ma suppongo che il minimo di noi sia in una posizione del genere.

Penso che dipenda dal contesto in cui stai usando l'email. I progetti più seri richiedono una convalida più severa, ma penso che per la maggior parte delle cose inviando una e-mail all'indirizzo fornito con un link di conformità si assicurerà che l'indirizzo e-mail sia valido.

@ Mike - Penso questa parte del motivo per cui le e-mail di conferma vengono inviate non è solo per garantire che l'indirizzo e-mail sia valido, ma che sia accessibile dall'utente che lo ha inviato. Una persona potrebbe facilmente inserire un errore di battitura a una lettera nell'indirizzo email che porterebbe a un indirizzo email diverso, valido, ma sarebbe comunque un errore in quanto sarebbe l'indirizzo sbagliato .

La regex più completa e accurata che abbia mai riscontrato per la convalida della posta elettronica è quella documentata qui . Non è per i deboli di cuore; è abbastanza complicato da essere suddiviso in parti per renderlo più semplice da analizzare (il codice di esempio è in Java). Ma nei casi in cui è meritato di andare fino in fondo con la convalida, non penso che andrà molto meglio.

In ogni caso, ti suggerisco di utilizzare il test dell'unità per confermare che la tua espressione copre i casi che ritieni importanti. In questo modo, man mano che ci tocchi, puoi essere sicuro di non aver infranto alcuni casi precedentemente funzionanti.

Qualunque cosa tu scelga, penso che tu debba errare nel credere che il 99% delle volte, l'utente in realtà sappia qual è il loro indirizzo email. Come qualcuno dall'Australia, trovo ancora occasionalmente una convalida e-mail così intelligente che mi dice che non posso possedere un dominio .com.au. Succedeva molto di più agli albori di Internet.

L'invio di un'email di conferma in questi giorni è accettabile per gli utenti ed è anche utile in termini di attivazione e di convalida dell'indirizzo fornito.

Su alcuni siti sviluppati nei luoghi in cui ho lavorato, abbiamo sempre utilizzato e-mail di conferma. Tuttavia, era sorprendentemente comune che gli utenti inserissero erroneamente il proprio indirizzo email in modi che non avrebbero potuto funzionare, e quindi aspettavano l'e-mail di conferma che non sarebbe arrivata. Aggiungere un codice ad hoc (o, per la parte relativa al nome di dominio, la verifica DNS) per avvisare l'utente in questi casi potrebbe essere una buona idea.

I casi comuni che ho visto:

• Rilascio di una lettera a metà del nome del dominio o di altre varianti semplici di battitura.
• Confusione TLD (ad esempio, aggiunta di .br a un dominio .com o eliminazione di .br da un dominio .com.br ).
• Aggiunta di un www. all'inizio della parte locale di un indirizzo email (non lo sto inventando, ho visto diversi indirizzi email del modulo [email protected] ).

C'erano anche casi più bizzarri; cose come un nome di dominio completo come la parte locale, gli indirizzi con due @ (qualcosa come [email protected]@example.com ), e così via.

Naturalmente, la maggior parte di questi erano ancora indirizzi RFC-822 validi, quindi tecnicamente si poteva semplicemente lasciare che il MTA si occupasse di loro. Tuttavia, avvisare l'utente che l'indirizzo email inserito è probabilmente fasullo può essere utile, specialmente se il pubblico di destinazione non è molto informatico.

Tutte le convalide regex nel mondo non impediranno a qualcuno di inserire un indirizzo email errato o falso. È davvero fastidioso, davvero.

Dipende dall'obiettivo. Se sei un ISP e devi convalidare che gli utenti stiano creando indirizzi email validi, scegli il Regex che convalida contro tutto ciò che è possibile. Se vuoi solo catturare gli errori degli utenti, che ne dici del seguente modello:

[Tutti i caratteri, senza spazi] @ [lettere e numeri] (. [lettere e numeri]) dove il gruppo finale appare almeno una volta.

Il RegEx per questo apparirebbe in questo modo:

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

E poi invia un'email di conferma per essere sicuro.

@ Yaakov (potrebbe rispondere fare con una sorta di 'risposta' qui)

I think that part of the reason why confirmation emails are sent is not only to ensure that the email address is valid, but that it is accessible by the user who submitted it. A person could easily put in a one-letter typo in the email address that would lead to a different, valid email address, but that would still be an error as it would be the wrong address.

Sono d'accordo, ma non sono sicuro che ne valga la pena. Disponiamo inoltre di campi di conferma a tale scopo (ripetendo di nuovo il tuo indirizzo e-mail). Un'altra situazione in cui il tipo di sito potrebbe giustificare approcci diversi.

Inoltre, l'invio di una e-mail di conferma non fornisce alcun modo di indicare all'utente originale che l'indirizzo inserito è sbagliato. Dopo aver ricevuto l'e-mail di conferma, potrebbero semplicemente ritenere che la tua app / il tuo sito sia difettosa; almeno consentendo all'utente di iniziare immediatamente a utilizzare il proprio account, potrebbe correggere il proprio indirizzo e-mail, in particolare se viene visualizzato in un luogo idoneo.

Cavalli per i corsi.

Tutti quelli sono validi, completi sistemi di verifica della posta elettronica in sé e per sé, e per un determinato sito web uno sarà più appropriato (o buono come è garantito) rispetto agli altri. In molti casi possono essere utili diversi passaggi di verifica.

Se stai sviluppando un sito web per una banca, hai intenzione di volere la posta ordinaria o la verifica del telefono in aggiunta a tutti questi.

Se stai sviluppando un sito Web per un concorso potresti non volerne nessuno - verifica le email in post-elaborazione e se uno fallisce è troppo brutto per la persona che lo ha inserito - potresti dare un valore alle prestazioni del server dato una grande cotta di persone (concorso TV, ad esempio) per assicurarsi che tutti vengano correttamente convalidati in linea.

Fino a che punto si dovrebbe effettuare una verifica tramite e-mail?

Nella misura necessaria e giustificata.

E non oltre (KISS)

Ho visto siti che proteggono anche le persone che utilizzano siti di spam temporaneo indesiderati come Mailinator o MyTrashMail , che aggira l'e-mail di conferma. Non sto dicendo che dovresti filtrare quelli, sto solo dicendo.

Che cosa stai cercando di intercettare nella convalida della tua email?

La convalida degli indirizzi e-mail di Regex può, nel migliore dei casi, verificare che l'indirizzo sia sintatticamente corretto e relativamente plausibile. Ha anche il rischio (come già detto molte volte) di poter rifiutare gli indirizzi effettivi e consegnabili se la regex non è del tutto corretta.

La verifica SMTP può determinare che l'indirizzo è consegnabile, soggetto alle limitazioni imposte dal greylisting o ai server che sono configurati in modo da fornire il minor numero possibile di informazioni sui propri utenti. Non hai modo di sapere se il MTA ha solo affermato di accettare la posta per un indirizzo falso, quindi lo ha fatto cadere per terra come parte di una strategia anti-spam.

L'invio di un messaggio di conferma, tuttavia, è il modo solo per verificare che un indirizzo appartenga all'utente che l'ha inserito. Se sto compilando il modulo, posso tranquillamente dirti che il mio indirizzo email è [email protected] . Una regex ti dirà che è sintatticamente valido, un RCPT TO SMTP ti dirà che è un indirizzo consegnabile, ma sicuramente non è il mio indirizzo.

Con l'avvento di HTML5 almeno un nuovo approccio si aggiunge alle possibilità: l'uso dell'input di tipo " email 'che consente la convalida sul lato client. Le versioni attuali di Firefox, Chrome, Safari e Opera supportano questo (e altri browser lo trattano come tipo = testo, quindi può essere usato senza problemi, anche se non hai una convalida, ovviamente.)

Non può mai (come si fa notare alcune volte) garantire un indirizzo lavorabile, ma può essere molto utile (e alla fine sostituire il controllo lato server) in punti in cui è necessario rilevare i probabili errori dell'utente.

I tre principali livelli di convalida dell'email:

1) controllo di espressioni regolari per un indirizzo email correttamente formattato [email protected]

2) controllo del dominio di posta elettronica contro i record MX per vedere se il nome di dominio ha un servizio di posta elettronica

3) inviando un'e-mail di conferma con un link di conferma o un codice

Livello 1:

In Visual Studio, puoi utilizzare "Validatore di espressioni regolari". E nella proprietà "ValidationExpression" puoi cliccare sul pulsante "..." che ha una procedura guidata per aggiungere il formato di espressione regolare per gli indirizzi email.

Livello 2:

Ecco qui sotto il mio codice C # per utilizzare nslookup per verificare se un dominio di posta elettronica ha record MX validi. Corre veloce e ok su Win 2008 R2 e 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

un'altra opzione è quella di usare il pacchetto nuget di Arsofttools ma potrebbe essere lento su Windows Server 2008 R2 come ho sperimentato, ma funziona velocemente su Win 7.

Livello 3:

Per la conferma via e-mail, puoi generare un URL esadecimale specifico dell'email (utilizzando le funzioni di crittografia) ecc link per convalidare il indirizzo email quando l'utente fa clic su di esso. Non è necessario memorizzare questo URL in memoria.