大势所趋，IDN与IDN Email

【IDN，啥东东？】

现在对新网民来说，他们已经很难再注册到一个全新的短域名或短账号邮箱了。虽然纯英文的域名和邮箱是肯定不会枯竭的 （理论上纯ASCII字符的可能性组合的个数还是很可观的~~），于是IDN再次被搬上桌面，人们对它充满憧憬。

所谓 IDN，就是 Internationalization Domain Name，国际化域名。传统的域名只允许含 纯ASCII字符，而IDN则允许含有 non-ASCII字符了，像一些中文汉字、德文、印度文等。

也就是说，你将可能看到类似 网易.中国、 亚马逊.jp、 Bücher.ch、 ??.???之类的域名了。这对全世界有着不同本地文化不同母语的网民来说，互联网世界无疑将变得更加友好 。

IETF旗下的 EAI （The Email Address Internationalization）工作组负责IDN相关的讨论和草案/标准拟定工作，这绝对不是一个简单的差事。IETF先后发布了 RFC 3490、 RFC 3491、 RFC 3492（Punycode）、 RFC 5890、 RFC 5891、 RFC 5892等一系列文档，并正式提出了 IDNA的概念和相关技术细节，即 Internationalized Domain Names for Applications。

同时，IETF要求所有支持IDN的互联网应用 （电子邮件、网页浏览器等）都应该做到 向下兼容，既支持新的non-ASCII字符，也兼容原先的ASCII字符。

【关于IDN】

说起IDN，第一个无法回避的问题就是 DNS要支持non-ASCII字符，详见 RFC 3490和 RFC 5890。 这里的核心是 ToASCII()和 ToUnicode()两个算法。

在IDN中，所有non-ASCII域名要先使用ToASCII算法最终转化成ASCII字符之后再存储在DNS中，在做DNS查询时就用转化后的ASCII字符。而互联网应用程序在呈现或读写时，则使用原先的non-ASCII字符（使用ToUnicode算法转化回来）。

ToASCII和ToUnicode是将ASCII和non-ASCII相互转化的算法。简单地说，ToASCII()先使用 Nameprep算法完成预处理，接着做 Punycode encode，最后追加上一个ACE （ASCII Compatible Encoding）前缀“xn--”，变成4个字符串。ToUnicode()则刚好相反，摘除ACE前缀并调用Punycode decode即可。 ToASCII()可能失败 （有几种导致异常的情况） ，而ToUnicode()则总是成功的。

例如， .中国 编码后为“.xn--fiqs8s” ， .香港编码后为“.xn--j6w193g”。

DNS是整个互联网世界的一大块基石，几乎所有主流的互联网应用或多或少都用到了DNS。如今DNS要internationalization化，上层的应用们自然也必须跟进了。 你高高兴兴花钱注册了一个IDN域名叫“张三.中国”，并创建一条A类型的DNS记录指向了你的Web服务器，结果在浏览器里一输入地址却发现根本无法访问，人家浏览器根本不认！不可谓不是一个打击。。

时下流行的互联网应用有 Email电子邮件 、 HTTP 网页浏览 、 FTP上下载 等等不下一千种，让所有这些Applications完成IDN化才是最大头的工作。如果不普及IDN App，任由IDN DNS再普及也没有任何意义。

目前我受雇于国内一家大型互联网公司，负责电子邮箱相关工作。下面以IDN Email为代表，介绍一下EAI在IDN Application这块的工作成果。

【邮箱国际化--IDN Email】

邮箱国际化， International email，又叫IDN email或者 Intl email。IETF在 2012年2月公布的 RFC 6530 文档汇总了在这块细分领域的工作成果。分几个方面整理了一下，发现每一块都不是容易啃的骨头，主要有：

• IDN Email Address
• IDN Email Header Field
• SMTP扩展
• DSN扩展
• POP/IMAP/DMARC等其他协议的扩展
• 其他受牵连的系统的兼容性

