Gostaria de saber até que ponto as pessoas devem levar a validação do endereço de email. Meu campo é principalmente de desenvolvimento web, mas isso se aplica a qualquer lugar.

Eu já vi algumas abordagens:

• basta verificar se existe um presente "@", que é simples, mas é claro que não é tão confiável.
• um teste regex mais complexo para formatos de email padrão
• um regex completo contra a RFC 2822 - o problema é que geralmente um endereço de email pode ser válido, mas provavelmente não é o que o usuário quis dizer
• Validação de DNS
• Validação SMTP

Como muitas pessoas sabem (mas muitas não sabem), os endereços de email podem ter muitas variações estranhas que a maioria das pessoas geralmente não considera (consulte a RFC 2822 3.4.1 ), mas é preciso pensar nos 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 é isso que o usuário provavelmente deseja inserir (o que é improvável em muitos dos casos mais obscuros de outras formas 'válidas 'endereços).

Uma opção que considerei é simplesmente dar um aviso com um endereço mais esotérico, mas ainda permitir a solicitação, mas isso adiciona mais complexidade a um formulário e a maioria dos usuários provavelmente fica confusa.

Embora a validação de DNS / validação de SMTP pareça óbvia, prevejo problemas em que o servidor DNS / servidor SMTP está temporariamente inativo e um usuário não consegue se registrar em algum lugar ou o servidor SMTP do usuário não suporta os recursos necessários.

Como alguns desenvolvedores experientes aqui podem lidar com isso? Existem outras abordagens além das listadas?

Edit: Eu esqueci completamente o mais óbvio de todos, enviando um e-mail de confirmação! Agradecemos aos respondentes por apontarem essa questão. Sim, este é bastante infalível, mas requer aborrecimentos extras por parte de todos os envolvidos. O usuário precisa buscar alguns emails e o desenvolvedor precisa se lembrar dos dados do usuário antes que eles sejam confirmados como válidos.

Não há uma maneira 100% confiável de confirmar um endereço de email válido além de enviar um email ao usuário e aguardar uma resposta, como a maioria dos fóruns.

Eu seguia a regra de validação "@" simples e enviava um email ao usuário para confirmar o endereço de email.

Embora essa seja minha opinião pessoal ... aguardo outras sugestões.

Uma sugestão: não rejeite endereços com um + neles. É irritantemente comum rejeitá-los, mas é um caractere válido, e os usuários do gmail podem usar address+label@gmail.com para rotular e classificar os e-mails recebidos com mais facilidade.

No seu post, parece que quando você diz "Validação SMTP", você quer dizer conectar-se ao servidor e tentar um RCPT TO para ver se ele é aceito. Como você o diferencia de realmente enviar um e-mail de confirmação, presumo que você queira fazê-lo em linha com as ações do usuário. Além de problemas como problemas de rede, falhas de DNS etc., a listagem em cinza pode causar estragos nesse método. A lista de métodos varia, mas 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 adiar apenas endereços válidos, mas não há uma maneira confiável de classificar as diferentes implementações programaticamente.

A única maneira de garantir que um endereço seja válido e enviado pelo proprietário que realmente deseja que ele seja usado para o seu aplicativo é enviar um email de verificação. Bem, desde que não seja spam filtrado, eu acho =).

Outro ponto fraco do uso de um regex para validação de email é que é quase impossível capturar todos os domínios de nível superior válidos enquanto rejeita todos os domínios inválidos.

Por exemplo, o regex básico de email na resposta de Jeff Atwood:

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

aceitará qualquer TLD de dois a quatro caracteres. Assim, por exemplo, .spam serão aceitos, mas .museum e .travel (ambos os TLDs válidos) serão rejeitados.

Apenas mais um motivo, é melhor procurar o @ e enviar um email de confirmação.

Com nomes de domínio internacionais, quase tudo é possível:

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

Se você quiser fazer algum teste, primeiro converta-o para punycode.

Sem o punycode, tudo o que você deve fazer é testar se existe:

• é pelo menos um @
• tem pelo menos um caractere na parte local
• é pelo menos um ponto na parte do domínio
• tem pelo menos quatro caracteres no domínio (supondo que ninguém tenha um endereço no tld, que o tld tenha pelo menos 2 caracteres)

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

É melhor verificar apenas coisas simples como @ e. em JavaScript e, em seguida, envie uma verificação para o e-mail deles. Se eles verificarem sua conta, você terá um endereço de email válido. Dessa forma, você tem certeza de que possui 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 dê falsos negativos. Esforço zero para você e validação robusta para seu aplicativo.

Agora colei casos de teste de Cal Henderson, Dave Child, Phil Haack, Doug Lovell e RFC 3696. 158 endereços de teste ao todo.

Eu executei todos esses testes contra todos os validadores que pude encontrar. A comparação está aqui: http://www.dominicsayers.com/isemail

