GB/T 46466-2025 中文电子邮件地址 框架结构总体技术要求

　　ICS 33. 040.40 CCS M 32

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 46466—2025

　　中文电子邮件地址 框架结构总体技术要求

　　Chineseinternetemailaddress—Generaltechnicalrequirementfor framework

　　2025-10-31发布 2026-02-01实施

　　国家市场监督管理总局国家标准化管理委员会

　　

　　发

　　

　　布

　　GB/T 46466—2025

　　目 次

　　前言 Ⅲ

　　1 范围 1

　　2 规范性引用文件 1

　　3 术语和定义 1

　　4 缩略语 2

　　5 协议基础 2

　　6 协议要求 2

　　6. 1 总则 2

　　6. 2 中文电子邮件的 SMTP扩展框架 3

　　6. 3 邮件头和信封支持中文电子邮件地址 3

　　6. 4 兼容现有的 7 比特电子邮件系统 3

　　6. 5 POP扩展支持中文电子邮件系统 4

　　6. 6 IMAP扩展支持中文电子邮件系统 4

　　6. 7 邮件客户端扩展支持中文电子邮件系统 4

　　参考文献 5

　　Ⅰ

　　GB/T 46466—2025

　　前 言

　　本文件按照 GB/T 1. 1—2020《标准化工作导则 第 1部分 :标准化文件的结构和起草规则》的规定起草 。

　　请注意本文件的某些内容可能涉及专利 。本文件的发布机构不承担识别专利的责任 。

　　本文件由中华人民共和国工业和信息化部提出并归 口 。

　　本文件起草单位 : 中国互联网络信息中心 、广东盈世计算机科技有限公司 、中国科学院计算机网络信息中心 、中国信息通信研究院 、中国互联网协会 、中国电信集团有限公司 、清华大学 、中国联合网络通信集团有限公司 、中国移动通信集团有限公司 、政务和公益机构域名注册管理中心 、北京二六三企业通信有限公司 、中国通信标准化协会 。

　　本文件主要起草人 :姚健康 、李洪涛 、陈磊华 、秦小伟 、徐雷 、裴玮 、杨学 、丁嘉嘉 、李彦彪 、王朗 、钟睿 、林延中 、吴秀诚 、陈颖棠 、张荣圣 、刘保君 、刘越 、孙乐 、李秦峰 、焦海燕 、傅瑜 、赫巍 、蔡晴 、张立坤 、张志勇 、沙晓爽 、王超 、王翠翠 、周晓磊 、龚嘉 、杜鸣 。

　　Ⅲ

　　GB/T 46466—2025

　　中文电子邮件地址 框架结构总体技术要求

　　1 范围

　　本文件规定了在互联网体系上使用中文电子邮件地址的框架体系总体技术要求 。

　　本文件适用于电子邮件地址服务提供商以及软件厂商开发支持中文电子邮件地址的应用或者服务等 。

　　2 规范性引用文件

　　下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款 。其中 , 注 日期的引用文件 ,仅该日期对应的版本适用于本文件 ;不注日期的引用文件 ,其最新版本(包括所有的修改单) 适用于本文件 。

　　GB/T 1988—1998 信息技术 信息交换用七位编码字符集

　　GB/T 32397—2015

　　中文电子邮件地址 邮件头格式技术要求

　　GB/T 32398—2015

　　中文电子邮件地址 简单邮件传输协议扩展技术要求

　　GB/T 44266—2024

　　中文域名总体技术要求

　　GB/T 46465—2025

　　中文电子邮件地址 邮局协议(POP)技术要求

　　GB/T 46467—2025

　　中文电子邮件地址 交互式邮件存取协议(IMAP)技术要求

　　3 术语和定义

　　下列术语和定义适用于本文件 。

　　3. 1

　　电子邮件 electronicmail:email

　　在计算机网络上 ,用户终端之间往来的信函 。

　　[来源 :GB/T 5271. 32—2006,32. 01. 01,有修改] 3.2

　　通用字符 unicodecharacter

　　根据其位置或码位来识别字符 ,给每个字符提供的一个唯一的数字 。

　　注 : 例如 ,U+12AB指的是在 Unicode表中位于 12AB处的字符 。

　　[来源 :GB/T 46465—2025,3. 2] 3.3

　　通用字符八位编码 UCS transformation format-8 ;UTF-8

　　将 Unicode分配整 数 给 字 符 的 编 码 表 中 的 一 串 字 符 表 示 为 一 串 字 节 的 方 法 。 其 中 , 字 符 采 用1个 ~4个8比特字节的序列进行编码 。仅仅一个 8 比特字节的一个序列中 , 字节的高位为 0,其他的7位用于字符值编码 。n(n>1)个 8 比特字节的一个序列中 ,初始的 8 比特字节中高 n 位为 1,接着 一位为 0,此字节余下的位包含被编码字符值的位 。接着的所有 8 比特字节的最高位为 1,接着下一位为0,余下每个字节 6位包含被编码字符的位 。

　　[来源 :GB/T 46465—2025,3. 3]

　　1

