| 标准编号 | GB/T 46465-2025 (GB/T46465-2025) | | 中文名称 | 中文电子邮件地址 邮局协议（POP）技术要求 | | 英文名称 | Chinese internet email address - Technical requirement for post office protocol to support | | 行业 | 国家标准 (推荐) | | 中标分类 | M32 | | 国际标准分类 | 33.040.40 | | 字数估计 | 14,126 | | 发布日期 | 2025-10-31 | | 实施日期 | 2026-02-01 | | 发布机构 | 国家市场监督管理总局、国家标准化管理委员会 | GB/T 46465-2025: 中文电子邮件地址 邮局协议（POP）技术要求
ICS 33.040.40
CCSM32
中华人民共和国国家标准
中文电子邮件地址 邮局协议
(POP)技术要求
2025-10-31发布
2026-02-01实施
国 家 市 场 监 督 管 理 总 局
国 家 标 准 化 管 理 委 员 会 发 布
目次
前言 Ⅲ
1 范围 1
2 规范性引用文件 1
3 术语和定义 1
4 缩略语 2
5 协议基础 2
6 协议要求 3
6.1 总体要求 3
6.2 LANG能力 3
6.3 UTF8能力 3
6.4 UTF8命令 4
6.5 UTF8能力的USER参数 4
6.6 UTF8响应码 5
6.7 本地UTF8信箱 5
附录A(资料性) POP命令使用示例 6
参考文献 8
前言
本文件按照GB/T 1.1-2020《标准化工作导则 第1部分:标准化文件的结构和起草规则》的规定
起草。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。
本文件由中华人民共和国工业和信息化部提出并归口。
本文件起草单位:中国互联网络信息中心、广东盈世计算机科技有限公司、中国科学院计算机网络
信息中心、中国信息通信研究院、中国互联网协会、中国电信集团有限公司、清华大学、中国联合网络通
信集团有限公司、中国移动通信集团有限公司、政务和公益机构域名注册管理中心、北京二六三企业通
信有限公司、中国通信标准化协会。
本文件主要起草人:李洪涛、姚健康、裴玮、陈磊华、丁嘉嘉、秦小伟、林延中、陈颖棠、吴秀诚、徐雷、
杨学、李彦彪、刘保君、钟睿、张荣圣、王朗、刘越、孙乐、李秦峰、焦海燕、张立坤、沙晓爽、张志勇、蔡晴、
赫巍、王超、傅瑜、王翠翠、于威、周晓磊、龚嘉、杜鸣。
中文电子邮件地址 邮局协议
(POP)技术要求
1 范围
本文件规定了在互联网体系上使用邮局协议(POP)扩展支持中文电子邮件地址的技术要求。
本文件适用于电子邮件服务提供商以及软件厂商开发支持中文电子邮件地址的应用或者服务等。
2 规范性引用文件
下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中,注日期的引用文
件,仅该日期对应的版本适用于本文件;不注日期的引用文件,其最新版本(包括所有的修改单)适用于
本文件。
GB/T 1988-1998 信息技术 信息交换用七位编码字符集
GB/T 44266-2024 中文域名总体技术要求
IETFRFC1939 邮局协议第三版本(PostOfficeProtocol-Version3)
IETFRFC2045 多用途互联网邮件扩展(MIME) 第一部分:互联网消息主体格式[Multipurpose
ges)
3 术语和定义
下列术语和定义适用于本文件。
3.1
电子邮件 electronicmail:email
在计算机网络上,用户终端之间往来的信函。
[来源:GB/T 5271.32-2006,32.01.01,有修改]
3.2
通用字符 unicode character
根据其位置或码位来识别字符,给每个字符提供的一个唯一的数字。
注:例如,U+12AB指的是在Unicode表中位于12AB处的字符。
3.3
将Unicode分配整数给字符的编码表中的一串字符表示为一串字节的方法。其中,字符采用
1个~4个8比特字节的序列进行编码。仅仅一个8比特字节的一个序列中,字节的高位为0,其他的
7位用于字符值编码。n(n >1)个8比特字节的一个序列中,初始的8比特字节中高n位为1,接着一
位为0,此字节余下的位包含被编码字符值的位。接着的所有8比特字节的最高位为1,接着下一位为
0,余下每个字节6位包含被编码字符的位。
3.4
中文域名 Chinesedomainname
含有中文字符的域名。
[来源:GB/T 44266-2024,3.1.2]
3.5
信息 message
一个字符串,它被一个用户(发送者)利用特定的电子邮件地址发送到另一个或者多个接收电子邮
件地址(接收者)。
3.6
一种邮件扩展机制,该机制允许电子邮件除包含一般纯文本以外,还可含有图片、声音、视频或二进
制格式的文件。
3.7
电子邮件地址“@”的左半部分。
3.8
电子邮件地址“@”的右半部分。
3.9
邮局协议第三版本 postofficeprotocol-version3;POP3
客户端收取存在服务器上电子邮件的技术协议,支持离线邮件的处理。
3.10
一种协议,规定了对基于安全连接的协议增加认证支持的方法。
4 缩略语
下列缩略语适用于本文件。
POP:邮局协议(PostOfficeProtocol)
本文件对IETFRFC1939和IETFRFC2449规定的POP3协议扩展机制进行扩展,从而允许使用
包含通用字符并用UTF-8编码方式存储的字符的国际化邮件头部。本文件同时增加了一个支持非
ASCII用户名和密码的机制和一个支持使用适合用户语言表示的UTF-8编码协议层错误信息的机制。
本文件中,“向下兼容”指将包含 UTF-8头部或8比特内容传输编码的消息体转换成符合
GB/T 1988-1998的文本和其他7比特编码邮件头部扩展的7比特网络消息格式的过程。“向下兼
容”应符合IETFRFC6857和IETFRFC6858规定的国际化电子邮件向下兼容机制。UTF-8表示编
码方法,UTF8表示用来操作UTF-8的命令。
6 协议要求
6.1 总体要求
POP3邮件服务器可能从邮件投递代理服务器收到邮件后进行储存。本文件要求更新现有的
POP3协议,以允许中文电子邮件的收取。下面具体从POP3服务器端和客户端来规定。电子邮件的
中文域名部分应符合GB/T 44266-2024的要求。
6.2 LANG能力
根据POP3扩展机制,本文件增加了一个新的能力响应标识符来支持新的命令:LANG。新增的能
力标识符和命令规定如下:
a) CAPA标签:LANG;
b) CAPA标签参数:none;
c) 新增命令:LANG;
d) 受影响的标准命令:Al;
e) 宣示的状态/可能的区别:both/no;
f) 本状态中有效的命令:AUTHENTICATION,TRANSACTION。
POP3允许在大多数的+OK和-ERR服务器响应中包含可读文本,但POP3协议规定,这个可读
文本只能使用符合GB/T 1988-1998的字符。LANG能力和命令允许POP3客户端与服务器协商使
用某种语言来发送可读文本。
广播了LANG能力扩展的POP3服务器应使用IETFRFC2277字符集中定义的“i-default”语言作
为默认语言,直到客户端与服务器协商了另一种服务器支持的语言为止。服务器支持的语言中应包含
“i-default”语言。
LANG命令要求所有随后+OK和-ERR响应中包含的可读文本,应固定使用一种服务器支持的
语言表示。如果LANG命令成功,服务器应返回一个响应。这个响应依次由+OK、一个空格、选择的
语言标识符、一个空格、所选语言表示的可读文本构成。本次和随后的协议层可读文本使用UTF-8字
符集编码。
如果LANG命令失败,服务器返回一个包含-ERR和先前所用语言(一般是i-default)描述的可读
文本的响应。
“*”是特殊的语言范围参数,表示请求使用服务器管理员指定的语言。对于不同的用户,服务器管
理员宜指定不同的语言。
如果客户端的LANG命令没有带参数且POP3服务器向客户端发送了一个肯定响应,那么这个响
应应是由多行构成的。响应的第一行是+OK,其后每行含有一种服务器支持语言的语言标识符,这被
称为语言列表。
为了简化解析,所有的POP3服务器应使用某种特定格式表示语言列表。一个语言列表由应符合
IETFRFC4646的语言标识符,和其后可选的一个空格和使用这种语言描述的UTF-8编码的可读文本
构成(示例参见附录A)。
6.3 UTF8能力
根据POP3扩展机制,本文件增加了一个新的能力响应标识符来支持新的服务器功能,包括一个新
的命令:UTF8。新增的能力标识符、命令和功能规定如下:
a) CAPA标签:UTF8;
b) CAPA标签参数:USER;
c) 新增命令:UTF8;
d) 受影响的标准命令:USER,PASS,APOP,LIST,TOP,RETR;
e) 宣示的状态/可能的区别:both/no;
f) 本状态中有效的命令:AUTHORIZATION;
g) UTF8能力的UTF8命令将会话从7比特模式切换到UTF-8模式。
6.4 UTF8命令
UTF8命令启用 UTF8模式,UTF8命令没有参数。UTF8模式不会影响纯7比特邮箱的邮件。
中文邮箱可在本地存储 UTF8邮件或限制为符合GB/T 1988-1998编码的邮件或混合模式的邮件。
在本地UTF8邮箱中,可存储7比特邮件、使用国际化头部的UTF8邮件和 MIME中定义的8比特内
容传输编码的邮件,MIME应符合IETFRFC2045的规定。在UTF8模式下,UTF8和7比特邮件被
直接发送到客户端(不做兼容处理)。在非UTF8模式下,本地UTF8邮箱中的UTF8邮件应使用电子
邮件地址国际化的兼容机制做向下兼容处理,以符合未扩展的POP3协议和互联网消息格式。POP服
务器没有强制要求使用电子邮件地址向下兼容机制。
注意即使在UTF8模式下,MIME二进制内容传输编码仍然是不允许的。MIME八比特内容传输
编码是允许的。
在LIST命令响应中报告的消息包含八比特组的数量,应与服务器在RETR命令响应中发送的准
确八比特组数量一致。其他地方关于数据大小的报告,例如在STAT的响应中和在“+OK”后面状态
指示中含有的各种格式的文本大小不需要是准确值,但宜是准确值。
邮件存储(MS)以7比特格式或UTF-8格式存储邮件,客户端可发送UTF8命令,也可不发送。如
果邮件是UTF-8邮件但是客户端没有发送UTF-8命令,那么POP服务器应对其进行向下兼容处理。
对于向下兼容,服务器可采取多种策略,包括何时进行向下兼容,是否缓存或保存消息的向下兼容形
式,是否计算或保留一个与向下兼容内容无关的向下兼容邮件的大小。如果服务器并不立刻访问向下
兼容后邮件的准确大小值,那么估算这个值可能比计算这个值更快。服务器可采用估算的方式确定邮
件大小值。如果服务器采用估算的方式,并且估算的浏览列表中大小值小于其实际值,这可能对某些客
户端产生影响。服务器宜报告邮件的准确大小值。如果无法准确估值大小,那么服务器应估计一个较
大的猜测值。
客户端不能在发送 UTF8命令后发送 STLS命令。对于在成功发送 UTF8命令后发送的
STLS命令,服务器可能强制使用“-ERR”响应拒绝。
6.5 UTF8能力的USER参数
如果UTF8能力中包含USER参数,这表示服务器应接受 UTF-8用户名和密码。在 UTF8能力
响应中包含USER参数的服务器,应对 USER和PASS命令的参数使用SASL预处理,SASL应符合
IETFRFC4013的规定。
支持APOP且允许在用户名或密码中使用UTF8字符的客户端或服务器应对用于计算APOP摘
要的用户名和密码使用SASL预处理。
当应用SASL预处理时,服务器应拒绝含有SASL预处理中列出Unicode字符中的一些特殊字符。
当对USER参数、PASS参数或APOP用户名参数应用SASL预处理时,POP服务器或客户端应把它
们看作查询字符串。当对APOP密码参数使用SASL预处理时,POP服务器或客户端应把它们看作存
储字符串。
如果在UTF8能力响应中没有明确包含 USER参数,否则客户端不应在 USER,PASS或APOP
命令中包含UTF-8字符。服务器应拒绝没有正确遵循 UTF-8语法规则的 UTF-8用户名或密码。如
何在AUTH命令中使用UTF-8由POP3SASL机制控制。
6.6 UTF8响应码
UTF8响应码:国际化邮局协议为POP协议增加一个 UTF8响应码,响应码的格式和使用方式
如下:
a) 完全响应码:UTF8;
b) 在响应中有效:ERR;
c) 在命令中有效:LIST,TOP,RETR。
UTF8的响应码的具体含义是客户端需要接受UTF-8格式的字符串信息,但是客户端不在UTF-8
模式。在客户端进入UTF-8模式后,客户端宜重新发送请求命令。
6.7 本地UTF8信箱
当POP3服务器使用本地 UTF8邮箱且在非 UTF8模式下,服务器应当符合IETFRFC1939的
POP3基本规则和ETFRFC5322规定的互联网邮件格式规则。在中文电子邮件地址中含有中文字符。
中文字符存在着“变体”,同一个字可能有多种表示方式,这样可能导致某些中文字符可能被认为是同一
个字符,但在计算机使用的字符集中,同一个概念上的字符会通过几个不同的码位来识别。外形相同的
字符,或者是有相同或相似语义却被分配了不同码位的字符有可能使用户产生混淆。电子邮件地址分
为电子邮件地址本地部分和电子邮件地址域名部分。为了防止混淆和钓鱼行为,本地的UTF8邮箱在
注册管理时有必要采取相应的措施使中文电子邮件地址本地部分的简繁体(变体)等名字在收发邮件时
是等效的。对每个成功注册的中文电子邮件地址的本地UTF8邮箱应根据中文异体对照表,生成一个
本地(Localpart)包。本地(Localpart)包内的所有本地(Localpart)名字字段归同一个邮件注册人持
有。电子邮件地址域名部分应符合GB/T 44266-2024中文域名的相关规定。
附 录 A
(资料性)
PO......
|