ID do email com traço no final da parte local

Question

É um email válido se o email tiver um traço (-) no final da parte local de um email? Por exemplo,

[email protected]

Ou para generalizar, algum desses caracteres ( Characters !#$%&'*+-/=?^_''{|}~ (ASCII: 33, 35-39, 42, 43, 45, 47, 61, 63, 94-96, 123-126) ), que são válidos para estar na parte local do e-mail no início e / ou no final do ID do e-mail?

O Google diz que é inválido, portanto, por enquanto, também considero inválido, embora o RFC exclua apenas o caractere [ponto] de começar e terminar a parte local.

Nota:Nãoestoupreocupadocomapartedodomínio,porqueissosetornamaisenvolvidodevidoàformacomooDNS,oquecomplicaasperguntaserespostas.

link

    

Answer 1

Is it a valid email if the email has a dash (-) at the end of local part of an email? [...] Google says it is invalid, so for the time being I assume it as invalid too, though RFC excludes only [dot] character from starting with and/or ending local part.

É válido. Você está vendo o Google ser rejeitado pelo Google porque realiza uma verificação completamente diferente. Eles têm suas próprias políticas sobre o que a parte local pode ser, assim como muitos outros provedores.

O Google, ou qualquer outra pessoa, seria obrigado a aceitar todos os endereços de e-mail possivelmente válidos somente se o formulário estivesse realmente pedindo um endereço de e-mail válido existente (possivelmente do provedor). Por exemplo, seria um erro se o campo Para: / Cc: do Gmail rejeitasse um endereço válido.

Mas o campo destacado não solicita um endereço de e-mail existente. ele solicita um nome da conta nos sistemas do Google, que será a base para um endereço de e-mail somente depois que a conta tiver sido criada. Não há nada que proíba o Google ou qualquer outra pessoa de limitar o conjunto de nomes de contas válidos (ou, na verdade, até mesmo nomes de caixas de correio) em seu próprio sistema .

Ou, em outras palavras, definir os caracteres permitidos para 'local-part' significa apenas que os aplicativos de correio dos servidores SMTP devem aceitar esses endereços nos cabeçalhos RFC 822 e nos comandos SMTP - mas isso não diz nada sobre ser capaz de < em> criar tais caixas de correio. (De fato, quando os primeiros RFCs de e-mail eram escritos e a maioria das caixas de correio ainda estava vinculada a contas no nível do sistema operacional, seus nomes tinham limites semelhantes ou ainda mais restritos.)

Por exemplo, esta parte do RFC 5321 (seção 4.1.2, abaixo ABNFs) explicitamente diz que um host de recebimento tem permissão e, de fato, deve ter limites muito mais estritos sobre como suas próprias caixas de correio são nomeadas :

While the above definition for Local-part is relatively permissive, for maximum interoperability, a host that expects to receive mail SHOULD avoid defining mailboxes where the Local-part requires (or uses) the Quoted-string form or where the Local-part is case-sensitive.

Portanto, embora [email protected] seja válido sintaticamente, isso não significa que o Google deva permitir que você o crie.

    

Answer 2

O G Suite (formalmente o Google Apps para seu domínio) permite hífens (traços) em endereços de e-mail, mesmo como o último caractere.

Usernames can contain letters (a-z), numbers (0-9), dashes (-), underscores (_), apostrophes ('), and periods (.).

Fonte: Diretrizes de nome e senha

Como você observou, o Gmail não permite hífens em endereços de e-mail.