GB/T 32397-2015 中文电子邮件地址 邮件头格式技术要求

　　ICS 33. 040.40 M 32

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 32397—2015

　　中文电子邮件地址

　　邮件头格式技术要求

　　Chineseinternetemailaddress—Technicalspecification for

　　emailheadersto support

　　2015-12-31发布 2016-07-01实施

　　中华人民共和国国家质量监督检验检疫总局中 国 国 家 标 准 化 管 理 委 员 会

　　发

　　布

　　GB/T 32397—2015

　　前 言

　　本标准为《中文电子邮件地址》系列标准之一 ,该系列标准的结构和名称预计如下 :

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

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

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

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

　　— 中文电子邮件地址 交互式邮件存取协议(IMAP)技术要求本标准按照 GB/T 1. 1—2009给出的规则起草 。

　　本标准由工业和信息化部提出 。

　　本标准由中国通信标准化协会归 口 。

　　本标准起草单位 : 中国互联网络信息中心 。

　　本标准主要起草人 :姚健康 、毛伟 、李晓东 、沈烁 、孔宁 、刘冰 。

　　中文电子邮件地址

　　邮件头格式技术要求

　　1 范围

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

　　本标准适用于各级电子邮件地址注册管理机构 、电子邮件地址服务提供商以及软件厂商开发支持中文电子邮件地址的应用或者服务等 。

　　2 规范性引用文件

　　下列文件对于本文件的应用是必不可少的 。凡是注 日期的引用文件 ,仅注 日期的版本适用于本文件 。凡是不注日期的引用文件 ,其最新版本(包括所有的修改单)适用于本文件 。

　　IETF RFC1939 邮局协议第三版本(Postoffice protocol—Version3)

　　IETF RFC2045 多目标互联网邮件扩展 第一部分 :互联网消息主体格式(Multipurposeinternet

　　mailextensions(MIME) Part1: Formatofinternetmessage bodies)

　　IETF RFC2821 简单邮件传输协议(Simple mailtransfer protocol)

　　IETF RFC2822 互联网信息格式(Internetmessage format)

　　IETF RFC3492 一种适用于国际化域名应用的对 UNICODE 的编码方法 :Punycode [Punycode: A Bootstring encoding of unicode for internationalized domain names in applications(IDNA)]

　　IETF RFC3501 互联网信息交互协议第四版本(Internetmessage access protocol—Version4)

　　IETF RFC6531 SMTP 扩展支持国际化电子邮件地址技术要 求(SMTP Extension for Interna- tionalized email)

　　注 : IETF即互联网工程任务组(InternetEngineering TaskForce) ,ISO 承认的国际标准化机构或组织之 一 。

　　3 术语和定义

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

　　3. 1

　　电子邮件 electronicmail

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

　　3.2

　　邮件投递 MTA

　　一种 SMTP服务器 ,它从网络接受信息投递给邮箱或者其他本地过程 ,或其他服务器 。 3.3

　　通用字符 Unicodecharacter

　　Unicode根据其位置或码位来识别字符 , 给每个字符提供的一个唯一的数字 。 例如 , U+12AB指在 Unicode 3. 2 表中位于 12AB处的字符 。本标准参考了 Unicode 标准 3. 2 版本(等同于 ISO10646) 。 Unicode字符集包含 ASCII字符集 。

　　GB/T 32397—2015

　　3.4

　　通用字符八位编码 UTF-8

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

　　3.5

　　中文域名 chinesedomain name

　　含有中文域名字段的域名 。

　　3.6

　　信息 message

　　一个信息是从一个用户(发送者)利用特定的电子邮件地址发送到另一个或者多个接收电子邮件地址(经常仅仅称作用户或接收用户) 。

　　3.7

　　域名编码算法 punycode

　　一种编码转换规则 。运用这种规则应可实现 Unicode字符串和 ASCII字符串的相互转换 ,具体要求见 IETF RFC3492。

　　3. 8

　　中文电子邮件系统 chineseemailaddresssystem

　　支持本标准的邮件系统 。

　　3.9

　　电子邮件地址本地部分 localpart

　　电子邮件地址“@ ”的左半部分 。

