国际化电子邮件地址（IEA）协议虽自2014年起已标准化，但部署仍局限于极少数语言，主流邮件服务器、服务商与客户端支持缺失，导致用户无法创建非ASCII邮箱，制约了IDN顶级域的实际效用。
协议框架已就绪但落地滞后：
IETF EAI工作组已发布RFC6530至RFC6533、RFC6783、RFC6855至RFC6858共9份RFC，涵盖SMTPUTF8扩展、国际化邮件头、投递状态通知、邮件列表、IMAP/POP3的UTF-8支持及降级机制。这些标准使“用户名@域名”可使用原生脚本（如राम@भाषा.भारत），消除了新用户必须掌握基础英语才能注册邮箱的门槛。然而，Gmail、Yahoo、Hotmail等主流提供商及常用客户端至今未普遍实现IEA创建与收发功能，开源邮件服务器（如Postfix）虽在3.0版引入SMTPUTF8，但生产环境升级缓慢，导致协议栈完整却无法端到端生效。
部署障碍与开源升级路径：
核心瓶颈在于邮件栈各层对IDN与EAI的库级支持不足。建议优先推动主流MTA（Postfix 3.0+、Exim、Dovecot等）在默认构建中启用SMTPUTF8与UTF-8 IMAP/POP，并修复语言绑定库（Python idna、ICU、OpenSSL等）的IDN解析缺陷。同时需在注册流程、密码重置、反垃圾规则等业务逻辑中补齐非ASCII地址的校验与存储能力，避免因前端放行、后端截断造成投递失败。
多方协作推进建议：
需采取多利益相关方方式，协调I*组织（ICANN、IETF、ISOC、区域注册机构等）共同制定部署里程碑：推动开源社区发布长期支持版本、引导大型邮件服务商开放IEA注册入口、推动终端厂商在客户端完成UTF-8渲染与降级回退测试。唯有服务端、库层、客户端同步跨越“支持协议”与“可用功能”的鸿沟，IDN顶级域持有者才能真正以原生语言收发邮件，释放“连接下十亿用户”的红利。
对运维与网络工程师而言，当前行动重点是：在MTA升级周期中强制启用SMTPUTF8，排查依赖库的IDN兼容性，并在监控中增加非ASCII地址的投递成功率指标，确保协议栈从标准走向生产可用。
原文: APNIC Blog（2017-01-23）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog