Validador de email

O que é um validador de email?

Um validador de email responde se uma cadeia está bem formada como endereço de correio eletrónico. Os formulários de registo usam um para apanhar gralhas antes que custem uma reposição de palavra-passe, as listas de distribuição para manter os devolvidos em baixo, e quem programa recorre a um quando uma expressão regular copiada da internet começou a rejeitar um cliente cujo endereço é perfeitamente legal.

O senão é que não há uma resposta única, e são as próprias especificações a dizê-lo. A norma HTML define o que um campo <input type=email> aceita e descreve a sua própria definição, nestes termos, como «uma violação deliberada do RFC 5322» — a norma da internet para o formato das mensagens. Dá três razões: o RFC 5322 é demasiado estrito antes da arroba, demasiado vago depois dela e demasiado permissivo ao aceitar comentários, espaços e cadeias entre aspas que deixariam quase toda a gente perplexa.

As três queixas confirmam-se quando se vai verificar, e a consequência é aquilo que esta página existe para mostrar: nenhuma das normas contém a outra. Cada uma aceita endereços que a outra rejeita. Por isso esta ferramenta dá os dois veredictos lado a lado e nomeia a regra que decidiu.

Como usar

1. Cole os seus endereços, um por linha. Serve um só e serve uma lista de milhares. As linhas em branco são saltadas em vez de contadas como falhas, e os espaços à volta são cortados, portanto colar uma coluna de uma folha de cálculo faz o que espera.
2. Leia as duas etiquetas de cada linha. Uma é a regra dos formulários HTML, a que decide se o navegador deixa submeter o campo. A outra é o RFC 5322, a que uma biblioteca de correio implementa. Quando discordam, a linha fica assinalada, porque é esse o caso que vale a pena conhecer.
3. Leia o motivo por baixo. Seja qual for a norma que rejeitou o endereço, a linha de baixo diz que regra o fez: um ponto no sítio errado, uma parte local entre aspas, um comentário entre parênteses, um hífen na berma de uma etiqueta de domínio. Um veredicto sem motivo não serve de muito quando é preciso decidir se se arranja o endereço ou o validador.

Onde as duas normas se separam

Três endereços de aspeto banal são válidos para a regra HTML e inválidos para o RFC 5322, e os três têm que ver com pontos. O RFC 5322 constrói a parte anterior à arroba com um «dot-atom» — pedaços de texto ligados por pontos isolados — pelo que um ponto duplo, um inicial ou um final quebram a gramática. O padrão do HTML permite simplesmente pontos em qualquer sítio dessa sequência, portanto john..doe@example.com passa num formulário do navegador e falha num analisador estrito.

Bastantes mais vão no sentido oposto. O RFC 5322 deixa que a parte anterior à arroba seja uma cadeia entre aspas, portanto "john..doe"@example.com é legal: as aspas transformam os pontos em dados e não em estrutura. Admite comentários entre parênteses em quase qualquer posição, pelo que john.doe(comment)@example.com é analisado sem problema. Permite que o domínio seja um endereço literal entre parênteses retos, tanto user@[192.168.0.1] como a forma IPv6. E a sua gramática de domínio não tem regra nenhuma sobre as etiquetas, que é ao que a norma HTML chama «demasiado vago»: user@-example.com e uma etiqueta de domínio com 64 caracteres são sintaticamente corretos para o RFC 5322 e ambos rejeitados pelo navegador.

A leitura prática é que a regra do HTML é um compromisso deliberado e não um erro. É mais estreita onde o RFC é permissivo com coisas que ninguém escreve, e mais larga onde o RFC é esquisito com coisas que as pessoas escrevem mesmo. Se está a validar um campo de formulário, imitar o navegador é normalmente o mais acertado. Se está a escrever um analisador de correio, não é.

Limites honestos

Nenhuma das colunas diz se o correio chegaria de facto. Essa é uma terceira pergunta inteira — se o domínio existe, se tem servidor de correio, se a caixa existe, se aceitará a mensagem — e exige consultas de DNS e uma conversa SMTP. Uma página a correr no seu navegador não consegue fazer nada disso, portanto esta ferramenta não finge que consegue. Quem afirme verificar a entrega sem enviar uma mensagem ou está a adivinhar a partir de uma lista de domínios conhecidos ou está a fazer o trabalho num servidor a que está a entregar a sua lista.

Os limites de comprimento vale a pena conhecê-los e são mais estranhos do que parecem. O RFC 5321 limita a parte anterior à arroba a 64 octetos e o domínio a 255. Os 254 caracteres totais que toda a biblioteca de validação usa não constam do corpo de nenhum RFC: vêm de uma errata verificada contra o RFC 3696 que os deduz do limite de 256 octetos de um forward-path, menos os dois sinais que um caminho é obrigado a ter à volta do endereço. Uma errata anterior dizia 256 e foi corrigida exatamente nesses dois caracteres. Siga a aritmética mais um passo e sai algo curioso: 64 mais um mais 255 dá 320, bem acima de 254, portanto os dois máximos parciais nunca podem ser atingidos ao mesmo tempo num endereço real.

Aqui os comprimentos contam-se em octetos e não em caracteres, porque é isso que o RFC diz. Para um endereço ASCII banal são o mesmo número, mas um caractere acentuado ocupa dois bytes e um emoji quatro, portanto um endereço de aspeto curto pode ser mais comprido na rede do que parece no ecrã.

As duas normas implementadas aqui são só ASCII, e isso é uma limitação real e não um descuido. Os endereços internacionalizados — com caracteres fora do ASCII antes ou depois da arroba — são definidos por especificações posteriores, e o suporte entre programas de correio é suficientemente desigual para que dá-los por válidos sem mais fosse outra forma de mentir. Quando aparece um, a ferramenta diz que caractere o causou em vez de falhar em silêncio.

Uma coisa que esta ferramenta não faz de propósito é adivinhar gralhas. Sugerir que gmial.com queria ser gmail.com exige uma lista de fornecedores populares, e uma lista dessas é uma fotografia que envelhece sem avisar e acaba a corrigir quem usa mesmo um domínio mais pequeno.

Porque é grátis

Porque não custa nada manter. As duas normas estão implementadas no seu navegador, portanto os endereços que cola não saem da sua máquina — o que aqui importa mais do que em quase qualquer outra página, já que uma lista de correio é precisamente aquilo que não se deve enviar para o servidor de um desconhecido para ser verificado.

Não há conta, não há limite de quantos endereços pode verificar de uma vez e não há nada guardado atrás de um plano pago. A implementação é confrontada com um analisador real de RFC 5322 em vez de expectativas escritas à mão, e com a própria expressão regular publicada pela norma HTML, portanto os veredictos desta página são dos que se conseguem defender.