Mi chiedo fino a che punto le persone dovrebbero prendere la convalida dell'indirizzo e-mail. Il mio campo è principalmente lo sviluppo web, ma questo vale ovunque.

Ho visto alcuni approcci:

• semplicemente controllando se c'è un "@" presente, che è semplice ma ovviamente non affidabile.
• un test regex più complesso per i formati di posta elettronica standard
• una regex completa contro RFC 2822 - il problema è che spesso un indirizzo e-mail potrebbe essere valido ma probabilmente non è ciò che l'utente intendeva
• Convalida DNS
• Validazione SMTP

Come molte persone potrebbero sapere (ma molti non lo sanno), gli indirizzi e-mail possono avere molte strane variazioni che la maggior parte delle persone di solito non considera (vedi RFC 2822 3.4.1 ), ma devi pensare agli obiettivi di la tua convalida: stai semplicemente cercando di assicurarti che un messaggio di posta elettronica possa essere inviato a un indirizzo, o che sia ciò che l'utente probabilmente intendeva inserire (il che è improbabile in molti dei casi più oscuri di altrimenti 'valido "indirizzi).

Un'opzione che ho preso in considerazione è semplicemente dare un avvertimento con un indirizzo più esoterico ma consentire comunque di passare la richiesta, ma ciò aggiunge maggiore complessità a un modulo e la maggior parte degli utenti rischia di essere confusa.

Mentre la convalida DNS / la convalida SMTP sembra non-brainer, prevedo problemi in cui il server DNS / server SMTP è temporaneamente inattivo e un utente non è in grado di registrarsi da qualche parte, o il server SMTP dell'utente non supporta le funzionalità richieste.

In che modo alcuni sviluppatori esperti qui possono gestire questo? Esistono approcci diversi da quelli che ho elencato?

Modifica: ho completamente dimenticato il più ovvio di tutti, inviando un'e-mail di conferma! Grazie a chi risponde per averlo segnalato. Sì, questo è piuttosto infallibile, ma richiede ulteriore seccatura da parte di tutti i soggetti coinvolti. L'utente deve recuperare un po 'di posta elettronica e lo sviluppatore deve ricordare i dati dell'utente prima ancora che siano confermati validi.

Non esiste un modo affidabile al 100% per confermare un indirizzo e-mail valido se non l'invio di un'e-mail all'utente e l'attesa di una risposta, come la maggior parte dei forum.

Vorrei andare con la semplice regola di convalida "@" e quindi e-mail all'utente per confermare il loro indirizzo e-mail.

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

Un suggerimento: non rifiutare gli indirizzi con un + in essi. È fastidiosamente comune rifiutarli, ma è un carattere valido e gli utenti di Gmail possono utilizzare address+label@gmail.com per etichettare e ordinare più facilmente la posta in arrivo.

Nel tuo post sembra che quando dici "convalida SMTP" intendi collegarti al server e provare un RCPT TO per vedere se è accettato. Dal momento che lo differenzia dall'invio effettivo 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ò creare scompiglio con questo metodo. Il metodo varia, ma in sostanza l'elenco grigio indica sempre il primo tentativo di recapitare al destinatario per IP di connessione. Come ho detto, questo può variare, alcuni host potrebbero rifiutare indirizzi non validi al primo tentativo e rinviare solo indirizzi validi, ma non esiste un modo affidabile per risolvere le diverse implementazioni a livello di codice.

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

Un altro punto debole dell'utilizzo di una regex per la convalida della posta elettronica è che è quasi impossibile catturare tutti i domini di primo livello validi mentre si rifiutano tutti quelli non validi.

Ad esempio, la regex e-mail di base nella risposta di Jeff Atwood:

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

accetterà qualsiasi TLD di 2-4 caratteri. Ad esempio, verrà accettato .spam, ma .museum e .travel (entrambi TLD validi) verranno rifiutati.

Un motivo in più è meglio cercare @ e inviare un'e-mail di conferma.

Con i nomi di dominio internazionali quasi tutto è possibile:

