Formato de endereço de e-mail: limites que a maioria ignora

Existe uma diferença incômoda entre o formato de endereço de e-mail definido em padrões públicos e o que os formulários do mundo real realmente aceitam. Quem escreve um validador com pressa acaba recusando endereços legítimos, e quem escreve um validador permissivo demais aceita coisas que nenhum provedor entrega. Este texto percorre as duas metades de um endereço, os limites que constam nos documentos públicos e as razões pelas quais a prática do mercado é mais estreita.

As duas metades de um endereço

Todo endereço é dividido em dois por um único sinal de arroba. A parte da esquerda é a local, e costuma identificar a pessoa dentro do domínio. A parte da direita é o domínio, e aponta para o sistema que recebe mensagens. Entender essa divisão resolve boa parte das dúvidas de validação, porque as regras de cada metade são diferentes.

A parte local é, do ponto de vista do padrão, bem mais livre do que a maioria imagina. Ela admite caracteres que quase nunca aparecem no dia a dia e até formas com aspas que permitem espaços. Já o domínio segue as regras de nomes de domínio da internet, com uma sequência de rótulos separados por pontos.

Quais são os limites definidos em padrões públicos?

Os documentos públicos de padronização da internet estabelecem três limites, e vale conhecê-los pelo que são: limites do padrão, não garantias de que um serviço os aceite.

Esses números aparecem nas especificações que descrevem a mensagem de correio e o formato do endereço. Eles são o teto teórico do sistema, e não a régua que os formulários usam na prática.

Existe uma segunda diferença que confunde muita gente. O limite é medido em bytes, e um caractere acentuado ou de outro alfabeto pode ocupar mais de um byte. Uma sequência de trinta caracteres pode, portanto, ser bem mais longa do que trinta bytes. Isso importa para quem escreve código que valida o comprimento.

O que o padrão permite e a maioria recusa

A lista abaixo reúne construções que o padrão admite e que a maioria dos serviços reais não aceita. Nenhuma delas é uma recomendação de uso; elas importam porque aparecem em testes de formulário e em discussões sobre validação.

• Parte local entre aspas. O padrão permite delimitar a parte local com aspas, o que viabiliza espaços e sinais que de outra forma seriam especiais. Praticamente nenhum formulário aceita isso.
• Comentários entre parênteses. A sintaxe original admite anotações que seriam ignoradas no endereço. Elas são irrelevantes na prática e alguns validadores as rejeitam ou as confundem com lixo.
• Domínio escrito como endereço de rede. O padrão admite indicar o destino por um endereço numérico de rede entre colchetes. Quase nenhum serviço aceita essa forma.
• Caracteres não latinos. Uma extensão de internacionalização permite letras acentuadas e alfabetos não latinos nos dois lados. O suporte varia bastante, e a forma de representação também pode mudar no caminho.
• Maiúsculas e minúsculas. O padrão trata a parte do domínio sem distinção de caixa, enquanto a parte local é, em tese, sensível. Na prática, quase todo provedor trata as duas como equivalentes.

A conclusão prática é direta: ser sintaticamente válido pelos padrões não significa ser aceito por um serviço específico. Nunca vale afirmar que um provedor aceita ou recusa uma dessas formas sem testar aquele provedor.

Por que validar demais é um defeito?

Um validador restritivo parece uma boa ideia até o dia em que recusa a pessoa certa. Endereços reais contêm pontos, hífens, sinais de soma e sublinhados, e expressões regulares escritas de memória costumam rejeitar pelo menos uma dessas combinações.

O custo é assimétrico. Aceitar um endereço inválido gera uma mensagem que não chega e um usuário que percebe o erro em segundos. Recusar um endereço válido gera um usuário que não consegue concluir o cadastro e não tem como saber por quê, porque a mensagem de erro raramente explica. O segundo caso é pior.

Há também o efeito sobre endereços internacionais. Um formulário que aceita apenas letras sem acento exclui pessoas cujo endereço legítimo usa caracteres acentuados. O Brasil é um bom exemplo: provedores e domínios com caracteres acentuados existem, e um campo apertado demais simplesmente não os aceita. Se o seu público inclui o mercado brasileiro, vale conferir como o formulário se comporta — a página sobre dados do Brasil reúne o contexto do país.

Testando o seu próprio formulário

A verificação começa por uma lista de endereços que devem ser aceitos: os comuns, os com ponto antes do sinal de arroba, os com sinal de soma, os longos mas dentro do limite, os com maiúsculas e minúsculas misturadas e os com caracteres acentuados.

Depois vem a lista dos que devem ser recusados, mas com um cuidado: o que exatamente deve ser recusado depende do seu produto, não do padrão. Um endereço sem o sinal de arroba, com dois sinais ou com um domínio vazio são recusas óbvias. As construções exóticas que o padrão permite são uma decisão de produto, e a escolha precisa estar escrita em algum lugar.

Por fim, teste o comportamento da interface. Um campo que corta o texto colado, que converte para minúsculas sem avisar ou que apaga espaços no meio é uma fonte de defeito que nenhum teste de servidor detecta.

Para quem desenvolve: campos, normalização e endereços internacionais

O primeiro cuidado é o limite do campo. Ajuste o comprimento armazenado ao teto do padrão mais uma margem, e valide o comprimento em bytes, não em caracteres, quando o campo aceitar texto internacional. Um campo curto demais trunca o endereço em silêncio, e a mensagem passa a ir para outro lugar ou para lugar nenhum.

O segundo é a normalização. Remover espaços nas pontas e uniformizar a caixa do domínio são operações seguras. Uniformizar a caixa da parte local é uma suposição: funciona na maioria dos provedores, mas não é garantida pelo padrão. Se você fizer isso, registre a decisão.

O terceiro é a forma de armazenar endereços internacionais. Existem duas representações possíveis, e a conversão entre elas precisa ser consistente. Guardar a forma exibida em um campo e a forma de transporte em outro evita comparações que falham por causa de uma letra acentuada.

O quarto é não confundir validação de formato com confirmação de existência. Nenhum validador de formulário sabe se um endereço realmente recebe mensagens. A única forma de saber é enviar uma e ver se a pessoa responde — e é exatamente para isso que existe a etapa de confirmação.

Por último, lembre do limite de uso: nenhuma das construções discutidas aqui deve ser usada para forjar o endereço de outra pessoa. O interesse é fazer o seu próprio software aceitar o que é válido e recusar o que é ambíguo, com uma mensagem que ajude quem está do outro lado.

Próximos passos

Abra o campo de e-mail do seu produto e teste três endereços: um com sinal de soma, um com ponto antes do sinal de arroba e um com caractere acentuado. O que sobreviver já está melhor do que a média. Para os testes que precisam de um destino descartável, use a ferramenta de e-mail temporário e veja depois a lista de verificação de mensagens transacionais antes de considerar o fluxo pronto.