International email (IDN email or Intl email) is email that contains international characters (characters which do not exist in the ASCII character set), encoded as UTF-8, in the email header and in supporting mail transfer protocols. The most significant aspect of this is the allowance of email addresses (also known as email identities) in most of the world's writing systems, at both interface and transport levels.
Contents
Email addresses
Traditional email addresses are limited to characters from the English alphabet and a few other special characters.
The following are valid traditional email addresses:
[email protected] (English, ASCII) [email protected] (English, ASCII) user+mailbox/[email protected] (English, ASCII) !#$%&'*+-/=?^_`.{|}[email protected] (English, ASCII) "Abc@def"@example.com (English, ASCII) "Fred Bloggs"@example.com (English, ASCII) "Joe.Blow"@example.com (English, ASCII)A Russian might wish to use дерек@екзампил.ком as their identifier but be forced to use a transcription such as [email protected] or even some other completely unrelated identifier instead. The same is clearly true of Chinese, Japanese and many other nationalities that do not use Latin scripts, but also applies to French and Polish users whose addresses might contain diacritics (e.g. André or Płużyna). As a result, email users are forced to identify themselves using non-native scripts - or programmers of email systems must compensate for this by converting identifiers from their native scripts to ASCII scripts and back again at the user interface layer.
International email, by contrast, uses Unicode characters encoded as UTF-8 - allowing for the encoding the text of addresses in most of the world's writing systems. The following are all valid international email addresses:
用户@例子.广告 (Chinese, Unicode) उपयोगकर्ता@उदाहरण.कॉम (Hindi, Unicode) юзер@екзампл.ком (Ukrainian, Unicode) θσερ@εχαμπλε.ψομ (Greek, Unicode) Dörte@Sörensen.example.com (German, Unicode) аджай@экзампл.рус (Russian, Unicode)UTF-8 headers
Although the traditional format for email header section allows non-ASCII characters to be included in the value portion of some of the header fields using MIME-encoded words (e.g. in display names or in a Subject header field), MIME-encoding must not be used to encode other information in a header, such as an email address, or header fields like Message-ID or Received. Moreover, the MIME-encoding requires extra processing of the header to convert the data to and from its MIME-encoded word representation, and harms readability of a header section. Including Unicode characters in a header section using UTF-8 encoding eliminates these limitations and also the need to transmit additional encoding and character set information, as UTF-8 encoding will be assumed implicitly.
Interoperability via downgrading
Since traditional email standards constrain all email header values to ASCII only characters, it is possible that the presence of UTF-8 characters in email headers would decrease the stability and reliability of transporting such email. This is because some email servers do not support these characters. This is becoming less and less the case as of 2014 and IDN (internationalized domain name) with the UTF-8 characters is taking over. There was a proposed method by members of the IETF, by which email can be downgraded into the "legacy" all ASCII format which all standard email servers should support. This proposal has been obsoleted in 2012 by RFC 6530.
Standards framework
The set of Internet RFC documents RFC 6530, RFC 6531, RFC 6532, and RFC 6533, all of them published in February 2012, define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email.