• Håkan.Söderström@malmö.se
• punnycode@XN--0ZWM56D.XN--HGBK6AJ7F53BBA
• 试 @ 例子. 测试 .مثال.آزمایشی

Se vuoi fare qualche test, devi prima convertirlo in codice di codice.

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

• è almeno uno @
• è almeno un personaggio nella parte locale
• è almeno un punto nella parte dominio
• ha almeno quattro caratteri nel dominio (supponendo 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);
}

Faresti meglio a controllare cose semplici come @ e. in JavaScript, quindi invia effettivamente una verifica alla loro email. Se verificano il loro account, hai un indirizzo email valido. In questo modo sai per certo che hai un indirizzo di lavoro e non devi essere troppo prepotente nel modulo.

Usa un validatore open source che non dia falsi negativi. Zero sforzi per te e solida convalida per la tua app.

Ora ho raccolto 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 sono riuscito a trovare. Il confronto è qui: http://www.dominicsayers.com/isemail

Cercherò di mantenere aggiornata questa pagina man mano che le persone miglioreranno i propri validatori. Grazie a Cal, Dave e Phil per l'aiuto e la collaborazione nella compilazione di questi test e critiche costruttive del mio validatore .

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

Sulla base delle risposte (dato che mi sono completamente dimenticato delle e-mail di conferma), mi sembra che un compromesso adeguato per una soluzione a basso attrito sarebbe:

