GB/T 46467-2025 中文电子邮件地址 交互式邮件存取协议（IMAP）技术要求

　　ICS 33. 040.40 CCS M 32

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 46467—2025

　　中文电子邮件地址 交互式邮件存取协议

　　(IMAP)技术要求

　　Chineseinternetemailaddress—Technicalrequirementforinternet

　　messageaccessprotocolto support

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

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

　　

　　发

　　

　　布

　　GB/T 46467—2025

　　目 次

　　前言 Ⅲ

　　1 范围 1

　　2 规范性引用文件 1

　　3 术语和定义 1

　　4 缩略语 2

　　5 协议基础 2

　　6 协议要求 2

　　6. 1 总则 2

　　6. 3 UTF8= APPEND 能力 3

　　6. 2 UTF8= ACCEPT 能力 2

　　6. 4 LOGIN命令 3

　　6. 6 和传统客户端交互 3

　　6. 5 UTF8= ONLY 能力 3

　　6. 7 本地 UTF8信箱 4

　　参考文献 5

　　Ⅰ

　　GB/T 46467—2025

　　前 言

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

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

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

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

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

　　Ⅲ

　　GB/T 46467—2025

　　中文电子邮件地址 交互式邮件存取协议

　　(IMAP)技术要求

　　1 范围

　　本文件规定了在互联网体系 上 使 用 交 互 式 邮 件 存 取 协 议(IMAP) 支 持 中 文 电 子 邮 件 地 址 的 技 术要求 。

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

　　2 规范性引用文件

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

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

　　GB/T 44266—2024 中文域名总体技术要求

　　IETF RFC 3501

　　互联网消息访问协 议 版 本 4 修 改(Inernet Message Access Protocol—VER-

　　SION 4rev1)

　　IETF RFC5198

　　用于网络交换的通用字符格式(Unicode Formatfor Network Interchange)

　　IETF RFC 5322

　　互联网信息格式(InternetMessage Format)

　　IETF RFC 6857

　　国际化邮件信息投递后降级机制(Post-Delivery Message Downgrading for In-

　　ternationalized EmailMessages)

　　IETF RFC 6858 国际化邮件邮局协议和交互式邮件存取协议简单降级机制(Simplified POP and IMAP Downgrading for Internationalized Email)

　　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

　　GB/T 46467—2025

　　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

　　中文域名 Chinesedomain name

　　含有中文字符的域名 。

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

　　信息 message

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

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

　　交互式邮件存取协议 internetmessageaccessprotocol:IMAP

　　一种互联网消息访问协议 ,该协议允许客户端对服务器上的电子邮件消息进行访问与操作 ,对邮箱(即远程邮件文件夹)进行操作 ,该协议具备离线功能 ,支持客户端与服务器重新同步 。

　　4 缩略语

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

　　MDA: 邮件投递代理(MailDelivery Agent)

　　SMTP:简单邮件传输协议(Simple MailTransferProtocol)

　　5 协议基础

　　本文件对 IETF RFC 3501规 定 的 IMAP 协 议 进 行 扩 展 , 从 而 允 许 使 用 包 含 通 用 字 符 八 位 编 码UTF-8字符的国际化邮件头部 。支持本文件的系统默认工作在完全支持通用字符 UNICODE 的环境中 。 电子邮件的中文域名部分应符合 GB/T 44266—2024中文域名总体技术要求 。

　　本文件中 “向下兼容 ”指 : 将 包 含 UTF-8头 部 或 8 比 特 内 容 传 输 编 码 的 消 息 体 转 换 成 符 合 GB/ T 1988—1998的文本和其他 7 比特编码邮件头部扩展的 7 比特网络消息格式的过程 。 “向下兼容 ”应符合 IETF RFC 6857和 IETF RFC 6858中的国际化电子邮件向下兼容机制要求 。UTF-8表示编码方法 ,UTF8表示用来操作 UTF-8的命令 。

　　6 协议要求

　　6. 1 总则

　　IMAP 邮件服务器可能从代理邮件 服 务 器 收 取 邮 件 并 进 行 储 存 。 本 文 件 要 求 更 新 现 有 的 IMAP协议 , 以允许中文电子邮件的收取 。下面具体从 IMAP服务器端和客户端来规定 。

　　6.2 UTF8=ACCEPT能力

　　用 UTF(“U)T-8F信(8)L(C)IS(EP)T(T)和 LSU(”能力表)B(明)命(服)令(务)进行回复(器 SELE)。CT 和 EXAMINE命令应支持 UTF-8引用串 ,应支持

　　2

　　GB/T 46467—2025

　　符串客,该命令只能在(户端应使用)“服务器已(ENABLE)认 证的状(UTF8)后使用(ACCEP)T。”命令 , 向服务器表明 , 客户端接受 UTF-8格式的字参数的字符串(如果服务)器。广播了“UTF8= ACCEPT”能力 ,客户端可能仍然使用 “引用格式 ”语法来发送任何带

　　如果 “引用格式 ”中的字符串中使用了 GB/T 1988—1998范围之外的字符 ,将导致报错 ,报错的结果将与 “语法有效但是语义无效 ”的字符串相同 。

