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

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

an.unusual.email-@mydomain.com

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

O Google diz que é inválido, então, por enquanto, eu também o assumo como inválido, embora o RFC exclua apenas o caractere [ponto] de iniciar e / ou terminar a parte local.

Nota: Não estou preocupado com a parte do domínio, porque ela se envolve mais devido à maneira como o DNS, o que complica a pergunta e as respostas.

https://social.technet.microsoft.com/Forums/ie/en-US/69f393aa-d555-4f8f-bb16-c636a129fc25/what-are-valid-and-invalid-email-address-characters

— Jimson Kannanthara James
fonte

Boa pergunta. Você já viu esta pergunta e o thread de respostas do Stack Overflow ? Lotes de info-muito do que fora da data, neste ponto, mas ainda bom ponto de partida /

— JakeGould

bom link de referência, parece que o google trata esse email como inválido, enquanto a Microsoft não tem nenhum problema.

— Jimson Kannanthara James

Compartilhando isso desde que você criou o Google: o Gmail ignora todos os períodos em um endereço de e-mail. Portanto, se seu e-mail for "anunusualemail@gmail.com", você também receberá e-mails enviados para "an.unusual.email@gmail.com". Ele também ignora vantagens no final do endereço de email: "anunusualemail+something@gmail.com".

— mowwwalker

No meu próprio serviço de correio, posso banir a letra "u" dos nomes de usuário. Só porque.

— Agent_L 20/06

Respostas:

É um email válido se o email tiver um traço (-) no final da parte local de um email? [...] o Google diz que é inválido, então, por enquanto, eu também o assumo como inválido, embora a RFC exclua apenas o caractere [ponto] de iniciar e / ou terminar a parte local.

É válido. Você só o vê 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 fornecedores.

O Google ou qualquer outra pessoa seria obrigada a aceitar todos os endereços de email possivelmente válidos apenas se o formulário estivesse realmente solicitando um endereço de email válido e 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 de conta nos sistemas do Google, que será a base para um endereço de e-mail somente depois que a conta for 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é nomes de caixas de correio) em seu próprio sistema .

Ou, em outras palavras, definir os caracteres permitidos para 'parte local' significa apenas que os servidores SMTP dos aplicativos de email devem aceitar esses endereços nos cabeçalhos RFC 822 e nos comandos SMTP - mas não diz nada sobre a capacidade de criar essas caixas de correio. (De fato, quando os RFCs de email antigos foram gravados e a maioria das caixas de correio ainda estava vinculada a contas no nível do SO, seus nomes tinham limites semelhantes ou ainda mais rigorosos.)

Por exemplo, esta parte da RFC 5321 (seção 4.1.2, abaixo dos ABNFs) diz explicitamente que um host de recebimento é permitido e, de fato, deve ter limites muito mais rígidos sobre como as próprias caixas de correio são nomeadas:

Enquanto a definição acima para parte local é relativamente permissiva, para máxima interoperabilidade, um host que espera receber e-mails DEVE evitar definir caixas de correio onde a parte local requer (ou usa) o formulário de cadeia de caracteres entre aspas ou onde a parte local é o caso -sensível.

Portanto, embora anunusualemail-@gmail.com seja válido sintaticamente, isso não significa que o Google deve permitir que você o crie.

— gravidade
fonte

Como uma observação interessante, o Google ignora períodos nos endereços de e-mail ( gmail.googleblog.com/2008/03/… ), que também não estão especificados na RFC. Portanto, meunome@gmail.com vai para o mesmo local que meunome@gmail.com ou meunome@gmail.com.

— childofsoong

@JimsonKannantharaJames Em geral, se você quiser verificar se um email é válido, envie um email para esse endereço e force o usuário a tomar uma ação. Qualquer verificação baseada apenas na sintaxe do endereço deve realmente ser apenas para capturar o usuário digitando erros de digitação.

— Michael Mior

@rawity Oh, eu sei - eu estava comentando para dar um exemplo de outra coisa que não está especificada na RFC, mas é permitida.

— childofsoong

@ user71659 Se você não estiver escapando adequadamente dos caracteres de controle, quando necessário, você terá um problema maior. Por fim, o email foi inserido pelo usuário e a entrada do usuário sempre deve ser considerada perigosa. Supondo que algum campo no seu banco de dados seja seguro, devido a algumas regras de validação que podem ser bastante perigosas. O que acontece quando, alguns meses depois, alguém preenche esse campo de outro formulário que não tem a mesma validação?

— Michael Mior

@ user71659 você está confundindo duas questões diferentes e confundindo o argumento. MichaelMior é perfeitamente correcto afirmar que a verificar que um endereço de e-mail existe , você vai ter que enviar um email para o endereço que requer ação do usuário.

— kumarharsh

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

Os nomes de usuário podem conter letras (az), números (0-9), traços (-), sublinhados (_), apóstrofes (') e pontos (.).

Fonte: Diretrizes de nome e senha

Como você observou, o Gmail não permite hífens nos endereços de email.

— davidmneedham
fonte