　　GB/T 46466—2025

　　3.4

　　中文域名 Chinesedomain name

　　含有中文字符的域名 。

　　[来源 :GB/T 44266—2024,3. 1. 2] 3.5

　　信息 message

　　一个字符串 ,它被一个用户(发送者)利用特定的电子邮件地址发送到另一个或者多个接收电子邮件地址(接收者) 。

　　[来源 :GB/T 46465—2025,3. 5] 3.6

　　域名编码算法 punycode

　　实现 Unicode字符串和 7 比特字符串的相互转换的一种编码转换规则 。

　　注 : 详见 IETF RFC 3492。

　　3.7

　　中文电子邮件系统 Chineseemailaddresssystem

　　支持收发含有中文电子邮件地址的邮件系统 。

　　3. 8

　　简单邮件传输协议 simplemailtransferprotocol;SMTP

　　一种简单的可以高效传输电子邮件的传输协议 。

　　4 缩略语

　　下列缩略语适用于本文件 。

　　IMAP:交互式邮件存取协议 (InternetMailAccess Protocol,Internet)

　　MSA: 邮件提交代理(Message Submission Agent)

　　POP: 邮局协议(PostOffice Protocol)

　　5 协议基础

　　中文域名的使用应符合 GB/T 44266—2024的要求 。域名只是各种需要中文化的名字和标识符中的一种 。在很多环境中 , 中文域名并不能很好地方便用户使用 日益中文化的互联网 ,需要更多的中文标识符来支持 。与中文域名最紧密的一个应用就是中文电子邮件地址的使用 。为了支持中文电子邮件地址,需要对原有的邮件系统进行扩展支持中文电子邮件地址 。 中文电子邮件地址的本地部分和域名部分可以先通过字符串预处理的方式来判定该电子邮件地址是否合适作为合法的电子邮件地址 。

　　电子邮件地址中文化不是简单地把 SMTP信封做改变 ,或修改 “From , To 和 Cc”字段 ,或进行特殊的编码来显示本地的字符 。互联网系统应建立一个中文化电子邮件通讯环境 ,需要允许在邮件的信封和信头里都 能 够 使 用 UTF-8 格 式 的 字 符 , 而 这 要 求 SMTP 扩 展 、IMAP 扩 展 、POP 扩 展 以 支 持UTF-8编码以允许中文电子邮件地址的发送和接收以及存储和显示 。

　　6 协议要求

　　6. 1 总则

　　更新 SMTP协议 、IMAP协议 ,POP协议以支持中文电子邮件地址的使用 。本文件中 , UTF-8表

　　2

　　GB/T 46466—2025

　　示编码方法 ,UTF8表示用来操作 UTF-8的命令 。

　　6.2 中文电子邮件的 SMTP扩展框架

　　SMTP进行扩展来支持中文电子邮件地址的使用 。这个扩展的关键 字 是 “SMTPUTF8”, 作 为 一个 SMTP扩展 ,“SMTPUTF8”定义为 :

　　a) 应在电子邮件地址中使用 UTF-8字符串 ,包括电子邮件地址中的本地部分和域名部分 ;

　　b) 应在电子邮件地址中有选择地使用 UTF-8格式的中文字符串 ;

　　c) 应要求服务器声明 8BITMIME 扩展以及客户端支持 8 比特传输 , 这样头部信息可以不用通过特殊的内容传输编码就能够传输 ;

　　d) 应提供必要的信息来支持向下兼容机制 。

　　支持中文电子邮件地址的中文电子邮件系统符合以下原则 。

　　a) 中文电子邮件地址可进入不同的系统或子系统 ,这些系统可对中文电子邮件地址进行字符转换或进行编码转换 。如果电子邮件地址的本地部分含有中文 ,域名部分不应使用域名编码算法 punycode编码来显示给用户 , 以保持编码和格式的一致性 。

　　b) 一个 SMTP 中继可以有以下选择 :

　　1) 可通过 ESMTP 的“SMTPUTF8”声明 ,来明确标示支持中文电子邮件地址 ;

　　2) 拒绝发送邮件 ,然后给发送者返回一个未投递通知信息 ,这样发送者可采取其他方法来发送邮件 ;

　　3) 如果因为下一跳的系统不支持“SMTPUTF8”扩展 ,而且没有足够的信息可以利用实现降级 ,应拒绝发送邮件或者产生并且发送一个未投递信息给发送者 。

　　c) 目前没有一种可行的方法来正确识别 UTF-8字符 ,允许多种编码的字符容易引起混乱 ,也不利于世界范围内邮件的互联互通 ,本文件规定在电子邮件地址 和 头 部 应 使 用 UTF-8编 码 的字符 。

　　在 SMTP服务器做 DNS域名记录查询时 ,应以域名编码算法 punycode编码的兼容 7 比特的编码(ACE)格式向 DNS服务器提交数据 。

　　6.3 邮件头和信封支持中文电子邮件地址