【1】 IDN Email Address -- 邮箱地址的国际化

根据 RFC 2822，最主流的邮箱地址格式是： display-name

【2】IDN Email Header Field -- 邮件信头的国际化

尽管 MIME已经规范了怎么在电子邮件的信头部分支持non-ASCII字符——使用一定格式的编码。譬如你无须担心邮件标题 （信头Subject:字段）里含有汉字或韩文，只要编码起来即可。

但是MIME本身并不允许带邮箱地址的信头字段直接含有non-ASCII字符，譬如常用的From:、To:、CC:、 Message-ID:、In-Reply-To:等字段。怎么办呢？ IETF在 RFC 6532 里详细介绍了这一块工作。

【3】SMTP协议扩展

【4】DSN扩展

原生的DSN （Delivery Status Notifications）是定义在 RFC 3461，在其中的机器可读部分只允许含有ASCII内容。

于是 RFC 6533给DSN定义了一个新地址类型，允许“原始收件人”参数（ ORCPT）含有non-ASCII字符。这类SMTP服务器的ehlo返回值不仅要有 8BITMIME和SMTPUTF8，当然还得有DSN。

【5】POP/IMAP/DMARC等其他协议的扩展

兼容IDN Email，传递邮件的SMTP/ESMTP协议要做一定的扩展，POP3、IMAP等这些取信和读信的协议也要。

EAI在这块也一直倾注心力，POP3协议的扩展可见 RFC 6856，IMAP协议的扩展可见 RFC 6855。

【6】更多相关系统

电子邮件作为一个成熟的互联网生态系统，它不仅仅与一封邮件的收发存储有关，还与周边很多应用有关联。因此，non-ASCII字符的邮箱地址和邮件牵扯到很多系统，譬如：

• 身份标识符：大部分网站的注册用户的用户名为邮箱账号，是否能兼容non-ASCII邮箱地址呢？
• 邮件过滤系统：最通用的Sieve语言是否兼容？
• 邮箱后端系统：日志数据库、用户索引体系等邮箱后端系统是否兼容？
• 邮箱客户端MUA：读写、是否兼容？
• mailto URI：是否兼容？这在IRI（Internationalized Resource Identifier）里有所讨论。
• DMARC协议：使用信头From:字段的域名作为标识符，是否兼容？
• 邮件加密算法：主流的S/MIME、PGP、DKIM等加密算法都有待兼容
• 邮件列表Mailling List：怎么兼容？在RFC 6783有所讨论。
• 通讯录应用、网址书签应用：邮箱地址和网址属性是否兼容？
• Others……肯定还有很多我没提及的方面

让我们来测试一下几大邮箱服务商对IDN Email的支持程度如何？

【1】网易163.com邮箱 （暂不支持）

【2】网易yeah.net邮箱（已支持）

$ telnet yeahmx01.mxmail.netease.com. 25 <-- 测试yeah.net的MX进信SMTP服务

Trying 123.58.178.224...

Connected to yeahmx01.mxmail.netease.com..

Escape character is '^]'.

220 yeah.net Anti-spam GT for Coremail System (yeah[20121016])

ehlo example.com

250-mail

250-PIPELINING

250-AUTH LOGIN PLAIN

250-AUTH=LOGIN PLAIN

250-coremail 1Uxr2xKj7kG0xkI17xGrU7I0s8FY2U3Uj8Cz28x1UUUUU7Ic2I0Y2UFTsom4UCa0xDrUUUUj

250-SMTPUTF8

250 8BITMIME <-- 大赞！！网易邮箱不愧是霸主，yeah.net邮箱已开始支持IDN！！

mail from:<测试@example.com>

250 Mail OK

quit

221 Bye

Connection closed by foreign host.

$ telnet smtp.yeah.net 25 <-- 测试yeah.net的SMTP发信服务

Trying 123.58.177.132...

Connected to smtp.yeah.net.

Escape character is '^]'.

220 yeah.net Anti-spam GT for Coremail System (yeah[20121016])

