达芬奇密码

除了技术,无它

439篇博客

大势所趋,IDN与IDN Email

达芬奇密码2018-08-02 11:51
【IDN,啥东东?】
现在对新网民来说,他们已经很难再注册到一个全新的短域名或短账号邮箱了。虽然纯英文的域名和邮箱是肯定不会枯竭的 (理论上纯ASCII字符的可能性组合的个数还是很可观的~~),于是IDN再次被搬上桌面,人们对它充满憧憬。

所谓 IDN,就是 Internationalization Domain Name,国际化域名。传统的域名只允许含 纯ASCII字符,而IDN则允许含有 non-ASCII字符了,像一些中文汉字、德文、印度文等。
也就是说,你将可能看到类似 网易.中国亚马逊.jpBücher.ch??.???之类的域名了。这对全世界有着不同本地文化不同母语的网民来说,互联网世界无疑将变得更加友好

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

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

【关于IDN】
说起IDN,第一个无法回避的问题就是 DNS要支持non-ASCII字符,详见 RFC 3490RFC 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”。

ICANN在2009年新发布了11个TLD (Top-Level Domain),分别对应全球11种non-ASCII语言表达“测试”意思的词语,详见 此表格。这是全球第一批 ccIDN域名,又叫IDN ccTLD (internationalized country code top-level domain)
现在,全球各洲的域名注册商都开始推出IDN域名的注册服务,但普及率还不高。

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
其中display-name已有一定的编码规则(详见 MIME Part3)可以含non-ASCII字符。但是,local-part和domain-part两个元素都只能含有7-bit ASCII字符,绝对不能含有non-ASCII字符。

现在要IDN化,那么local-part和domain-part都必须支持non-ASCII字符。
domain-part已经在RFC 5890里解决了,而原生的 SMTP协议并不允许local-part部分包含non-ASCII字符的,于是 RFC 6531 (作者都是华人,哇!)再次扩展了SMTP协议,允许local-part含有non-ASCII字符。
【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协议扩展
尽管某些SMTP服务器已经支持 RFC 6152定义的 8BITMIME特性,允许传输8-bit MIME数据。
但这还不足够。要让SMTP协议支持IDN Email的传输,其ehlo响应值不仅要带 8BITMIME特性,还要带一个新的 SMTPUTF8特性,详见 RFC 6531

【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……肯定还有很多我没提及的方面
【测试@20131030】
让我们来测试一下几大邮箱服务商对IDN Email的支持程度如何?

【1】网易163.com邮箱 (暂不支持)
$ telnet 163mx01.mxmail.netease.com. 25
Trying 220.181.14.140...
Connected to 163mx01.mxmail.netease.com..
Escape character is '^]'.
220 163.com Anti-spam GT for Coremail System (163com[20121016])
ehlo example.com
250-mail
250-PIPELINING
250-AUTH LOGIN PLAIN
250-AUTH=LOGIN PLAIN
250-coremail 1Uxr2xKj7kG0xkI17xGrU7I0s8FY2U3Uj8Cz28x1UUUUU7Ic2I0Y2UrUHpu0UCa0xDrUUUUj
250 8BITMIME <-- 只有8BITMIME,还木有SMTPUTF8特性,暂不支持IDN。
quit
221 Bye
Connection closed by foreign host.
【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邮箱 (暂不支持)
$ telnet gmail-smtp-in.l.google.com. 25
Trying 74.125.129.27...
Connected to gmail-smtp-in.l.google.com..
Escape character is '^]'.
220 mx.google.com ESMTP yj4si736410pac.253 - gsmtp
ehlo example.com
250-mx.google.com at your service, [220.181.12.242]
250-SIZE 35882577
250-8BITMIME <-- 与163.com邮箱一样,只有8BITMIME而没有SMTPUTF8,暂不支持IDN。
250-STARTTLS
250-ENHANCEDSTATUSCODES
250 CHUNKING
quit
221 2.0.0 closing connection yj4si736410pac.253 - gsmtp
Connection closed by foreign host.

经测试,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的全面推广需要等到主流互联网协议都兼容才行,SMTPHTTPURI等等,每一份协议的兼容都需要很多工作量。
  • 容易记错:现在还有不少人在记小伙伴的邮箱地址时并非在电脑上复制粘贴,而是从纸张、名片、电视等地方一边看一边手抄的,有那么多相似的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/


网易云新用户大礼包:https://www.163yun.com/gift

本文来自网易实践者社区,经作者陈俊平授权发布。