路径: 主页 > GB/T > 第728页 > GB/T 46466-2025 | 标准编号 | GB/T 46466-2025 (GB/T46466-2025) | | 中文名称 | 中文电子邮件地址 框架结构总体技术要求 | | 英文名称 | Chinese internet email address - General technical requirement for framework | | 行业 | 国家标准 (推荐) | | 中标分类 | M32 | | 国际标准分类 | 33.040.40 | | 字数估计 | 10,153 | | 发布日期 | 2025-10-31 | | 实施日期 | 2026-02-01 | | 发布机构 | 国家市场监督管理总局、国家标准化管理委员会 | GB/T 46466-2025: 中文电子邮件地址 框架结构总体技术要求
ICS 33.040.40
CCSM32
中华人民共和国国家标准
中文电子邮件地址 框架结构总体技术要求
2025-10-31发布
2026-02-01实施
国 家 市 场 监 督 管 理 总 局
国 家 标 准 化 管 理 委 员 会 发 布
目次
前言 Ⅲ
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 1.1-2020《标准化工作导则 第1部分:标准化文件的结构和起草规则》的规定
起草。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由中华人民共和国工业和信息化部提出并归口。
本文件起草单位:中国互联网络信息中心、广东盈世计算机科技有限公司、中国科学院计算机网络
信息中心、中国信息通信研究院、中国互联网协会、中国电信集团有限公司、清华大学、中国联合网络通
信集团有限公司、中国移动通信集团有限公司、政务和公益机构域名注册管理中心、北京二六三企业通
信有限公司、中国通信标准化协会。
本文件主要起草人:姚健康、李洪涛、陈磊华、秦小伟、徐雷、裴玮、杨学、丁嘉嘉、李彦彪、王朗、钟睿、
林延中、吴秀诚、陈颖棠、张荣圣、刘保君、刘越、孙乐、李秦峰、焦海燕、傅瑜、赫巍、蔡晴、张立坤、张志勇、
沙晓爽、王超、王翠翠、周晓磊、龚嘉、杜鸣。
中文电子邮件地址 框架结构总体技术要求
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
将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]
3.4
中文域名 Chinesedomainname
含有中文字符的域名。
[来源:GB/T 44266-2024,3.1.2]
3.5
信息 message
一个字符串,它被一个用户(发送者)利用特定的电子邮件地址发送到另一个或者多个接收电子邮
件地址(接收者)。
[来源:GB/T 46465-2025,3.5]
3.6
域名编码算法 punycode
实现Unicode字符串和7比特字符串的相互转换的一种编码转换规则。
注:详见IETFRFC3492。
3.7
支持收发含有中文电子邮件地址的邮件系统。
3.8
一种简单的可以高效传输电子邮件的传输协议。
4 缩略语
下列缩略语适用于本文件。
POP:邮局协议(PostOfficeProtocol)
中文域名的使用应符合GB/T 44266-2024的要求。域名只是各种需要中文化的名字和标识符中
的一种。在很多环境中,中文域名并不能很好地方便用户使用日益中文化的互联网,需要更多的中文标
识符来支持。与中文域名最紧密的一个应用就是中文电子邮件地址的使用。为了支持中文电子邮件地
址,需要对原有的邮件系统进行扩展支持中文电子邮件地址。中文电子邮件地址的本地部分和域名部
分可以先通过字符串预处理的方式来判定该电子邮件地址是否合适作为合法的电子邮件地址。
电子邮件地址中文化不是简单地把SMTP信封做改变,或修改 “From,To和Cc”字段,或进行特
殊的编码来显示本地的字符。互联网系统应建立一个中文化电子邮件通讯环境,需要允许在邮件的信
封和信头里都能够使用 UTF-8格式的字符,而这要求SMTP扩展、IMAP扩展、POP扩展以支持
UTF-8编码以允许中文电子邮件地址的发送和接收以及存储和显示。
6 协议要求
6.1 总则
更新SMTP协议、IMAP协议,POP协议以支持中文电子邮件地址的使用。本文件中,UTF-8表
示编码方法,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) 追踪头(tracefield)的格式语法更新。
6.4 兼容现有的7比特电子邮件系统
由于中文电子邮件系统的出现,互联网上必然也存在ASCII电子邮件系统。对于任何SMTP扩展
机制,一个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相互作用的界面来发送邮件,和邮件存储交互来收取邮件。收取......
|