1. Usa regex per verificare che l'indirizzo e-mail appaia valido e avvisa se è più oscuro, ma evita di rifiutarlo.
2. Utilizzare la convalida SMTP per assicurarsi che l'indirizzo e-mail sia valido.
3. Se la convalida SMTP ha esito negativo, quindi - e solo allora - utilizzare un'e-mail di conferma come ultima risorsa. Le e-mail di conferma sembrano richiedere troppe interazioni all'esterno dell'applicazione per essere considerate a basso attrito, ma sono un perfetto fallback.

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 e-mail (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 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 aziende in cui qualcuno dell'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 tutti i regex cattureranno tutto, ma ti risparmieranno una seccatura e accetteranno un apostrofo senza generare un avviso.

-
bmb

È possibile proseguire ulteriormente la convalida della posta elettronica per verificare effettivamente l'esistenza di una cassetta postale. Questa tecnica ha i suoi svantaggi (tempo di sviluppo e anche possibilità di essere inserito nella lista nera per uso improprio). http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/

Se si desidera verificare un messaggio di posta elettronica (ovvero assicurarsi che l'utente possieda l'indirizzo di posta elettronica), un messaggio di conferma è l'unica cosa che si può fare. Inoltre, molte persone hanno indirizzi di spam dedicati o usano servizi come OneWayMail e se non vogliono darti il ​​loro vero indirizzo e-mail, non lo faranno. Quindi fondamentalmente stai creando l'ostruzione dell'utente.

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

Per uno, non sarai in grado di riconoscere i refusi nelle "parole" effettive dell'indirizzo e-mail. Non hai modo di scoprire che back2dso@example.comè sbagliato, basato esclusivamente sul formato.
Ancora più importante, dal punto di vista dell'utente, c'è solo uno (o una mano piena) di indirizzi e-mail 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 e-mail ed eliminino quindi la necessità di digitare l'indirizzo e-mail in primo luogo. Naturalmente questo non si applica, se stai costruendo il tipo di sito che potrebbe essere colpito dagli utenti che non hanno mai inserito il loro indirizzo e-mail nel loro browser prima. Ma suppongo che l'ultimo di noi sia in una posizione simile.

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

@ Mike - Penso che parte del motivo per cui vengono inviate e-mail di conferma non sia 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 di una lettera nell'indirizzo di posta elettronica che porterebbe a un indirizzo di posta elettronica diverso e valido, ma sarebbe comunque un errore in quanto sarebbe l' indirizzo sbagliato .

La regex più completa e accurata che abbia mai incontrato per la convalida dell'email è quella documentata qui . Non è per i deboli di cuore; è abbastanza complicato da essere suddiviso in parti per facilitare l'analisi da parte degli umani (il codice di esempio è in Java). Ma nei casi in cui si merita di andare fino in fondo con la convalida, non penso che sia molto meglio.

In ogni caso, suggerirei di utilizzare il test unitario per confermare che la tua espressione copre i casi che ritieni importanti. In questo modo, mentre ci pensi, puoi essere sicuro di non aver rotto un caso che ha funzionato prima.

Qualunque sia la scelta, penso che è necessario sbagliare sul lato di credere che il 99% del tempo, l'utente ha in realtà sa che cosa il loro indirizzo e-mail è. Come qualcuno australiano, trovo ancora occasionalmente una convalida e-mail così intelligente che mi dice che non posso possedere un dominio .com.au. Accadeva molto di più nei primi giorni di Internet, intendiamoci.

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

Su alcuni siti sviluppati in luoghi in cui ho lavorato, abbiamo sempre utilizzato e-mail di conferma. Tuttavia, era sorprendentemente comune per gli utenti digitare in modo errato il loro indirizzo e-mail in modi che non avrebbero potuto funzionare, quindi continuare ad attendere l'e-mail di conferma che non sarebbe arrivata. L'aggiunta di codice ad hoc (o, per la parte del nome di dominio, verifica DNS) per avvisare l'utente in questi casi potrebbe essere una buona idea.

I casi comuni che ho visto:

• Rilasciare una lettera nel mezzo del nome di dominio o diverse altre semplici varianti di errore di battitura.
• Confusione TLD (ad esempio, aggiungendo a .bra un .comdominio o rilasciando .brda un .com.brdominio).
• Aggiungendo www.a all'inizio della parte locale di un indirizzo e-mail (non lo sto inventando; ho visto diversi indirizzi e-mail del modulo www.username@example.com).

Ci furono casi ancora più bizzarri; cose come un nome di dominio completo come parte locale, indirizzi con due @(qualcosa di simile username@domain.tld@example.com) e così via.

Naturalmente, la maggior parte di loro erano ancora indirizzi RFC-822 validi, quindi tecnicamente potevi lasciare che l'MTA li gestisse. Tuttavia, avvisare l'utente che l'indirizzo e-mail inserito è molto probabilmente falso può essere utile, soprattutto se il pubblico di destinazione non è molto esperto di computer.

Tutta la convalida regex nel mondo non impedirà a qualcuno di inserire un indirizzo e-mail errato o falso. È solo fastidioso, davvero.

Dipende dall'obiettivo. Se sei un ISP e devi convalidare che gli utenti stanno creando indirizzi e-mail validi, scegli Regex che convalida con tutto il possibile. Se vuoi solo rilevare errori dell'utente, che ne dici del seguente schema:

[Tutti i caratteri, nessuno spazio] @ [lettere e numeri] (. [Lettere e numeri]) in cui il gruppo finale appare almeno una volta.

Il RegEx per questo apparirebbe qualcosa del genere:

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

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

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

Penso che parte del motivo per cui le e-mail di conferma vengono inviate non sia 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 di una lettera nell'indirizzo di posta elettronica che porterebbe a un indirizzo di posta elettronica diverso e valido, ma sarebbe comunque un errore in quanto sarebbe l'indirizzo sbagliato.

Concordo, ma non sono sicuro che ne valga la pena. Abbiamo anche campi di conferma a tale scopo (ripetendo nuovamente il tuo indirizzo e-mail). Un'altra situazione in cui il tipo di sito potrebbe giustificare approcci diversi.

Inoltre, l'invio di un'e-mail di conferma non fornisce alcun modo per indicare all'utente originale che l'indirizzo inserito è errato. Dopo aver ricevuto l'e-mail di conferma, è possibile che la tua app / il tuo sito siano difettosi; almeno consentendo all'utente di iniziare immediatamente a utilizzare il proprio account, potrebbe correggere il proprio indirizzo e-mail, in particolare se visualizzato in un luogo adeguatamente ovvio.

Cavalli per i corsi.

Tutti questi sono validi e completi sistemi di verifica e-mail in sé e per sé, e per un determinato sito Web uno sarà più appropriato (o buono quanto garantito) rispetto agli altri. In molti casi possono essere utili diversi passaggi di verifica.

Se stai sviluppando un sito Web per una banca, avrai bisogno di una verifica tramite posta ordinaria o telefonica.

Se stai sviluppando un sito Web per un concorso, potresti non volerne nessuno - verifica le email in fase di post-elaborazione e se uno fallisce è troppo male per la persona che l'ha inserito - potresti valutare le prestazioni del server data una grande cotta di persone ( Concorso TV, ad esempio) per assicurarsi che tutti siano validati correttamente in linea.

Fino a che punto si dovrebbe portare la verifica via e-mail?

Per quanto necessario e garantito.

E non oltre (KISS)

Ho visto siti che proteggono anche dalle persone che usano siti bucket di spam temporanei usa e getta come Mailinator o MyTrashMail , che aggirano la questione dell'e-mail di conferma. Non sto dicendo che dovresti filtrare quelli fuori, sto solo dicendo.

Cosa stai cercando di catturare nella tua e-mail di convalida?

La validazione Regex degli indirizzi e-mail può, nella migliore delle ipotesi, verificare che l'indirizzo sia sintatticamente corretto e relativamente plausibile. Ha anche il rischio (come già accennato più volte) di rifiutare eventualmente indirizzi effettivi e consegnabili se il regex non è del tutto corretto.

La verifica SMTP può determinare che l'indirizzo è consegnabile, fatte salve le limitazioni imposte dal greylisting o dai server configurati per fornire il minor numero di informazioni possibile sui propri utenti. Non hai modo di sapere se l'MTA ha solo preteso di accettare la posta per un indirizzo falso, quindi l'ha semplicemente lasciato cadere sul pavimento come parte di una strategia anti-spam.

L'invio di un messaggio di conferma, tuttavia, è l' unico modo per verificare che un indirizzo appartenga all'utente che lo ha inserito. Se sto compilando il modulo, posso facilmente dirti che il mio indirizzo email è president@whitehouse.gov. Una regex ti dirà che è sintatticamente valida, un SMTP RCPT TO ti dirà che è un indirizzo consegnabile, ma sicuramente non è il mio indirizzo.

Con l'avvento dell'HTML5 si aggiunge almeno un nuovo approccio 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 type = text, quindi può essere utilizzato senza problemi anche se ovviamente non hai la convalida.)