　　3. 10

　　电子邮件地址域名部分 domain part

　　电子邮件地址“@ ”的右半部分 。

　　3. 11

　　简单邮件传输协议 SMTP

　　IETF RFC2821规定的邮件传输协议 。

　　3. 12

　　兼容 ASCII的编码 ACE

　　利用一些算法把不兼容 ASCII的编码转成兼容 ASCII的编码 。

　　3. 13

　　交互邮件存取协议 IMAP

　　IETF RFC3501规定的互联网信息交互协议 。

　　3. 14

　　邮局协议 POP

　　IETF RFC1939规定的邮局协议 。

　　4 协议概述

　　邮箱名通常代表了人名 。 当使用 ASCII字符集无法表达世界上不同国家的所有人的名字 ,更倾向

　　于在发送和接收邮件时 ,在名字和邮件标题中使用非 ASCII文本 。此时邮件协议使用 UTF-8作为邮件头部域的编码标准 。

　　邮件消息的传统格式规定在头部域中使用 ASCII字符集 ,禁止在普通名字 , 注释及自由文本(如邮件标题域)中使用非 ASCII文本 。本标准规定了允许在多数邮件头部域中使用非 ASCII字符 。这些改变会影响 SMTP客户端 ,SMTP服务器 , 邮件用户代理(MUAs) ,控制列表 , 网关和其他解析或者处理邮件消息的所有方面 。

　　在 IETF RFC6531规定了“SMTPUTF8”用来声明服务器是否支持 SMTP扩展 ,用来防止将 UTF- 8 头部域的消息投递到无法处理该邮件的系统上 。并且使用此 SMTP扩展有助于防止邮件纳入消息存储系统时被不正确的解析 ,显示和分割 。要注意到使用 ESMTP扩展并不阻止带 UTF-8头部域的邮件传输到不支持 POP和 IMAP扩展的服务器上 。

　　本标准的目标是允许在邮件头部域中使用 UTF-8字符集 。

　　5 协议要求

　　5. 1 总体要求

　　本标准要求更新现有的电子邮件地址的格式以便允许中文电子邮件地址的显示和传输 。下面具体从电子邮件地址格式的邮件头来具体要求协议的实现 。

　　一旦 SMTP服务器声明了 SMTPUTF8扩展 ,或者有其他传输机制允许的情况 ,SMTP客户端就可以对邮件的头部域采用 UTF-8格式编码 。

　　本标准不改变 IETFRFC2822中定义头部名字的规则 。头部域的字段内容允许包含 UTF-8字符 ,但是头部域名字本身还只能是 ASCII字符 。

　　为了允许在头部域的值中包含 UTF-8字符 ,IETF RFC2822中定义的头部定义需要扩充以支持新格式 。 以下的 ABNF规范用来代替 IETF RFC2822中的相关定义 。未涉及到的部分维持原来的定义 。

　　5.2 UTF-8 语法规范

　　UTF-8字符可以用下面的 ABNF通过八位字节的术语来定义 :

　　5.3 MIME 头部变化

　　传统的电子邮件头部域 ,是禁止对所有的 message/的子类使用内容传输编码的 。 国际化电子邮件的头部域允许新定义的 MIME类型使用内容传输编码 ,允许 message/global使用内容传输编码 。

　　正常情况下 ,message/global的传输在纯 8-bit通道中 , body部分有 “身份 ”编码 , 这就意味着解码是不必要的 。如果遇到了包含 message/global的消息经过了兼容性处理 ,从 8-bit降级为 7-bit,可能会对该消息编码 ;如果该消息多次经过了 7-bit环境和支持 SMTPUTF8扩展的环境 , 多层次编码可能就会发生 。这种情况在实际应用中应该极少出现 ,而且使用其他处理该问题的方法比起允许嵌套编码的方法 ,其潜在的复杂性更大 。

　　5.4 对 IETF RFC2822的扩展语法

　　以下语法扩展了 IETF RFC2822中相应的规则 ,允许使用 UTF-8字符 。

　　VCHAR = / UTF8-non-ascii