　　IETF RFC3501的 5. 1. 3 中规定的邮箱名的服务器应接受引用的 UTF-8格式的邮箱名并且把它们转换

　　所有广播了“UTF8= ACCEPT”能力的 IMAP服务器应接受含有 UTF-8 的邮箱名 。那些支持在

　　成合适的内 部 格 式 。 邮 箱 名 应 符 合 IETF RFC5198 的 第 2 部 分 规 定 , 并 禁 止 包 含 控 制 字 符 (U+

　　0000-U+001F,U+0080-U+009F) , 删 除(U+007F) , 行 分 隔 符(U+2028) 或 者 段 分 隔 符(U+

　　2029) 。

　　SEARCH命令(IMAP客户)。端如果(已) I(经)M(明)AP服务(确 使 用)器(了)接“收到(UTF)一8这样的命令(ACCEPT”能),它(力)应, 使用 BAD回复拒(它不应使用带字)绝(符)这(集)个命令(参 数)语。本(法)文(的)

　　件规定使用 SEARCH 命令时候应不允许携带字符集参数 。

　　6.3 UTF8=APPEND 能力

　　UTF如-8头(果)部(服)务。客(器)户(广)端发(播了)送“UT一个(F8)TF(AP)-8头部的(PEND”)消(能)息(力),到(那)服务器应使(么 服 务 器)用(应)接“UTF8(受 A)P”数据扩展(PEND命)。令 消 息 参 数 中的

　　力 , 客户端在使用 APPEND和 CA(如果服务 器 同 时 支 持"UTF8)ENATE(APPEN)命(D)"令时(能力)候(和)可( I)以使用相(ETFRFC)同4的数据扩展(469中 的 规)定。APPE(的 CA)N(T)D(E)数据(NAT)扩(E)展(能)

　　和 CATENATE扩展的 ABNF范式规定如下 :

　　append-data = /utf8-literal

　　utf8-literal = "UTF8" SP "( " literal8 ") "

　　cat-part = /utf8-literal

　　没有广播“UTF8= APPEND”能力的服务器应当使用“NO”回复码 , 以拒绝一个头部中包含任何 8

　　比特字符的信息 。

　　6.4 LOGIN命令

　　本文件没有对“LOGIN”命令进行扩展以支持 UTF-8的用户名和密码 。客户端不应使用带 UTF-8参数的“LOGIN”命令 。如果客户端应使用 UTF-8 的用户 名 或 密 码 , 应 使 用 “AUTHENTICATE”命令 ,这个命令已经能够支持 UTF-8的用户名和认证 。虽然使用 “AUTHENTICATE”命令在句法上能够支持 UTF-8的用户名或密码 ,但是服务器可能不进行这样的用户配置 。

　　6.5 UTF8=ONLY 能力

　　符串“。特别(UTF8),这表示(ONLY)”服务器将只接受 UTF(能力表明服务器支持)“-8(U),它不(TF8)受旧的(CEPT)”U,T(它)F(宜)-7格式的字(支持从客户)如果(送的)想让(UTF)-服(8)务(字)

　　-8果“”-”““F”给(明)”

　　6.6 和传统客户端交互

　　在大多数情况下 , IMAP服务器不知道所有可能访问它的客户端的具体情况 , 因此服务器应做好与各种客户端交互的准备 ,不管这些客户端支持本文件中规定的 UTF-8能力与否 。 当一个消息需要

　　3

　　GB/T 46467—2025

　　UTF-8能力 ,但是客户端不具备 UTF-8能力的时候 ,服务器需要根据 IETF RFC6857中的规定来处理这些信息 。

　　6.7 本地 UTF8信箱

　　当 IMAP服务器使用本地 UTF8邮箱且在非 UTF8模式下 ,服务器应当符合 IMAP基本文件和互联网邮件格式文件应符合 IETF RFC5322。 在中文电子邮件地址中含 有 中 文 字 符 。 中 文 字 符 存 在 着“变体 ”, 同一个字可能有多种表示方式 ,这样可能导致某些中文字符可能被认为是同一个字符 ,但在计算机使用的字符集中 , 同一个概念上的字符会通过几个不同的码位来识别 。外形相同的字符 ,或者是有相同或相似语义却被分配了不同码位的字符有可能使用户产生混淆 。 为了防止混淆和钓鱼行为 ,本地的 UTF8邮箱在注册管理时有必要采取相应的措施使中文电子邮件地址本地部分的简繁体(变体) 等名字在收发邮件时是等效的 。对每个成功注册的中文电子邮件地址的本地 UTF8 邮箱应根据中文异体对照表 ,生成一个本地 Localpart包 。Localpart包内的所有 Localpart名字字段归同一个邮件注册人持有 。

　　4

　　GB/T 46467—2025

　　参 考 文 献

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

　　[2] GB/T 46465—2025 中文电子邮件地址 邮局协议(POP)技术要求

　　[3] IETF RFC 2045 MultipurposeInternetMailExtensions(MIME) PartOne:FormatofIn- ternetMessageBodies Status

　　[4] IETF RFC 4469 InternetMessage Access Protocol (IMAP) CATENATE Extension

　　5