International email

From Wikipedia, the free encyclopedia
Jump to: navigation, search

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.

Email addresses[edit]

Traditional email addresses are limited to characters from the English alphabet and a few other special characters.[1] 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 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.[2] The following are all valid international email addresses:

  用户@例子.广告                                  (Chinese, Unicode)
  उपयोगकर्ता@उदाहरण.कॉम                         (Hindi, Unicode)
  юзер@екзампл.ком                              (Ukrainian, Unicode)
  θσερ@εχαμπλε.ψομ                              (Greek, Unicode)
  Dörte@Sörensen.example.com                    (German, Unicode)
  

UTF-8 headers[edit]

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[edit]

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[edit]

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[edit]

  • 2014-07-15: Postfix mailer started supporting[3] 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.[4] This supports UTF-8 in SMTP or LMTP sender addresses, recipient addresses, and message header values.
  • 2014-08-05: Google announced[5] 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[6] 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[7] which added support for SMTPUTF8, EAI, and IDN.

See also[edit]

References[edit]

  1. ^ RFC 5322: Internet Message Format
  2. ^ RFC 6530: Overview and Framework for Internationalized Email
  3. ^ [1] Postfix SMTPUTF8 support (unicode email addresses)
  4. ^ [2] Postfix stable release 3.0.0
  5. ^ [3] A first step toward more global email
  6. ^ [4] Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities
  7. ^ [5] Amavis 2.10.0 released

Bibliography[edit]

External links[edit]