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.
Video International email
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:
Abc@example.com (English, ASCII) Abc.123@example.com (English, ASCII) user+mailbox/department=shipping@example.com (English, ASCII) !#$%&'*+-/=?^_`.{|}~@example.com (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 derek@example.com 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 users from non-English-speaking European countries whose desired 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)
Maps International email
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.
Adoption
- 2013-11-14: The Bat! Email Client implemented support for Internationalized Domain Names (IDN) in email addresses.
- 2014-07-15: Postfix mailer started supporting Internationalized Email, also known as EAI or SMTPUTF8, defined in RFC 6530 .. RFC 6533. Initial support was made available with a development version 20140715, and on 2015-02-08 ended up in a stable release 3.0.0. This supports UTF-8 in SMTP or LMTP sender addresses, recipient addresses, and message header values.
- 2014-07-19: XgenPlus Email Server started supporting IDN based email, also known as support for SMPTUTF8 , specially for .???? domain.
- 2014-08-05: Google announced that Gmail will recognize addresses that contain accented or non-Latin characters, with more support for internationalization to follow. Their mailers (MX MTA) are announcing support for SMTP Extension for Internationalized Email (SMTPUTF8, RFC 6531).
- 2014-09-30: Message Systems announced that their product Momentum (versions 4.1 and 3.6.5) provides SMTPUTF8 support, the email address internationalization extension to the SMTP protocol, allowing emails to be sent to new, non-western addressed recipients.
- 2014-10-22: the version 2.10.0 of Amavis mail content filter was released which added support for SMTPUTF8, EAI, and IDN.
- 2016-12-07: ?????.??? Launches fully Russian (Cyrillic) email in Moscow through a press conference.
- 2016-10-18: Data Xgen Technologies launched a free linguistic email address under the name "DATAMAIL". In support of Digital India this made in India email app supports IDN (internationalized domain name) in Hindi (??????), Gujarati (???????), Urdu (????), Punjabi (?????? ??), Tamil (?????), Telgu (??????), Bangali (?????), Marathi (?????), Latin English. DATAMAIL is also launching international languages for the countries using Arabic (????????????), Russian (???????)and Chinese (??/??) as their base language.
See also
- Internationalized domain name
- Email Address Internationalization (EAI)
- Unicode and email
- IETF
- ICANN
References
Bibliography
- RFC 6530
- RFC 6531
- RFC 6532
- RFC 6533
- RFC 6783
- RFC 6855
- RFC 6856
- RFC 6857
- RFC 6858
External links
- EAI Working Group Status Page
- Internet Engineering Task Force (IETF)
Source of the article : Wikipedia
0 Comments