Non può mai (come è stato sottolineato più volte) garantire un indirizzo praticabile, ma può essere molto utile (e alla fine sostituire il controllo lato server) in luoghi in cui è necessario solo rilevare probabili errori dell'utente.

I tre livelli principali di convalida dell'email:

1) controllo delle espressioni regolari per un indirizzo email correttamente formattato email@email.com

2) controllo dominio e-mail rispetto ai record MX per vedere se il nome dominio ha un servizio e-mail

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

Livello 1:

In Visual Studio, è possibile utilizzare il "Validatore di espressioni regolari". E nella proprietà "ValidationExpression" puoi fare clic sul pulsante "..." che ha una procedura guidata da aggiungere nel formato delle espressioni regolari per gli indirizzi e-mail.

Livello 2:

Ecco il mio codice C # di seguito per utilizzare nslookup per verificare se un dominio e-mail ha record MX validi. Funziona 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 utilizzare il pacchetto nuget Arsofttools ma potrebbe essere lento su Windows Server 2008 R2 come ho sperimentato ma funziona velocemente su Win 7.

Livello 3:

Per la conferma dell'email, puoi generare un URL esadecimale specifico per l'email (usando le funzioni di crittografia) ecc. Http://domain.com/validateEmail?code=abcd1234 per convalidare l'indirizzo email quando l'utente fa clic su di esso. Non è necessario memorizzare questo URL in memoria.