　　传统的邮件信息格式只允许符合 GB/T 1988—1998的字符出现在邮件头里 ,本文件要求中文电子邮件地址系统应允许非 ASCII字符出现在邮件头里 ,这些字符是以 UTF-8编码格式的 UNICODE字符 ,通过 UTF-8编码传输电子邮件头部域 。

　　允许在邮件头里使用非 7 比特字符 ,会影响 SMTP客户端 、SMTP服务器 、邮件用户客户端和网关等各种解析和处理邮件信息的进程 。在 GB/T 32398—2015里规定了用 “SMTPUTF8”扩展来阻止非ASCII字符的传输 ,来避免在传输过程中带有邮件头的信息被错误解析 。使用“SMTPUTF8”扩展并不能阻止非 7 比特邮件头信息传递给邮件存储器 ,如果这些存储器没有支持中文电子邮件地址,可能不会正确解析这些邮件信息 ,这些存储系统如 POP、IMAP等也应更新支持中文电子邮件地址系统 。本节的目的是允许非 7 比特字符在邮件头里传输 ,并不规定如何将这些信息传递给非中文电子邮件系统 。

　　在邮件头里主要应做如下变化 :

　　a) 允许邮件头里出现 UTF-8编码的 UNICODE字符 ;

　　b) 在 MIME头里增加 message/global类型 ;

　　c) 邮件头的语法格式进行扩展支持 UTF-8编码 ;

　　d) 追踪头(trace field)的格式语法更新 。

　　6.4 兼容现有的 7 比特电子邮件系统

　　由于中文电子邮件系统的出现 ,互联网上必然也存在 ASCII电子邮件系统 。对于任何 SMTP扩展

　　3

　　GB/T 46466—2025

　　机制 ,一个 SMTP客户端要求一些属性而服务器可能并不支持要求的属性 。如果一个信封地址或邮件头信息包含非 7 比特字符 ,这封邮件就不能投递给不支持 UTF-8扩展的 SMTP服务器 。对于中文电子邮件地址的投递 ,需要在传输过程中每一个邮件服务器都支持“SMTPUTF8”扩展 。 当其中的个别服务器不支持这个扩展时 候 , 应 进 行 退 信 处 理 或 者 利 用 中 文 电 子 邮 箱 的 别 名 英 文 电 子 邮 箱 地 址 来 进 行发送 。

　　6.5 POP扩展支持中文电子邮件系统

　　POP服务器应包括如下能力 。

　　a) LANG 能力 :POP3允许大多数的响应需要返回给用户可读的文本 , LANG 功能和命令允许POP3客户端与服务器协商应该使用什么语言来传递这些文本 。为了简化解析 ,所有的 POP3服务器都应允许中文字符 。

　　b) UTF8能力 :根据 POP3扩展机制 ,本文件增加了一个新的能力响应标识符来支持新的服务器功能 ,包括一个新的命令 :UTF8。具体应符合 GB/T 46465—2025 中文电子邮件地址—邮局协议(POP)技术要求 。

　　6.6 IMAP扩展支持中文电子邮件系统

　　支持 中 文 电 子 邮 件 地 址 的 IMAP 应 扩 展 支 持 “UTF-8”能 力从 而 支 持 8 位 字 符 , 应 允 许GB/T 32397—2015规定的邮件头格式 ,也要确立一种机制来支持 UTF-8格式的邮箱名字和登录用户名及密码 。IMAP客户端可使用 ENABLE命令来通知服务器可以使用与 UTF-8相关的机制 。具体应符合 GB/T 46467—2025 中文电子邮件地址—交互式邮件存取协议(IMAP)技术要求 。

　　6.7 邮件客户端扩展支持中文电子邮件系统

　　邮件客户端具有和 MSA相互作用的界面来发送邮件 , 和邮件存储交互来收取邮件 。 收取邮件的接口直接进入文件系统或进入 POP或 IMAP服务器 。客户端也提供了用户界面 ,允许终端用户读取 、显示 、撰写邮件 。

　　支持中文电子邮件地 址 的 客 户 端 应 有 能 够 支 持 UTF-8格 式 的 字 符 的 能 力 , 允 许 GB/T 32397— 2015规定的邮件头格式 。

　　对于一个支持“SMTPUTF8”的邮件代理客户端 , 会遇到多种可能性 ,基于电子邮件信封和正文是否包含非 7 比 特 字 符 以 及 MSA 是 否 支 持 “SMTPUTF8”扩 展 等 问 题 。 如 果 邮 件 提 交 代 理 不 支 持“SMTPUTF8”扩展 , 邮件代理客户端不应发送带有“SMTPUTF8”头部的信息 ,应采用如下方法来处理这种情况 ,分别是 :

　　a) 用 7 比特地址重写头部 ;

　　b) 拒绝发送信息 ;

　　c) 寻找一个能够到达目的的替代的路由 。

　　4

　　GB/T 46466—2025

　　参 考 文 献

　　[1] GB/T 5271. 32—2006 信息技术 词汇 第 32部分 : 电子邮件

　　[2] IETF RFC 3492 Punycode: A Bootstring Encoding of Unicode for Internationalized Domain Namesin Applications(IDNA)

　　5