Eu estou querendo saber até onde as pessoas devem levar a validação do endereço de e-mail. Meu campo é principalmente desenvolvimento da web, mas isso se aplica em qualquer lugar.
Eu já vi algumas abordagens:
Como muitas pessoas podem saber (mas muitas não sabem), os endereços de e-mail podem ter muitas variações estranhas que a maioria das pessoas não costuma considerar (veja RFC 2822 3.4.1 ), mas você tem que pensar sobre os objetivos de sua validação: você está simplesmente tentando garantir que uma mensagem de e-mail possa ser enviada para um endereço , ou que é o que o usuário provavelmente quis colocar (o que é improvável em muitos dos casos mais obscuros de endereços "válidos").
Uma opção que considerei é simplesmente dar um aviso com um endereço mais esotérico, mas ainda permitindo que a solicitação seja concluída, mas isso adiciona mais complexidade a um formulário e a maioria dos usuários provavelmente ficará confusa.
Embora a validação de DNS / validação de SMTP pareça não-brainers, prevejo problemas nos quais o servidor DNS / servidor SMTP está temporariamente inativo e um usuário não pode se registrar em algum lugar, ou o servidor SMTP do usuário não suporta os recursos necessários.
Como alguns desenvolvedores experientes podem lidar com isso? Existem outras abordagens que não as listadas?
Edit: Eu esqueci completamente o mais óbvio de todos, enviando um e-mail de confirmação! Obrigado aos respondentes por apontar aquele. Sim, este é bastante infalível, mas requer mais trabalho por parte de todos os envolvidos. O usuário precisa buscar alguns e-mails, e o desenvolvedor precisa se lembrar dos dados do usuário antes mesmo de serem confirmados como válidos.
Não há uma maneira 100% confiável de confirmar um endereço de e-mail válido além de enviar um e-mail para o usuário e aguardar uma resposta, como a maioria dos fóruns.
Eu usaria a regra de validação simples "@" para enviar um email ao usuário para confirmar seu endereço de e-mail.
Embora, esta seja a minha opinião pessoal ... aguardo outras sugestões.
Uma sugestão: não rejeite endereços com um + neles. É irritantemente comum rejeitá-las, mas é um caractere válido, e os usuários do Gmail podem usar o endereç[email protected] para rotular e classificar os e-mails recebidos com mais facilidade.
Em sua postagem, parece que quando você diz "validação SMTP", você está se conectando ao servidor e tentando um RCPT TO para ver se ele é aceito. Desde que você o diferenciou de realmente enviar um email de confirmação, eu suponho que você queira fazer isso em linha com as ações do usuário. Além de problemas como problemas de rede, falhas de DNS, etc, a listagem cinza pode causar estragos com esse método. O método varia, mas a listagem essencialmente cinza sempre adia a primeira tentativa de entrega ao destinatário por IP de conexão. Como eu disse, isso pode variar, alguns hosts podem rejeitar endereços inválidos na primeira tentativa e só adiar endereços válidos, mas não há maneira confiável de classificar programaticamente as diferentes implementações.
A única maneira de você ter certeza de que um endereço é válido e enviado por seu proprietário, que realmente o quer usado para seu aplicativo, é enviar um e-mail de verificação. Bem, desde que não receba spam filtrado, acho que =).
Outra desvantagem de usar um regex para validação de email é que é quase impossível detectar todos os domínios de nível superior válidos enquanto rejeita todos os inválidos.
Por exemplo, o regex de email básico na resposta de Jeff Atwood:
\b[A-Z0-9._%+-][email protected][A-Z0-9.-]+.[A-Z]{2,4}\b
aceita qualquer TLD de dois a quatro caracteres. Assim, por exemplo, o spam será aceito, mas o .museum e o .travel (ambos os TLDs válidos) serão rejeitados.
Apenas mais um motivo, é melhor procurar pelo @ e enviar um email de confirmação.
Com nomes de domínio internacionais quase tudo é possível:
Se você quiser fazer algum teste, primeiro converta-o em punycode.
Sem punycode, tudo o que você deve fazer é testá-lo:
function isEmail(address) {
var pos = address.lastIndexOf("@");
return pos > 0 && (address.lastIndexOf(".") > pos) && (address.length - pos > 4);
}
Você só precisa verificar coisas simples como @ e. em JavaScript e, em seguida, enviá-los uma verificação para seu email. Se eles confirmarem sua conta, você terá um endereço de e-mail válido. Dessa forma, você tem certeza de que tem um endereço de trabalho e não precisa ser muito mandão no formulário.
Use um validador de código aberto que não forneça falsos negativos. Esforço zero para você e validação robusta para seu aplicativo.
Eu colecionei casos de teste de Cal Henderson, Dave Child, Phil Haack, Doug Lovell e RFC 3696. 158 endereços de teste no total.
Eu executei todos esses testes contra todos os validadores que consegui encontrar. A comparação está aqui: link
Vou tentar manter esta página atualizada à medida que as pessoas aprimoram seus validadores. Obrigado a Cal, Dave e Phil por sua ajuda e cooperação na compilação desses testes e críticas construtivas de
As pessoas devem estar cientes da errata contra a RFC 3696 em particular. Três dos exemplos canônicos são, na verdade, endereços inválidos. E o comprimento máximo de um endereço é 254 ou 256 caracteres, não 320.
Considerando as respostas (já que me esqueci completamente dos e-mails de confirmação), parece-me que um compromisso adequado para uma solução de baixo atrito seria:
RegexBuddy oferece as seguintes expressões regulares relacionadas a e-mail em sua biblioteca:
Endereço de e-mail (básico)
\b[A-Z0-9._%+-][email protected][A-Z0-9.-]+\.[A-Z]{2,4}\b
Endereço de e-mail (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])?
Mas eu costumo concordar com as respostas de Peter e SuperJoe; o único "teste" real está realmente enviando um email de validação.
Eu trabalhei em 4 empresas diferentes, onde alguém no help desk foi gritado por alguém chamado O'Malley ou O'Brien ou algum outro endereço de e-mail com um apóstrofo. Como sugerido anteriormente, nem todos os regexs vão capturar tudo, mas poupe algum incômodo e aceite um apóstrofo sem gerar um aviso.
-
bmb
Se você quiser verificar um e-mail (ou seja, se o usuário possui o endereço de e-mail), um e-mail de confirmação é a única coisa que você pode fazer. Então, novamente, muitas pessoas têm endereços de spam dedicados ou usam serviços como o OneWayMail e, se não quiserem fornecer seu endereço de e-mail real, eles não vão. Então basicamente você está criando obstrução ao usuário.
Quando se trata de validação , para garantir que o usuário não involuntariamente introduzir um endereço de e-mail errado, é definitivamente a motivação certa. No entanto, pelo menos para formulários HTML (que são de longe a maneira mais comum de reunir endereços de e-mail), dificilmente é o instrumento certo.
Por exemplo, você não poderá reconhecer erros de digitação nas "palavras" reais do endereço de e-mail. Você não tem como descobrir que [email protected] está errado, baseado apenas no formato.
Mas, mais importante, do ponto de vista do usuário, há apenas um (ou uma mão cheia) de endereços de e-mail que você poderia querer inserir. E você provavelmente já entrou nele.
Portanto, em vez de tentar validar um endereço, você deve se concentrar em garantir que todos os navegadores reconheçam o campo de email e, assim, eliminem a necessidade de digitar o endereço de email em primeiro lugar. É claro que isso não se aplica, se você estiver criando o tipo de site que provavelmente será atingido por usuários que nunca inseriram o endereço de e-mail no navegador antes. Mas suponho que o menor de nós esteja em tal posição.
Acho que depende do contexto para o qual você está usando o e-mail. Projetos mais sérios exigem uma validação mais rigorosa, mas acho que, para a maioria das coisas, enviar um e-mail para o endereço fornecido com um link de conformação garantirá que o endereço de e-mail seja válido.
@ Mike - eu acho essa parte do motivo pelo qual os emails de confirmação são enviados não é apenas para garantir que o endereço de email seja válido, mas que seja acessível pelo usuário que o enviou. Uma pessoa poderia facilmente inserir um erro de digitação de uma letra no endereço de e-mail que levaria a um endereço de e-mail diferente e válido, mas isso ainda seria um erro, pois seria o endereço errado .
O regex mais completo e preciso que já encontrei para a validação de e-mail é o aqui documentado. Não é para os fracos do coração; é complicado o suficiente para ser dividido em partes para tornar mais fácil para os humanos analisarem (código de amostra está em Java). Mas nos casos em que vale a pena validar, não acho que fique muito melhor.
De qualquer forma, sugiro que você use o teste de unidade para confirmar que sua expressão abrange os casos que considera importantes. Dessa forma, enquanto você se diverte com isso, pode ter certeza de que não quebrou nenhum caso que funcionou antes.
O que você escolher, eu acho que você precisa errar do lado de acreditar que 99% do tempo, o usuário faz realmente sabe qual é o endereço de e-mail deles. Como alguém da Austrália, eu ainda acho muito ocasionalmente uma validação de e-mail tão inteligente que me diz que eu não posso ter um domínio .com.au. Costumava acontecer muito mais nos primeiros dias da internet.
Enviar um e-mail de confirmação nos dias de hoje é aceitável para os usuários e também é útil em termos de ativação e validação do endereço fornecido.
Em alguns sites desenvolvidos em locais onde trabalhei, sempre usamos e-mails de confirmação. No entanto, era surpreendentemente comum os usuários digitarem incorretamente o endereço de e-mail de maneiras que não poderiam ter funcionado, e continuar aguardando o e-mail de confirmação que não viria. Adicionar código ad-hoc (ou, para a parte do nome de domínio, verificação do DNS) para avisar o usuário nesses casos pode ser uma boa ideia.
Os casos comuns que tenho visto:
.br a um .com ou perdendo o .br de um domínio .com.br ). www. no início da parte local de um endereço de e-mail (não estou fazendo isso; vi vários endereços de e-mail do formulário [email protected] ). Houve casos ainda mais bizarros; coisas como um completo nome de domínio como a parte local, endereços com dois @ (algo como [email protected]@example.com ) e assim por diante.
É claro que a maioria deles ainda eram endereços RFC-822 válidos, então tecnicamente você poderia simplesmente deixar o MTA lidar com eles. No entanto, alertar o usuário de que o endereço de e-mail digitado é possivelmente falso pode ser útil, especialmente se seu público-alvo não for muito competente em informática.
Toda a validação de regex no mundo não impedirá que alguém insira um endereço de e-mail incorreto ou falso. É realmente irritante.
Depende do objetivo. Se você é um ISP e precisa validar que os usuários estão criando endereços de e-mail válidos, vá para o Regex que valida contra todo o possível. Se você quiser apenas capturar erros do usuário, que tal o seguinte padrão:
[Todos os Caracteres, sem espaços] @ [letras e números] (. [letras e números]) onde o grupo final aparece pelo menos uma vez.
O RegEx para isso seria algo assim:
[\S][email protected][\w]+(.[\w-]+)+
Envie um e-mail de confirmação para confirmar.
@ Yaakov (poderia responder fazer com algum tipo de 'responder' aqui)
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.
Concordo, mas não tenho certeza se vale a pena. Também temos campos de confirmação para esse propósito (repetindo seu endereço de e-mail novamente). Outra situação em que o tipo de site pode justificar abordagens diferentes.
Além disso, o envio de um email de confirmação em si não fornece nenhuma indicação ao usuário original de que o endereço digitado estava errado. Depois de não receber o e-mail de confirmação, eles podem simplesmente assumir que seu aplicativo / site está com defeito; pelo menos permitindo que o usuário comece a usar sua conta imediatamente, eles poderiam corrigir seu endereço de e-mail, especialmente se ele for exibido em um local adequadamente óbvio.
Cavalos para os cursos.
Todos esses são sistemas de verificação de e-mail completos e válidos por si mesmos e, para um determinado site, um deles será mais apropriado (ou tão bom quanto for garantido) do que os outros. Em muitos casos, várias etapas de verificação podem ser úteis.
Se você está desenvolvendo um site para um banco, vai querer snail mail ou verificação por telefone além de tudo isso.
Se você estiver desenvolvendo um site para um concurso, talvez não deseje nenhum deles - verifique os e-mails no pós-processamento e, se um deles falhar, é muito ruim para a pessoa que o inseriu. de pessoas (concurso de TV, por exemplo) para garantir que todos sejam validados corretamente em linha.
E não mais (KISS)
Já vi sites que também protegem contra pessoas que usam sites remotos temporários de spam, como Mailinator ou MyTrashMail , que contorna a mensagem de e-mail de confirmação. Eu não estou dizendo que você deveria estar filtrando isso, estou apenas dizendo.
O que você está tentando pegar na validação do seu email?
A validação regular de endereços de e-mail pode, na melhor das hipóteses, verificar se o endereço está sintaticamente correto e relativamente plausível. Ele também tem o risco (como já foi mencionado várias vezes) de possivelmente rejeitar endereços reais, se o regex não estiver correto.
A verificação de SMTP pode determinar que o endereço seja entregue, sujeito às limitações impostas pela lista cinza ou servidores configurados para fornecer o mínimo de informações possível sobre seus usuários. Você não tem como saber se o MTA apenas reivindicou o recebimento de um endereço falso e, em seguida, apenas o deixou no pregão como parte de uma estratégia anti-spam.
Enviar uma mensagem de confirmação, no entanto, é a maneira única de verificar se um endereço pertence ao usuário que o inseriu. Se eu estiver preenchendo seu formulário, posso facilmente informar que meu endereço de e-mail é [email protected] . Um regex dirá que é sintaticamente válido, um SMTP RCPT TO informará que é um endereço de entrega, mas com certeza não é o endereço meu .
Com a chegada do HTML5, pelo menos, uma nova abordagem é adicionada às possibilidades: o uso da entrada do tipo ' e-mail ', que permite validação no lado do cliente. As versões atuais do Firefox, Chrome, Safari e Opera suportam isso (e outros navegadores apenas o tratam como type = text, então ele pode ser usado sem problemas, embora você não tenha validação, é claro).
Ele nunca pode (como é apontado algumas vezes) garantir um endereço viável, mas pode ser muito benéfico (e eventualmente substituir a verificação do lado do servidor) em lugares onde você só precisa pegar erros prováveis do usuário.
Os três principais níveis de validação de email:
1) verificação de expressão regular para um endereço de e-mail devidamente formatado [email protected]
2) verificar o domínio de e-mail em registros MX para ver se o nome do domínio tem um serviço de e-mail
3) enviando um email de confirmação com um link ou código de confirmação
Nível 1:
No Visual Studio, você pode usar o "Validador de expressões regulares". E na propriedade "ValidationExpression", você pode clicar no botão "..." que tem um assistente para adicionar no formato de expressão regular para endereços de e-mail.
Nível 2:
Aqui está o meu código c # abaixo para usar o nslookup para verificar se um domínio de e-mail tem registros MX válidos. Funciona rápido e bem no Win 2008 R2 e no 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
outra opção é usar o pacote nuget do Arsofttools, mas pode ser lento no Windows Server 2008 R2, como eu experimentei, mas é executado rapidamente no Win 7.
Nível 3:
Para confirmação por e-mail, você pode gerar uma URL hexadecimal específica por e-mail (usando funções de criptografia) etc. link para validar a endereço de e-mail quando o usuário clica nele. Não há necessidade de armazenar este URL na memória.