Um endereço de e-mail pode conter caracteres internacionais (não ingleses)?

Se for possível, devo aceitar esses e-mails dos usuários e quais problemas esperar quando eu enviar e-mails para esses endereços?

Oficialmente, por RFC 6532 – Sim .

Para uma rápida explicação, confira a Wikipedia sobre o assunto.

Atualização de 2015: Use o RFC 6532

O 5335 experimental foi Obsoletado por: 6532 e
isso mais tarde foi definido como “Category: Standards Track”,
tornando o padrão.

A Seção 3.2 (Extensões de Sintaxe para RFC 5322 ) atualizou a maioria dos campos de texto para
inclua (apropriado) UTF-8.

The following rules extend the ABNF syntax defined in [RFC5322] and [RFC5234] in order to allow UTF-8 content. VCHAR =/ UTF8-non-ascii ctext =/ UTF8-non-ascii atext =/ UTF8-non-ascii qtext =/ UTF8-non-ascii text =/ UTF8-non-ascii ; note that this upgrades the body to UTF-8 dtext =/ UTF8-non-ascii The preceding changes mean that the following constructs now allow UTF-8: 1. Unstructured text, used in header fields like "Subject:" or "Content-description:". 2. Any construct that uses atoms, including but not limited to the local parts of addresses and Message-IDs. This includes addresses in the "for" clauses of "Received:" header fields. 3. Quoted strings. 4. Domains. Note that header field names are not on this list; these are still restricted to ASCII. 

Por favor, note a inclusão explícita de domínios.
E a exclusão explícita de nomes de header.

Nota também sobre o NFKC :

 The UTF-8 NFKC normalization form SHOULD NOT be used because it may lose information that is needed to correctly spell some names in some unusual circumstances. 

E a seção 3 começa:

 Also note that messages in this format require the use of the SMTPUTF8 extension [RFC6531] to be transferred via SMTP. 

O problema é que alguns clientes de email (ferramentas de servidor e / ou ferramentas de área de trabalho) não o suportam e lançam uma exceção de ’email inválido’ quando você tenta enviar um email para um endereço que contenha umlauts por exemplo.

Se você quiser suporte completo, você poderia fazer o truque com a conversão das partes do endereço de e-mail para “punycode”. Isso permite que os usuários digitem seus endereços da maneira usual, mas você os salva no nível de suporte.

Exemplo: müller.com »xn--mller-kva.com

Ambos apontam para a mesma coisa.

Eu diria que sim, já que vários domínios de nível superior já permitem caracteres não ascii para domínios e como o domínio faz parte de um endereço de e-mail, é perfeitamente possível. Um exemplo para tal domínio seria http://www.öko.de

resposta curta: sim

não apenas no nome de usuário, mas também no nome de domínio são permitidos.

Ainda não. O IEEE planeja fazer isso: Artigo H-Online: Endereços de e-mail internacionalizados de planejamento do IEFT , aqui está o RfC: Extensão SMTP para endereços de e-mail internacionalizados

Citação do H-Online (como foi abaixo):

A Força-Tarefa de Engenharia da Internet (IETF) publicou três documentos cruciais para a padronização de headers de endereço de email que incluem símbolos fora do conjunto de caracteres ASCII. Isso significa que em breve você poderá usar caracteres chineses, sotaques franceses e trema alemã nos endereços de e-mail, bem como no corpo da mensagem. Portanto, se seu nome é Zoë e você trabalha para uma empresa que faz fachadas, talvez esteja interessado em um novo endereço de e-mail. Mas representantes de provedores já estão gemendo. Eles dizem que precisaria haver uma “mania de atualização” se o padrão Unicode UTF-8 for replace o ASCII (American Standard Code para Information Interchange) atualmente usado como o idioma geral de e-mail.

A RFC 5335 especifica o uso de UTF-8 em praticamente todos os headers de email. Mudanças teriam que ser feitas em clientes SMTP, servidores SMTP, agentes de usuários de email (MUAs), software para listas de correspondência, gateways para outras mídias e em qualquer outro lugar onde o email é processado ou transmitido. RFC 5336 expande o protocolo de transporte de email SMTP. No nível do protocolo, a expansão é rotulada como UTF8SMTP.

Um novo campo de header será adicionado como uma espécie de “pára-quedas de emergência” para garantir que os e-mails UTF-8 tenham um pouso suave se forem descartados antes de chegar ao destinatário pelos sistemas que não foram atualizados. O “OldAddress” é um endereço puramente ASCII. Mas o OldAddress não deve ser usado como um canal para uma segunda tentativa de transferência, mas sim para garantir que o feedback seja enviado para casa.

Finalmente, o RFC5337 garante que mensagens corretas sejam enviadas referentes ao status de entrega de emails não-ASCII. O endereço correto de um destinatário inacessível deve ser enviado de volta, mesmo se outro transporte tiver sido recusado. O grupo de trabalho de Internacionalização de Endereços de E-mail (EAI) também está trabalhando em vários “mecanismos de downgrade” para vários campos de header e o envelope. Se possível, as informações do header original devem ser “empacotadas” e preservadas.

DeNIC da Alemanha, o registrador para o domínio “.de”, no entanto, está tomando isso em seu ritmo. “Não há muito o que possamos fazer”, explicou o porta-voz da DeNIC, Klaus Herzig. O DeNIC está, em vez disso, prestando mais atenção à atualização na qual o IETF está trabalhando para o padrão de domínios internacionais – RFC3490, ou IDNA2003, como às vezes é conhecido. “Não estamos muito felizes porque não há compatibilidade com versões anteriores”, explicou Herzig. Quando a atualização chegar, o DeNIC diz que estará jogando seu peso atrás do símbolo “ß” – também conhecido como estzett – que foi negligenciado até agora. O registrador alemão também disse que pode esperar um pouco antes de mudar de acordo com a falta de compatibilidade retroativa. Uma vez que o novo padrão esteja funcionando de forma estável e os registradores e provedores o adotarem, o ß será adicionado.

Em contraste, especialistas acreditam que os registradores chineses na China e em Taiwan implementarão rapidamente a mudança para e-mails internacionalizados. Representantes do CNIC e TWNIC são autores dos padrões. Os usuários chineses atualmente precisam escrever e-mails em ASCII à esquerda do @ e em caracteres chineses à direita para domínios chineses, que já foram internacionalizados.

(Monika Ermert)

A resposta é sim, mas eles precisam ser codificados especialmente.

Olha isso . Leia a parte que se refere aos headers de email e ao RFC 2047.