Vou tentar manter esta página atualizada à medida que as pessoas aprimoram seus validadores. Agradeço a Cal, Dave e Phil por sua ajuda e cooperação na compilação desses testes e críticas construtivas do meu próprio validador .

As pessoas devem estar cientes da errata contra a RFC 3696 em particular. Três dos exemplos canônicos são de fato endereços inválidos. E o tamanho máximo de um endereço é 254 ou 256 caracteres, não 320.

Considerando as respostas (desde que me esqueci completamente dos e-mails de confirmação), parece-me que um compromisso adequado para uma solução de baixo atrito seria:

1. Use regex para verificar se o endereço de email parece válido e dê um aviso se for mais obscuro, mas evite rejeitar completamente.
2. Use a validação SMTP para garantir que o endereço de email seja válido.
3. Se a validação do SMTP falhar, então - e somente então - use um email de confirmação como último recurso. Os e-mails de confirmação parecem exigir muita interação fora do aplicativo para que sejam considerados de baixo atrito, mas são um substituto perfeito.

RegexBuddy oferece as seguintes expressões regulares relacionadas a email de sua biblioteca:

Endereço de email (básico)

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

Endereço de email (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 tendem a concordar com as respostas de Peter e SuperJoe; o único "teste" real é realmente enviar um email de validação.

Já trabalhei em 4 empresas diferentes, nas quais alguém na central de atendimento 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 capturam tudo, mas economize algum aborrecimento e aceite um apóstrofo sem gerar um aviso.

-
bmb

Você pode levar a validação de email ainda mais para testar se existe uma caixa de correio. Essa técnica tem suas desvantagens (tempo de desenvolvimento e também possibilidade de entrar na lista negra por uso indevido). http://www.webdigi.co.uk/blog/2009/how-to-check-if-an-email-address-exists-without-sending-an-email/

Se você deseja verificar um email (ou seja, garantir que o usuário seja o proprietário do endereço de email), um email de confirmação é a única coisa que você pode fazer. Por outro lado, 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, não o farão. Então, basicamente, você está criando obstrução do usuário.

Quando se trata de validação , para garantir que o usuário não insira um endereço de e-mail errado sem querer, é 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 email), dificilmente é o instrumento certo.

Por um lado, você não poderá reconhecer erros de digitação nas "palavras" reais do endereço de email. Você não tem como descobrir o que back2dso@example.comé errado, apenas com base no formato.
Mais importante, porém, do ponto de vista do usuário, há apenas um (ou um total de endereços) de email que você pode querer inserir. E você provavelmente já entrou nele.
Portanto, em vez de tentar validar um endereço, você deve se certificar de 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 nessa posição.

Acho que depende do contexto em que você está usando o email. Projetos mais sérios exigem validação mais rígida, mas acho que, na maioria das vezes, o envio de um email para o endereço fornecido com um link de conformação garantirá que o endereço de email seja válido.

@ Mike - Eu acho que parte do motivo pelo qual os e-mails de confirmação são enviados não é apenas para garantir que o endereço de e-mail seja válido, mas que ele 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 email que levaria a um endereço de email válido diferente, mas isso ainda seria um erro, pois seria o endereço errado .

O regex mais completo e preciso que eu já encontrei para validação de email é o documentado aqui . Não é para os fracos do coração; é bastante complicado que seja dividido em partes para facilitar a análise dos seres humanos (o código de exemplo está em Java). Mas nos casos em que é necessário dar todo o caminho na validação, não acho que fique muito melhor.

De qualquer forma, sugiro que você use o teste de unidade para confirmar que sua expressão cobre os casos que você considera importantes. Dessa forma, conforme você se diverte, pode ter certeza de que não quebrou um caso que funcionava antes.

Tudo o que você escolher, eu acho que você precisa errar no lado de acreditar que 99% do tempo, o usuário não realmente sabe o seu endereço de e-mail é. Como alguém da Austrália, ainda encontro muito ocasionalmente uma validação de e-mail tão inteligente que me diz que não posso ter um domínio .com.au. Isso costumava acontecer muito mais nos primeiros dias da internet.

Atualmente, o envio de um e-mail de confirmação é aceitável para os usuários e também é útil em termos de aceitação, além de validar o endereço fornecido.

Em alguns sites desenvolvidos nos locais em que trabalhei, sempre usamos e-mails de confirmação. No entanto, era surpreendentemente comum que os usuários digitassem incorretamente seu endereço de email de maneiras que não poderiam ter funcionado e continuem aguardando o email de confirmação que não chegaria. Adicionar código ad-hoc (ou, na parte do nome de domínio, verificação DNS) para avisar o usuário nesses casos pode ser uma boa ideia.

Os casos comuns que eu já vi:

