Can an email address contain international (non-en

Question

If it's possible, should I accept such emails from users and what problems to expect when I will be sending mails to such addresses?

Answer 1

Update 2015: Use RFC 6532

The experimental 5335 has been Obsoleted by: 6532 and
this later has been set to "Category: Standards Track",
making it the standard.

The Section 3.2 (Syntax Extensions to RFC 5322) has updated most text fields to
include (proper) 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.

Please note the explicit inclusion of Domains.
And the explicit exclusion of header names.

Also Note about 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.

And Section 3 start:

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

Answer 2

short answer: yes

not only in the username but also in the domain name are allowed.

Answer 3

Officially, per RFC 6532 - Yes.

For a quick explanation, check out wikipedia on the subject.

Answer 4

Not yet. The IEEE plans to do this: H-Online article: IEFT planning internationalised email addresses, here is the RfC: SMTP Extension for Internationalized Email Addresses

Quote from H-Online (as it went down):

The Internet Engineering Task Force (IETF) has published three crucial documents for the standardisation of email address headers that include symbols outside the ASCII character set. This means that soon you'll be able to use Chinese characters, French accents, and German umlauts in email addresses as well as just in the body of the message. So if your name is Zoë and you work for a company that makes façades, you might be interested in a new email address. But representatives of providers are already moaning. They say there would need to be an "upgrade mania" if the Unicode standard UTF-8 is to replace the American Standard Code for Information Interchange (ASCII) currently used as the general email language.

RFC 5335 specifies the use of UTF-8 in practically all email headers. Changes would have to be made to SMTP clients, SMTP servers, mail user agents (MUAs), software for mailing lists, gateways to other media, and everywhere else where email is processed or passed along. RFC 5336 expands the SMTP email transport protocol. At the level of the protocol, the expansion is labelled UTF8SMTP.

A new header field will be added as a sort of "emergency parachute" to ensure that UTF-8 emails have a soft landing if they are thrown out before reaching the recipient by systems that have not been upgraded. The "OldAddress" is a purely ASCII address. But OldAddress is not to be used as a channel for a second transfer attempt, but rather to make sure that feedback is sent home.

Finally, RFC5337 ensures that correct messages are sent pertaining to the delivery status of non-ASCII emails. The correct address of an unreachable addressee must be sent back, even if further transport has been refused. The email Address Internationalization (EAI) working group is also working on a number of "downgrade mechanisms" for various header fields and the envelope. If possible, original header information is to be "packaged" and preserved.

Germany's DeNIC, the registrar for the ".de" domain, is nonetheless taking this in its stride. "There is really not much we can do", explained DeNIC spokesperson Klaus Herzig. DeNIC is instead paying more attention to the update that the IETF is working on for the standard of international domains – RFC3490, or IDNA2003 as it's sometimes known. "We are not that happy about it because there is no backwards compatibility," Herzig explained. When the update comes, DeNIC says it will be throwing its weight behind the symbol "ß" - also known as estzett - which has been overlooked up to now. The German registrar also says that it may wait a bit before switching in light of the lack of backward compatibility. Once the new standard is running stably and registrars and providers have adopted it, the ß will be added.

In contrast, experts believe that Chinese registrars in China and Taiwan will quickly implement the change for internationalised email. Representatives of CNIC and TWNIC are authors of the standards. Chinese users currently have to write emails in ASCII to the left of the @ and in Chinese characters to the right of it for Chinese domains, which have already been internationalized.

(Monika Ermert)

Answer 5

The problem is that some mail clients (server-tools and / or desktop tools) don't support it and throw an 'invalid email' exception when you try to send a mail to an address which contains umlauts for example.

If you want full support, you could do the trick with converting the email-address parts to "punycode". This allows users to type in their addresses the usual way but you save it the supported-level way.

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

Both points to the same thing.

Answer 6

I would assume yes since a number of top level domains already allow non ascii characters for domains and since the domain is part of an email address, it's perfectly possible. An example for such a domain would be www.öko.de