　　这意味着所有建立在这些基础上的结构都允许 UTF-8字符 ,包括注释和引号字符串 。我们不改变< atext>语法 , 以便允许< addr-spec>中使用 UTF8字符 。为了允许在 中使用 UTF-8字符 ,就需要增加满足这个需求 。

　　utf8-text = 9-1/

　　%d14-127/

　　UTF8-non-ascii

　　utf8-quoted-string =DE] * ([FWS] utf8-qcontent) [FWS] DQUOTE

　　[CFWS]

　　utf8-atext = LPHA / DIGIT /

　　"& " / "'" / ;

　　"* " / "+ " /

　　"-" / "/" /

　　"|""""

　　"~ " /

　　UTF8-xtra-char

　　utf8-atom = [CFWS] 1* utf8-atext[CFWS]

　　utf8-dot-atom = [CFWS] utf8-dot-atom-text[CFWS]

　　utf8-dot-atom-text = 1* utf8-atext * ( ". " 1* utf8-atext)

　　为了述(ot--qDciion) 头 部 域[RFC2045] 能 够 使 用 UTF-8 字 符 , 使 用 了 下 面 的

　　语法 :

　　description = "Content-Description: " unstructured CRLF

　　虽然扩展了部分语法 , 但 是 要 注 意 的 是 , 这 并 没 有 删 除 任 何 关 于 协 议 元 素 字 符 集 的 限 制 。 比 如 , Date中时区的所有允许的值 , 邮件头部域名称仍然用 ASCII字符表达 。

　　5.5 新增 message/global类型

　　国际化的邮件必须在电子邮件地址国际化扩展的授权下或者支持这些邮件的非 SMTP环境下传输 。如果一封邮件头部域的值包含了 UTF-8字符或者邮件正文部分的头部包含了 UTF-8字符 ,那么这封邮件定义为一封“message/global message”。

　　message/global类型类似 于 message/rfc822, 不 同 的 是 , 邮 件 里 可 以 在 头 部 或 者 正 文 部 分 包 含UTF-8字符 。如果发送给一个只支持 7-bit的系统 ,那么必须按照 IETF RFC2045的规定进行编码 。

　　另一种选择 , SMTP服务器或者其他传输 message/global邮件正文部分的系统 ,可以选择把邮件向下转换成 message/rfc822正文部分 ,称为向下兼容 。

　　类型名 :message

　　子类型名:global

　　必需参数 :无

　　可选参数 :无

　　编码考虑 :任意内容传输编码都可行 。

　　注 : 8-bit或二进制内容传输编码在允许的地方优先使用 。

　　互操作考虑 :媒体类型对国际化电子邮件提供的功能与 message/rfc822 内容类型对普通电子邮件

　　提供的功能类似 。 当需要在另外一个消息中嵌入或者返回此类消息 ,可以使用此媒体类型 ,而不用改变其内容或向下转换成 message/rfc822。这些选择都会与已经安装的系统互操作 , 只不过是针对不同的方面 。不识别国际化电子邮件头部的系统对 message/global的处理是把它当作未知附件 , 因为他们只能识别 message/rfc822结构 。然而 ,理解 message/global的系统将提供这样一种功能 , 它优先于采用对 message/rfc822进行向下转换方法得到的结果 。如何达到最大的互操作取决于部署的软件 。

　　使用媒体类型的应用 :SMTP服务器 , 或者 email客户端 , 它们要么支持产生 multipart/report,要么解析能把带国际化邮件头部的消息当作附件来转发的 email客户端 。

　　5.6 安全考虑

　　因为 UTF-8使用八位组来对一个字符编码 , 国际化邮件地址的本地部分长度变得比原来的更大 。每行字符串必须不能超过 998个八位组(不包含回车键 CRLF) 。 由于长度变大了 ,要注意在解析 ,存储和处理邮件地址时避免缓冲区溢出 ,地址截断或超出存储分配的错误 。 当然 ,在比较电子邮件地址时也要注意使用地址的全部长度 。

　　UTF-8邮件头部对 邮 件 签 名 系 统 的 安 全 影 响 , 比 如 Domain Keys Identified Mail (DKIM) , S/ MIME, 和 OpenPGP。