ICS33.040.40 M32 中华人民共和国国家标准 GB/T32397—2015 中文电子邮件地址 邮件头格式技术要求 Chineseinternetemailaddress—Technicalspecificationfor emailheaderstosupport 2015-12-31发布 2016-07-01实施 中华人民共和国国家质量监督检验检疫总局 中国国家标准化管理委员会发布前 言 本标准为《中文电子邮件地址》系列标准之一,该系列标准的结构和名称预计如下: ———中文电子邮件地址 框架结构总体技术要求 ———中文电子邮件地址 简单邮件传输协议(SMTP)扩展技术要求 ———中文电子邮件地址 邮件头格式技术要求 ———中文电子邮件地址 邮局协议(POP)技术要求 ———中文电子邮件地址 交互式邮件存取协议(IMAP)技术要求 本标准按照GB/T1.1—2009给出的规则起草。 本标准由工业和信息化部提出。 本标准由中国通信标准化协会归口。 本标准起草单位:中国互联网络信息中心。 本标准主要起草人:姚健康、毛伟、李晓东、沈烁、孔宁、刘冰。 ⅠGB/T32397—2015 中文电子邮件地址 邮件头格式技术要求 1 范围 本标准规定了在互联网体系上使用中文电子邮件地址中的邮件头的技术要求。 本标准适用于各级电子邮件地址注册管理机构、电子邮件地址服务提供商以及软件厂商开发支持 中文电子邮件地址的应用或者服务等。 2 规范性引用文件 下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文 件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。 IETFRFC1939 邮局协议第三版本(Postofficeprotocol—Version3) IETFRFC2045 多目标互联网邮件扩展 第一部分:互联网消息主体格式(Multipurposeinternet mailextensions(MIME)Part1:Formatofinternetmessagebodies) IETFRFC2821 简单邮件传输协议(Simplemailtransferprotocol) IETFRFC2822 互联网信息格式(Internetmessageformat) IETFRFC3492 一种适用于国际化域名应用的对UNICODE的编码方法:Punycode[Punycode: ABootstringencodingofunicodeforinternationalizeddomainnamesinapplications(IDNA)] IETFRFC3501 互联网信息交互协议第四版本(Internetmessageaccessprotocol—Version4) IETFRFC6531 SMTP扩展支持国际化电子邮件地址技术要求(SMTPExtensionforInterna- tionalizedemail) 注:IETF即互联网工程任务组(InternetEngineeringTaskForce),ISO承认的国际标准化机构或组织之一。 3 术语和定义 下列术语和定义适用于本文件。 3.1 电子邮件 electronicmail 在计算机网络上,用户终端之间往来的信函。 3.2 邮件投递 MTA 一种SMTP服务器,它从网络接受信息投递给邮箱或者其他本地过程,或其他服务器。 3.3 通用字符 Unicodecharacter Unicode根据其位置或码位来识别字符,给每个字符提供的一个唯一的数字。例如,U+12AB指 在Unicode3.2表中位于12AB处的字符。本标准参考了Unicode标准3.2版本(等同于ISO10646)。 Unicode字符集包含ASCII字符集。 1GB/T32397—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 中文域名 chinesedomainname 含有中文域名字段的域名。 3.6 信息 message 一个信息是从一个用户(发送者)利用特定的电子邮件地址发送到另一个或者多个接收电子邮件地 址(经常仅仅称作用户或接收用户)。 3.7 域名编码算法 punycode 一种编码转换规则。运用这种规则应可实现Unicode字符串和ASCII字符串的相互转换,具体要 求见IETFRFC3492。 3.8 中文电子邮件系统 chineseemailaddresssystem 支持本标准的邮件系统。 3.9 电子邮件地址本地部分 localpart 电子邮件地址“@”的左半部分。 3.10 电子邮件地址域名部分 domainpart 电子邮件地址“@”的右半部分。 3.11 简单邮件传输协议 SMTP IETFRFC2821规定的邮件传输协议。 3.12 兼容ASCII的编码 ACE 利用一些算法把不兼容ASCII的编码转成兼容ASCII的编码。 3.13 交互邮件存取协议 IMAP IETFRFC3501规定的互联网信息交互协议。 3.14 邮局协议 POP IETFRFC1939规定的邮局协议。 4 协议概述 邮箱名通常代表了人名。当使用ASCII字符集无法表达世界上不同国家的所有人的名字,更倾向 2GB/T32397—2015 于在发送和接收邮件时,在名字和邮件标题中使用非ASCII文本。此时邮件协议使用UTF-8作为邮 件头部域的编码标准。 邮件消息的传统格式规定在头部域中使用ASCII字符集,禁止在普通名字,注释及自由文本(如邮 件标题域)中使用非ASCII文本。本标准规定了允许在多数邮件头部域中使用非ASCII字符。这些改 变会影响SMTP客户端,SMTP服务器,邮件用户代理(MUAs),控制列表,网关和其他解析或者处理 邮件消息的所有方面。 在IETFRFC6531规定了“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字符,IETFRFC2822中定义的头部定义需要扩充以支持新 格式。以下的ABNF规范用来代替IETFRFC2822中的相关定义。未涉及到的部分维持原来的定义。 5.2 UTF-8语法规范 UTF-8字符可以用下面的ABNF通过八位字节的术语来定义: UTF8-non-ascii = UTF8-2/UTF8-3/UTF8-4 UTF8-2 =%xC2-DFUTF8-tail UTF8-3 =%xE0%xA0-BFUTF8-tail/ %xE1-EC2(UTF8-tail)/ %xED%x80-9FUTF8-tail/ %xEE-EF2(UTF8-tail) UTF8-4 =%xF0%x90-BF2(UTF8-tail)/ %xF1-F33(UTF8-tail)/ %xF4%x80-8F2(UTF8-tail) UTF8-tail =%x80-BF 3GB/T32397—2015 5.3 MIME头部变化 传统的电子邮件头部域,是禁止对所有的message/的子类使用内容传输编码的。国际化电子邮件 的头部域允许新定义的MIME类型使用内容传输编码,允许message/global使用内容传输编码。 正常情况下,message/global的传输在纯8-bit通道中,body部分有“身份”编码,这就意味着解码 是不必要的。如果遇到了包含message/global的消息经过了兼容性处理,从8-bit降级为7-bit,可能会 对该消息编码;如果该消息多次经过了7-bit环境和支持SMTPUTF8扩展的环境,多层次编码可能就 会发生。这种情况在实际应用中应该极少出现,而且使用其他处理该问题的方法比起允许嵌套编码的 方法,其潜在的复杂性更大。 5.4 对IETFRFC2822的扩展语法 以下语法扩展了IETFRFC2822中相应的规则,允许使用UTF-8字符。 VCHAR =/ UTF8-non-ascii ctext =/UTF8-non-ascii atext =/UTF8-non-ascii qtext =/UTF8-non-ascii text =/UTF8-non-ascii dtext