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

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

国家标准 GB/T32397一2015 中文电子邮件地址 邮件头格式技术要求 Chineseinternetemailaddress一Technmicalspecificationfor emailheaderstosupport 2015-12-31发布 2016-07-01实施 中毕人民共和国国家质量监督检验检疫总局 发布 中 国国家标准化管厘委员会国家标准
GB/T32397一2015 前 言 本标准为《中文电子邮件地址》系列标准之一,该系列标准的结构和名称预计如下: 中文电子邮件地址框架结构总体技术要求 中文电子邮件地址简单邮件传输协议(SMTP)扩展技术要求 中文电子邮件地址邮件头格式技术要求 中文电子邮件地址邮局协议(POP)技术要求 中文电子邮件地址交互式邮件存取协议(IMAP)技术要求 本标准按照GB/T1.1一2009给出的规则起草 本标准由工业和信息化部提出 本标准由通信标准化协会归口 本标准起草单位;互联网络信息中心 本标准主要起草人:姚健康、毛伟、李晓东、沈烁、孔宁、刘冰
GB/T32397一2015 中文电子邮件地址 邮件头格式技术要求 范围 本标准规定了在互联网体系上使用中文电子邮件地址中的邮件头的技术要求 本标准适用于各级电子邮件地址注册管理机构、电子邮件地址服务提供商以及软件厂商开发支持 中文电子邮件地址的应用或者服务等 规范性引用文件 下列文件对于本文件的应用是必不可少的 凡是注日期的引用文件,仅注日期的版本适用于本文 件 凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件 IETFRFC1939邮局协议第三版本(PostofficeprotocolVersion3 IE:TFRFC2045多目标互联网邮件扩展第一部分;互联网消息主体格式(Multipurposeinternet mailextensions(MIME)Part1:Formatofinternetmessagebodies) IETFRFC2821简单邮件传输协议(Simplemailtransferprotoeol IETFRFC2822互联网信息格式(Internetmessageformat) IETFRFC3492 -种适用于国际化域名应用的对UNIcODE的编码方法:Punycode[Punycode: ABootstringencodingofunicodeforinternationalizeddomainnamesinapplications(IDNA] -Ve IETFRFC3501互联网信息交互协议第四版本(Internetmessageaccessprotocol ersion4 IETFRFC6531SMTP扩展支持国际化电子邮件地址技术要求(SMTPExtensionforInterna- tionalizedemai 注:IETF即互联网工程任务组(InternetEngineeringTaskForce),ISO承认的国际标准化机构或组织之 术语和定义 下列术语和定义适用于本文件 3.1 电子邮件 eleetronicmail 在计算机网络上,用户终端之间往来的信丽 3.2 邮件投递 MTA 种SMTP服务器,它从网络接受信息投递给邮箱或者其他本地过程,或其他服务器 3.3 通用字符 Unicodecharacter Unicode根据其位置或码位来识别字符,给每个字符提供的一个唯一的数字 例如,U十12AB指 在Unicode3.2表中位于12AB处的字符 本标准参考了Unicode标准3.2版本(等同于ISO10646) Unicode字符集包含AsCI1字符集
GB/T32397一2015 3.4 通用字符八位编码UF-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 信息 mesSge 个信息是从一个用户(发送者)利用特定的电子邮件地址发送到另一个或者多个接收电子邮件地 址(经常仅仅称作用户或接收用户) 3.7 域名编码算法punyeode -种编码转换规则 运用这种规则应可实现Unicode字符串和AsCI字符串的相互转换,具体要 求见IETFRFC3492. 3.8 chineseemailaddres 中文电子邮件系统 sssystem 支持本标准的邮件系统 3.9 localpart 电子邮件地址本地部分 电子邮件地址“@”的左半部分 3.10 电子邮件地址域名部分domainpart 电子邮件地址“@”的右半部分 3.11 简单邮件传输协议 SMTP IETFRFC2821规定的邮件传输协议 3.12 兼容ASCI的编码 ACE 利用一些算法把不兼容AsCI的编码转成兼容AscI的编码 3.13 交互邮件存取协议I1AP IETFRFC3501规定的互联网信息交互协议 3.14 邮局协议 POP IETFRFC1939规定的邮局协议 协议概述 邮箱名通常代表了人名 当使用ASCII字符集无法表达世界上不同国家的所有人的名字,更倾向
GB/T32397一2015 于在发送和接收邮件时,在名字和邮件标题中使用非AsCI文本 此时邮件协议使用UTF-8作为邮 件头部域的编码标准 邮件消息的传统格式规定在头部域中使用ASC字符集,禁止在普通名字,注释及自由文本(如邮 件标题域)中使用非ASC文本 本标准规定了允许在多数邮件头部域中使用非AscC字符 这些改 变会影响SMTP客户端,SMTP服务器,邮件用户代理(MUAs),控制列表,网关和其他解析或者处理 邮件消息的所有方面 在IETFRFC6531规定了“SMTPUTF8”用来声明服务器是否支持SMTP扩展,用来防止将UTF 8头部域的消息投递到无法处理该邮件的系统上 并且使用此SMTP扩展有助于防止邮件纳人消息存 储系统时被不正确的解析,显示和分割 要注意到使用ESMTP扩展并不阻止带UTF-8头部域的邮件 传输到不支持POP和IMAP扩展的服务器上 本标准的目标是允许在邮件头部域中使用UTF-8字符集 协议要求 5.1 总体要求 本标准要求更新现有的电子邮件地址的格式以便允许中文电子邮件地址的显示和传输 下面具体 从电子邮件地址格式的邮件头来具体要求协议的实现 -旦SMTP服务器声明了sMTPUTF8扩展,或者有其他传输机制允许的情况,SMTP客户端就 可以对邮件的头部域采用UTF-8格式编码 本标准不改变IETFRFC2822中定义头部名字的规则 头部域的字段内容允许包含UTF-8字符， 但是头部域名字本身还只能是ASC字符 为了允许在头部域的值中包含UTF-8字符,IETFRFC2822中定义的头部定义需要扩充以支持新 格式 以下的ABNF规范用来代替IETFRFC2822中的相关定义 未涉及到的部分维持原来的定义 5.2UTF-8语法规范 UTF-8字符可以用下面的ABNF通过八位字节的术语来定义 UTF8-non-asci UTF8-2/UTF8-3/UTF8-小 UTF8-2 %xC2-DFUTF8-tai %xE0%xA0-IBFUTF8-tail UTF8-3 %xE1-EC2(UTF8-tail/ %xED%x80-9FUTF8-tail %xEEEF2(UTF8-tailD) UTF8-4 %xFo%x90-BF2(UTF8-tail %xF1-F33(UTF8-tail %xF4%x80-8F2UTF8-tail UTF8-tait %x80-BF
GB/T32397一2015 5.3MIM头部变化 传统的电子邮件头部域,是禁止对所有的message/的子类使用内容传输编码的 国际化电子邮件 的头部域允许新定义的MIME类型使用内容传输编码,允许nmessage/global使用内容传输编码 正常情况下,message/global的传输在纯8-bit通道中,body部分有“身份"编码,这就意味着解码 是不必要的 如果遇到了包含message/global的消息经过了兼容性处理,从8-bit降级为7-bit,可能会 对该消息编码;如果该消息多次经过了7-bit环境和支持SMTPUTF8扩展的环境,多层次编码可能就 会发生 这种情况在实际应用中应该极少出现,而且使用其他处理该问题的方法比起允许嵌套编码的 方法,其潜在的复杂性更大 5.4对IETRFC2822的扩展语法 以下语法扩展了IETFRFC2822中相应的规则,允许使用UTF-8字符 VCHAR UTF8=non=asci UTF8-non=asei ctext UTF8-non=asei atext UTF8-non-asci qtext UTF8-non-asci eXt UTF8-non-asci dtext 这意味着所有建立在这些基础上的结构都允许UTF8字符,包括注释和引号字符串 我们不改变 语法,以便允许中使用UTF8字符 为了允许在中使用UTF-8 字符,就需要增加满足这个需求 utf8-text %d1-9 %d11-12 %d14-127 UTF8-non-asci utf8-quotedpair ut8-text) obs-qp utf8-qcontent utf8-qtext/utf8-quotedpair [[CFws utf8-quoted-string DQUOTE关([Fws]utf8-qcontent)[Fws]DQU(oTE [CFws utf8-ccontent ctext/utf8-quoted-pair/comment qtext/UTF8-non-asei utf8-qtext
GB/T32397一2015 ALPHA/DGIT utf8-atext "井"/，所有字符,除了控制字符 "$" "%"/;SP,和特殊字符 UTF8-xtra-char utf8-atom [CFws]1关utf8-atext[CFws utf8-dotatom=[CFws]utf8-dot-atom-text[CFwS utf8-dotatom-text =1*utf8-atext关"”1*utf8-atext utf8-qgcontent qcontent ontent-De: 为了使内容描述(Con )eseription)头部域[RFC2045]能够使用UTF-8字符,使用了下面的 语法 "Co1 description ontemtIDescription”unstrueturedCRILF 上面语法的扩展是用来允许在头部域中使用UTF-8字符 虽然扩展了部分语法,但是要注意的是,这并没有删除任何关于协议元素字符集的限制 比如， Date中时区的所有允许的值,邮件头部域名称仍然用ASCI字符表达 5.5新增message/global类型 国际化的邮件必须在电子邮件地址国际化扩展的授权下或者支持这些邮件的非SMTP环境下传 输 如果一封邮件头部域的值包含了UTF-8字符或者邮件正文部分的头部包含了UTF-8字符,那么 这封邮件定义为一封“message/global message message/global类型类似于 /rfe822,不同的是，邮件里可以在头部或者正文部分包含 message/ UTF-8字符 如果发送给一个只支持7-bit的系统,那么必须按照IETFRFC2045的规定进行编码 另一种选择，SMTP服务器或者其他传输message/global邮件正文部分的系统,可以选择把邮件 nmessage/rfe822正文部分,称为向下兼容 向下转换成" 类型名;message 子类型名:global 必需参数:无 可选参数;无 编码考虑;任意内容传输编码都可行 注8-bit或二进制内容传输编码在允许的地方优先使用 互操作考虑;媒体类型对国际化电子邮件提供的功能与message/rfe822内容类型对普通电子邮件
GB/T32397一2015 提供的功能类似 当需要在另外一个消息中嵌人或者返回此类消息,可以使用此媒体类型,而不用改变 其内容或向下转换成message/rfe822 这些选择都会与已经安装的系统互操作,只不过是针对不同的 方面 不识别国际化电子邮件头部的系统对message/global的处理是把它当作未知附件,因为他们只 能识别tmessage/rfc822结构 然而,理解nmessage/global的系统将提供这样一种功能,它优先于采用 对message/rfc822进行向下转换方法得到的结果 如何达到最大的互操作取决于部署的软件 使用媒体类型的应用:SMTP服务器,或者ermail客户端,它们要么支持产生multipart/report,要 么解析能把带国际化邮件头部的消息当作附件来转发的email客户端 5.6安全考虑 因为UTF-8使用八位组来对一个字符编码,国际化邮件地址的本地部分长度变得比原来的更大 每行字符串必须不能超过998个八位组(不包含回车键CRLF) 由于长度变大了,要注意在解析,存储 和处理邮件地址时避免缓冲区溢出,地址截断或超出存储分配的错误 当然,在比较电子邮件地址时也 要注意使用地址的全部长度 UTF-8邮件头部对邮件签名系统的安全影响,比如DomainKeysldentifiedMailDKIM)，S/ MIME，和OpenPGP

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

随着Internet的普及，电子邮件成为了人们日常生活中不可或缺的一部分。而在众多的互联网应用中，邮件的传输方式显得尤为重要。邮件头格式作为邮件传输的一个必要组成部分，对于邮件的安全性、完整性和可靠性都起着至关重要的作用。 目前，邮件头格式已经被规范化为RFC 822标准，但是该标准并没有考虑到中文电子邮件地址这种特殊情况。因此，为了保证中文电子邮件地址的正确传输，我国制定了《中文电子邮件地址邮件头格式技术要求GB/T32397-2015》标准。 根据该标准规定，中文电子邮件地址的邮件头格式应当遵循以下规则： 1. 中文电子邮件地址应当使用RFC 822规定的“<>”来括起来，例如：<张三@163.com>。 2. 中文电子邮件地址中的中文字符应当使用UTF-8编码。 3. 邮件头中的主题（Subject）一项应该使用Base64编码。 4. 发送时间（Date）应该遵循RFC 822标准。 5. 发送者（From）、接收者（To）和抄送（cc）等地址信息应该使用英文半角状态下的逗号“,”隔开。 6. 如果需要在邮件头中添加附件，则应该使用MIME消息格式。 通过上述规则，我们可以保证中文电子邮件地址的正确传输和识别，在日常工作和生活中更加方便快捷地进行邮件通讯。 总之，中文电子邮件地址邮件头格式技术要求GB/T32397-2015标准的出台，对于我国互联网电子邮件事业的发展和进步起到了重要的促进作用。希望今后有更多的标准能够不断涌现，为互联网产业的发展和完善贡献力量。

中文电子邮件地址邮件头格式技术要求的相关资料

和中文电子邮件地址邮件头格式技术要求类似的标准

GB/T32398-2015

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

2022/10/17 13:01:38 现行

GB/T32397-2015

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

2022/10/17 12:54:16 现行