• Soltar uma letra no meio do nome do domínio ou várias outras variantes simples de erros de digitação.
• Confusão de TLDs (por exemplo, adicionando um .bra um .comdomínio ou eliminando-o .brde um .com.brdomínio).
• Adicionando um www.no início da parte local de um endereço de email (não estou inventando isso; vi vários endereços de email do formulário www.username@example.com).

Houve casos ainda mais bizarros; coisas como um nome de domínio completo como a parte local, endereços com dois @(algo como username@domain.tld@example.com) e assim por diante.

Obviamente, a maioria deles ainda eram endereços RFC-822 válidos; portanto, tecnicamente, você podia 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 o seu público-alvo não tiver conhecimentos de informática.

Toda a validação de regex no mundo não impedirá que alguém digite um endereço de email incorreto ou falso. É apenas irritante, realmente.

Depende do objetivo. Se você é um ISP e precisa validar se os usuários estão criando endereços de email válidos, vá para o Regex que valida com todo o possível. Se você deseja apenas detectar 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 parecido com isto:

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

E, em seguida, envie um email de confirmação para ter certeza.

@ Yaakov (poderia responder com algum tipo de 'resposta' aqui)

Penso que parte da razão pela 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 ele 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 email que levaria a um endereço de email válido diferente, mas isso ainda seria um erro, pois seria o endereço errado.

Concordo, mas não tenho certeza se vale a pena. Também temos campos de confirmação para esse fim (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 e-mail de confirmação não indica o 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 inicie imediatamente o uso de sua conta, ele pode corrigir seu endereço de email, principalmente se ele for exibido em um local adequadamente óbvio.

Cavalos para cursos.

Todos eles são válidos, sistemas completos de verificação de e-mail por si só e, para um determinado site, um será mais apropriado (ou tão bom quanto o necessário) do que os outros. Em muitos casos, várias etapas de verificação podem ser úteis.

Se você estiver desenvolvendo um site para um banco, precisará de verificação de correio tradicional ou telefone por cima disso.

Se você estiver desenvolvendo um site para um concurso, talvez não queira nenhum deles - verifique os e-mails no pós-processamento e, se um deles falhar, é muito ruim para a pessoa que o inseriu - você pode valorizar o desempenho do servidor, devido a uma enorme queda de pessoas ( Concurso de TV, por exemplo), certificando-se de que todos sejam validados corretamente em linha.

Até que ponto devemos levar a verificação por email?

Na medida do necessário e garantido.

E não mais (KISS)

Vi sites que também se protegem contra pessoas que usam sites de depósito de spam descartáveis ​​temporários, como o Mailinator ou o MyTrashMail , que contornam o e-mail de confirmação. Não estou dizendo que você deveria filtrar isso, estou apenas dizendo.

O que você está tentando entender na validação de seu email?

A validação regular de endereços de email 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á mencionado várias vezes) de possivelmente rejeitar endereços reais e entregáveis, se o regex não estiver totalmente correto.

A verificação SMTP pode determinar que o endereço é entregável, sujeito às limitações impostas pela lista de espera 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 reivindicou apenas aceitar e-mails para um endereço falso e depois o soltou no chão como parte de uma estratégia anti-spam.

Enviar uma mensagem de confirmação, no entanto, é a única maneira de verificar se um endereço pertence ao usuário que o inseriu. Se estou preenchendo seu formulário, posso dizer com facilidade que meu endereço de e-mail é president@whitehouse.gov. Um regex dirá que é sintaticamente válido, um SMTP RCPT TO dirá que é um endereço de entrega, mas com certeza não é o meu endereço.

Com a chegada do HTML5, pelo menos uma nova abordagem é adicionada às possibilidades: o uso da entrada do tipo ' email ' que permite a 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, para que possa ser usado sem problemas, desde que você não tenha validação, é claro).

Ele nunca (como indicado algumas vezes) garante um endereço viável, mas pode ser muito benéfico (e eventualmente substituir a verificação do lado do servidor) em locais onde você só precisa detectar os erros prováveis ​​do usuário.

Os três níveis principais de validação de email:

1) verificação de expressão regular para um endereço de email formatado corretamente email@email.com

2) verificação de domínio de email nos registros MX para ver se o nome de domínio possui um serviço de email

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ão regular". E na propriedade "ValidationExpression", você pode clicar no botão "..." que possui um assistente para adicionar no formato de expressão regular para endereços de email.

Nível 2:

Aqui está meu código C # abaixo para usar o nslookup para verificar se um domínio de email tem registros MX válidos. Executa rápido e ok no 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

outra opção é usar o pacote de nuget do Arsofttools, mas pode ser lento no Windows Server 2008 R2, como experimentei, mas roda rapidamente no Win 7.

Nível 3:

Para confirmação por email, você pode gerar um URL hexadecimal específico para email (usando funções de criptografia) etc http://domain.com/validateEmail?code=abcd1234 para validar o endereço de email quando o usuário clicar nele. Não há necessidade de armazenar esse URL na memória.