ehlo example.com

250-mail

250-PIPELINING

250-AUTH LOGIN PLAIN

250-AUTH=LOGIN PLAIN

250-coremail 1Uxr2xKj7kG0xkI17xGrU7I0s8FY2U3Uj8Cz28x1UUUUU7Ic2I0Y2Ur9PDe3UCa0xDrUUUUj

250-STARTTLS

250-SMTPUTF8 <-- 可见yeah.net不管是进信还是发信，其SMTP服务都已经支持IDN。

250 8BITMIME

quit

221 Bye

Connection closed by foreign host.

[coremail@163admin ~]$ 

【3】谷歌Gmail邮箱 （暂不支持）

经测试，163.com、gmail.com、hotmail.com、outlook.com等主流邮箱服务商都还不支持，但 网易yeah.net邮箱的SMTP服务已经支持IDN特性，赞一个！

【忧虑】

的确，IDN将让互联网变得更友好、更易用，同时也给业界带来诸多挑战。

制定IDN技术标准和系统升级兼容只是冰山一角，还有一些肯定会出现的负面影响，稍微整理一下：

• 同名伪造：或者叫IDN欺诈。IDN允许域名和邮箱地址有海量的字符，不同字符之间却可能长得很相像，人类肉眼很难分辨。这就给域名伪造和网络钓鱼带来一定便利了！譬如U+0430（小写的Cyrillic字母а）和U+0061（小写的ASCII字母a）就长得非常非常像，你能一眼看出amаzon.cn是个伪造的域名吗？
• 协议兼容：IDN的全面推广需要等到主流互联网协议都兼容才行，SMTP、HTTP、URI等等，每一份协议的兼容都需要很多工作量。
• 容易记错：现在还有不少人在记小伙伴的邮箱地址时并非在电脑上复制粘贴，而是从纸张、名片、电视等地方一边看一边手抄的，有那么多相似的ASCII和non-ASCII字符，一不小心就容易记错，以后这样记邮箱地址要再三确认了。。
• 黑名单膨胀：邮件服务商通常会把spammer的邮箱地址加入到黑名单中，IDN将提供海量域名和海量邮箱地址，这类黑名单系统如不做优化，黑名单列表长度将无限膨胀。
• 长度限制：根据RFC 1035，原生DNS域名的每个label（都是ASCII字符）长度应限制在63 octets。现在IDN允许UTF8字符出现在DNS域名中，由于UTF8字符不如ASCII字符那么“压缩”，IDN域名的字符最大个数就更受限制了。
• Others……

【小趣闻】

• IDN在表示ASCII字符以及non-ASCII字符的时候，底层都是Unicode字符。当前都是使用UTF-8编码。
• 国际化邮箱地址叫Internationalization address，简称IDN address又或者i18n address。为啥要把internationalization缩写成i18n呢？答：IT技术宅都是很懒很懒的，internationalization一共有20个字母嫌太长，去掉收尾的i和n，中间部分就是18了~~~于是乎，在IT Geeks们的世界里，i18n=internationalization（国际化），l10n=localization（本地化），g11n=globalization（全球化）。

【小结】

人类 不断求索的本性 （good or evil？）让整个互联网世界充满未知和可能，在未踏遍地球一半领域的时候人们就着急着探月探外星，在两性能正常造人的年代人们就开始捣腾基因克隆，在遍地ipv4的时候就折腾出ipv6、ipv7甚至ipv12，在域名不曾枯竭的上世纪末就琢磨着IDN。

仅就大方向来说，这是好事。罗马也不是一天建成的， 只要地球不被这群人玩爆炸，这些都是大势所趋，但壮志未酬，任重道远。说不定大家们明年要发邮件给我，收件人地址一栏填写的就是陈书记@网易.中国了，说不定是后年，又或者是10年后，上帝知道。

欢迎转载！请在转载时加上本博文的原始地址： http://blog.163.com/pandalove@126/blog/static/980032452013928422423/