Can an email address contain international (non-english) characters?

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?

Officially, per RFC 6532 - Yes.

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

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 https://en.wikipedia.org/wiki/Unicode_equivalence#Combining_and_precomposed_characters" title="Combining characters">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.

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.

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

short answer: yes

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

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)

The answer is yes, but they need to be encoded specially.

Look at this. Read the part that refers to email-headers and RFC 2047.