GB/T 32398-2015 中文电子邮件地址 简单邮件传输协议扩展技术要求

　　ICS 33. 040.40 M 32

　　中 华 人 民 共 和 国 国 家 标 准

　　GB/T 32398—2015

　　中文电子邮件地址 简单

　　邮件传输协议扩展技术要求

　　Chineseinternetemailaddress—Technical

　　specification forSMTP extension to support

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

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

　　发

　　布

　　GB/T 32398—2015

　　前 言

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

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

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

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

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

　　— 中文电子邮件地址 交互式邮件存取协议(IMAP)技术要求 。

　　本标准按照 GB/T 1. 1—2009给出的规则起草 。

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

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

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

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

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

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

　　1 范围

　　本标准规定了在互联网体系上使用 SMTP扩展支持中文电子邮件地址的技术要求 ,从服务器端提出相应的技术规范 。

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

　　2 规范性引用文件

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

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

　　IETF RFC1034 域名-概念和设施(Domain names-conceptsand facilities)

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

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

　　IETF RFC3464 传 送 状 态 通 知 的 可 扩 展 消 息 格 式 (An extensible message format for delivery status notifications)

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

　　IETF RFC4409 邮件消息提交(Message submission for mail)

　　IETF RFC6533 国 际 化 交 付 情 况 和 部 署 通 知 (Internationalized delivery status and disposition notifications)

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

　　3 术语和定义

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

　　3. 1

　　电子邮件 electronicmail

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

　　3.2

　　邮件投递 MTA

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

　　通用字符 unicodecharacter

　　Unicode根据其位置或码位来识别字符 , 给每个字符提供的一个唯一的数字 。 例如 , U+12AB指在 Unicode 3. 2 表中位于 12AB处的字符 。Unicode字符集包含 ASCII字符集 。

　　GB/T 32398—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的编码 。

　　4 协议概述

　　中文电子邮件地址包括两部分 ,本地部分和域名部分 。互联网协议使用电子邮件地址的方法与使用域名的方法是不同的 。最显著的不同是电子邮件是通过一系列的邮件服务器来投递的 , 而域名通过服务器解析来获得结果 。简单邮件传输协议(SMTP) 提供了一个协商机制 , 客户端服务器可以通过这种机制决定以后的动作 。所以中文电子邮件地址的实现方式不同于中文域名的实现(CDNA, chinese domain name in application) 。 中文域名不能使用协商机制 , 中文电子邮件地址可以在传输层通过协商机制来解决 。本标准规定的技术协议是一个基于邮件传输 MTA 的解决方案 。本标准规定了中文电子邮件地址投递的 SMTP扩展 。

　　5 协议要求

　　5. 1 总体要求

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

　　为了使用中文电子邮件地址,我们需要同时处理中文电子邮件地址的域名部分和本地部分 。 电子邮件的域名部分已经通过 CDNA [RFC3490]得到了处理 ,但是仍然没有标准规定如何处理本地部分 。

　　原始的互联网电子邮件的地址的语法将域名部分限制为一个 7 位 ASCII的子集 ,对于本地部分并没有做过多限制 ,这些限制在 IETF RFC2821中定义 。为了能够投递中文电子邮件地址通过 SMTP服务器 ,我们需要升级 SMTP服务器来支持中文电子邮件地址 。老的 SMTP服务器和邮件阅读客户端以及其他相关的邮件系统可能没有准备处理好中文电子邮件地址 , 基于 SMTP 的 SMTPUTF8扩展被定义来识别和保护这样的系统 。

　　本标准规定了电子邮件传输机制的扩展以允许信息的信封和头部域中存在非 ASCII字符的中文电子邮件地址 。

　　5.2 中文电子邮件的 SMTP扩展框架

　　SMTP协议要求进行扩展来支持中文电子邮件地址,并遵循以下 10条原则 :

　　—SMTP服务扩展名称是“邮件地址国际化 ”或“Internationalized Email”;

　　— 与本扩展相关的 EHLO 关键字值是 “SMTPUTF8”。EHLO 命 令 不 带 参 数 。 客 户 端 要 忽 略该命令的任何参数 。服务器端一旦在 EHLO 响应里包含了 SMTPUTF8,就要实现本文档规定的扩展功能 ;

　　— 一个可选的参数是 SMTPUTF8被加入到 MAIL命令中 。此参数确认客户端是支持中文邮件的国际化邮件的客户端 ,且认为所传信息是含有国际化字符信息的 ;

　　— 一个可选的参数是“SMTPUTF8”被加入到 VRFY 和 EXPN命令中 。参数 SMTPUTF8没有具体的值 ,它标示 SMTP客户端可以接受发送 VRFY 和 EXPN 命令后的返回信息可以是用UTF8编码的 Unicode字符串 ;

　　— 本扩展没有定义其他命令 ;

　　— 如果服务器支持本扩展 ,必须也要支持 8BITMIME扩展 ;

　　—MAIL和 RCPT 中的 reverse-path和 forward-path允许 UTF-8编码的邮件地址 ;

　　— 邮件头信息也进行了扩展 ,详见 GB/T 32397;

　　— 由于增加了 SMTPUTF8参数 ,MAIL命令行的最大长度可以增加 10个字符 ;

　　—SMTPUTF8扩展在邮件提交协议 MSA上有效 。

　　5.3 SMTPUTF8扩展

　　一个声明了支持电子邮件地址 SMTPUTF8扩展的 SMTP 服务器必须能够准备接受在邮箱中任何可能的位置出现 UTF-8字符串 。这个字符串仍然必须按照邮箱格式的规定解释 , 比如将邮箱分割为来源路由(source route) ,本地部分(localpart)和域名部分(domain part) ,按规定只使用字符冒号(U+ 003A) , 逗号(U+002C) , 和 @ (U+0040) 。 即使 SMTP服务器支持了电子邮件地址 SMTPUTF8扩展 ,也必须按照 RFC2821的要求 。 除了 SMTP服务器是最终投递服务器(LastMTA) 之外 ,传输过程中的 SMTP服务器不应解析邮件地址的本地部分 。对于域名部分的处理 ,要遵循中文域名相关标准的要求 。任何将要通过 DNS查找的域名 ,如果不是全 ASCII字符的域名 ,那么必须首先通过 ToASCII()函数处理成中文域名相对应的 ACE格式 ,再提交给相应的 DNS服务器 。

　　一个 SMTP客户端 ,如果收到的对于“EHLO”命令的响应中包含关键字 “SMTPUTF8”,那么可以使用 UTF-8形式传输中文电子邮件地址,也允许传输含有中文电子邮件地址以 UTF-8形式表示的头部 。对于域名部分的字符串 ,可以使用 ACE传输 ,也可以以 UTF-8 形式传输 。 如果原始 SMTP客户端发送信息到 MSA,MSA应根据 CDNA规则检查域名部分的合法性 。如果服务器提供了电子邮件地址 SMTPUTF8扩展 ,那么任何中间环节的服务器不能够以任何方式解析 、或者试图改变电子邮件地址本地部分 。

　　如果服务器没有提供 SMTPUTF8扩展 ,SMTP客户端就不应该传输中文电子邮件地址,也不应该在邮件信息中包含 GB/T 32397中规定的中文电子邮件地址头部 ,此规定适合于 MIME结构中的任何层次 。 (注意 , 以 CDNA 中定义 的 ACE 编 码 的 中 文 域 名 不 在 此 列) 。 相 反 , 如 果 SMTP 客 户 端(发 信人)尝试传输了中文电子邮件地址,但是遇到了不支持 SMTPUTF8扩展的服务器 ,则 SMTP客户端必须做如下三个选择之一 :

　　a) IETF RFC4409规定的当且仅当 SMTP客户端是一个邮件传输服务器(MSA) ,那么它可能会对相应的服务器提供一些通用的预防措施 ,能够重写信封 ,头部或者邮件内容来使得这些部分改变为全部为 ASCII字符 ,符合 IETF RFC 2821和 IETF RFC 2822的规定 。

　　b) 在 SMTP事务中拒绝邮件 ,或者接收邮件然后生成和发送一个无法投递的通知 。通知要遵守IETF RFC2821、IETF RFC3464和 IETF RFC6533的相关规定 。

　　c) 找到一个到达目的地的允许电子邮件地址 SMTPUTF8扩展的替代路由 。这样的路由可能可以通过尝试替代的 MX 主机或者 SMTP发送者可以使用的其他方法来得到 。

　　5.4 邮箱地址语法扩展

　　IETF RFC2821的 4. 1. 2规定了 ASCII形式的邮箱语法 ,本标准针对邮箱地址主要的修改是 :

　　“sub-domain”的定义修改为允许原来的定义或者允许一个符合 IDNA[RFC3490]标准的代表 DNS标签的 UTF-8字符串 。

　　“Atom”的定义修改为允许原来的定义或者允许一个 UTF-8字符串 。这个字符串必须不能包含任何在“atext”中不允许的 ASCII字符(控制字符或者图形字符) 。

　　根据上面的描述 ,一个中文电子邮件地址的邮箱名字(地址)应该有如下的 ABNF[RFC5234]定义 : uMailbox = uLocal-part "@ " uDomain

　　uLocal-part= uDot-string/ uQuoted-string

　　; 替换 RFC 2821中 4. 1. 2 中的 Local-part的定义

　　uDot-string = uAtom * ( ". " uAtom)

　　uAtom = 1* ucharacter

　　ucharacter = atext/ UTF8-non-ascii

　　atext =

　　uQuoted-string = DQUOTE * uqcontentDQUOTE

　　DQUOTE =

　　uqcontent= qcontent/ UTF8-non-ascii

　　qcontent=

　　uDomain = (sub-udomain 1* ( ". " sub-udomain)) / address-literal

　　address-literal =

　　sub-udomain = uLet-dig[uLdh-str]

　　uLet-dig = Let-dig/ UTF8-non-ascii

　　Let-dig =

　　uLdh-str = * ( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig

　　UTF8-non-ascii= UTF8-2/ UTF8-3/ UTF8-4

　　UTF8-2 =

　　UTF8-3 = “ ”UTF8-4 =

　　5.5 MAIL命令参数和响应码

　　本标准规定禁止发送带有中文电子邮件地址头部信息的邮件到不支持 SMTPUTF8扩展的 SMTP服务器 。如果客户端发 送 含 有 中 文 电 子 邮 件 头 信 息 的 邮 件 , 客 户 端 必 须 在 MAIL命 令 中 提 供 SMT- PUTF8参数 。

　　本条中规定的三位数字表示的响应码的含义和 IETF RFC 2821中的规定一致 。

　　如果邮件被拒绝由于 RCPT命令需要 ASCII地址时 ,用响应码 533表示 “出现不允许的邮箱名 ”。如果邮件被拒绝由于其他原因如 MAIL命令需要 ASCII邮箱时 ,用响应码 550表示 “邮箱名不可用 ”。当服务器支持增强邮件系统状态码时 ,返回码“X. 6. 7”[RFC5248]表示“非 ASCII邮箱不被允许 ”。这里使用的三位的返回代码与 IETF RFC 2821中所定义的含义是一致的 。

　　如果响应代码产生在 DATA命令最后的 “.”之后 ,那么响应代码 554用来表示 “传输失败 ”。当服务器支持增强邮件系统状态代码时 , 响应代码“X. 6. 9”表示“SMTPUTF8传输失败 ,信息必须被退回 ”。

　　5.6 正文部分和 SMTP扩展

　　MAIL命令参数 SMTPUTF8可以用来相信一个邮件是否为一封含有 GB/T 32397规定的邮件信息的中文电子邮件 ,但是仍然有可能此邮件不是中文电子邮件 ,所以一个 SMTP服务器如果需要精确的知道一封邮件是否含有中文电子邮件头信息的中文电子邮件 ,就需要解析邮件正文部分中所有的邮件头部域和 MIME头部域 。

　　电子邮件地址 SMTPUTF8扩展规定了服务器必须支持 8BITMIME扩展[RFC1652]来确保服务器拥有足够的能力来 处 理 8-bit数 据 以 及 避 免 更 多 复 杂 的 编 码 问 题 。使 用 国 际 化 的 邮 件 没 有 要 求 在MIME 的信息里 , 邮件要出现含非 ASCII字符的正文内容 。如果邮件正文内容符合要求 , 电子邮件地

　　。8I使,么。--

　　a) 如果没有“BODY”参数 ,那么头部包含 UTF-8字符 ,但是所有的正文内容(body) 部分是全部ASCII的(可能是作为内容传输编码的结果) ;

　　b) 如果出现 BODY= 8BITMIME参数 ,那么头部包含 UTF-8字符 ,一些或者所有的正文内容部

　　c) 如果出现 BODY=BINARYMIME参数 ,那么头部包含 UTF-8字符 ,一些或者全部正文内容

　　5.7 附加的 ESMTP变化和说明

　　在邮件传输过程中 ,针对不同的上下文 ,在 MAIL和 RCPT命令及相应的扩展命令中包含了邮箱地址和域名 。 总 体 的 规 则 是 由 于 在 IETF RFC2821 中 规 定 了 邮 箱 的 格 式 , 则 字 符 串的 全 部 都 使 用UTF-8;由于在 RFC2821规定了域名的格式 ,所 以 如 果 原 始 的 格 式 是 非 ASCII, 则 此 名 称 应 该 转 换 成ACE 的格式 。

　　以下的部分列出并讨论了全部的相关情况 。

　　a) 初始 SMTP交换

　　当建立了一个 SMTP连接 ,正常情况下服务器发送由响应代码 220和其他信息组成的 “greeting”消息给客户端 ,客户 端 在 此 之 后 发 送 EHLO 命 令 。 客 户 端 查 询 EHLO 命 令 的 响 应 中 是 否 有 SMT- PUTF8扩展以确定服务器是否支持 SMTPUTF8。在对话过程或者 EHLO 的响应中出现的任何域名都必须符合 IETF RFC1034关于主机名的规定 。例如 , 中文域名必须是 ACE 的形式 。

　　b) 邮件交换 MaileXchangers

　　每个机构通常授权多个服务器去接收发送给它们的邮件 。 这些授权过的邮件服务器通常会列在IETF RFC2821中描述的 MX记录中 。 当多个服务器根据邮箱的域名部分接收邮件时 ,本标准建议所有对应同一个邮件域的服务器选择全部支持或不支持 SMTPUTF8扩展 。否则可能引起意外的向下兼容导致临时性错误 ,而用户可能把它当作严重的可靠性问题 。

　　c) Trace消息

　　当一个 SMTP服务器因为投递邮件接收一条消息 ,或者进行更多的处理 ,它必须在消息内容的开始部 分 插 入 trace(“Time stamp”或 者 “Received”) 消 息 。 “Time stamp”或 者 “Received”出 现 在“Received”行中 。该行的用处主要是诊断邮件错误 。 当 SMTP服务器做消息的 “最后投递 ”时 ,它在邮

　　件数据的开始部分插入 Return-path行 ,这样做的主要 目 的是指定一个邮件地址作为当消息没有投递或者其他的邮件系统错误发生时的目标地址 。对 trace消息 ,本标准规定在利用 SMTPUTF8传输时 ,涉及到域名部分的 trace信息可以使用 UTF8表示 ,其他情况必须使用 ASCII或者 ACE形式表示 。

　　d) 响应信息中的 UTF-8字符串

　　1) MAIL命令

　　如果客户端发送包含了 SMTPUTF8参数的 MAIL命令 ,服务器被允许在邮件地址中使用与响应代码 251和 551相关的 UTF-8字符串 。

　　如果 SMTP客户端遵照了此规定 ,发送包含了 SMTPUTF8参数的 MAIL命令 , 它必须能够接收和处理包含 UTF-8邮件地址的 251或 551响应 。如果给定的 MAIL命令不包含 SMTPUTF8参数 ,服务器不应该返回包含了非 ASCII邮箱的 251或者 551的响应 。相反 ,它必须转换响应信息为不包含非ASCII邮箱地址的 250或 550响应 。

　　2) VRFY 和 EXPN命令及 SMTPUTF8参数

　　如果 VRFY,EXPN命令和可选参数“SMTPUTF8”一起传输 ,它表示客户端可以接受这些命令的回复中包含 UTF-8字符串 。它允许服务器回复时 ,在邮箱名称和全名中使用 UTF-8字符串而不用考虑客户端可能会混淆它们 。一个符合此规定的 SMTP客户端必须接受和正确地处理包含了 UTF-8字符串的 VRFY 和 EXPN命令的回复 。然而 ,如果 SMTP客户端没有特别指定允许在传输此参数时允许这类回复 ,SMTP服务器就不应该在回复中使用 UTF-8字符串 。大多数回复没有要求在回复的文本中包含一个邮箱名称 , 因此 UTF-8在其中就不必要 。一些回复 ,尤其是成功地执行了 VRFY 和 EXPN命令的回复 ,会包含邮箱 ,这使得本部分的规定十分重要 。

　　新的 VERIFY(VRFY)和 EXPAND(EXPN)命令的语法如下 :

　　"VRFY" SP (uLocal-part/ uMailbox) [SP "SMTPUTF8"] CRLF

　　"EXPN" SP ( uLocal-part/ uMailbox ) [ SP "SMTPUTF8" ] CRLF

　　“SMTPUTF8”参数没有使用值 。 如 果 对 VERIFY (VRFY) 或 者 EXPAND (EXPN) 命 令 的 回 复需要 UTF-8,但是 SMTP客户端没有使用“SMTPUTF8”参数 ,那么服务器就必须使用 252或者 550响应代码 。 响应代码 252表示 “不能认证用户 ,但是会接受此消息 ,尝试投递 ”。响应代码 550表示 “请求的行为没有被执行 : 邮箱不存在 ”。当服务器支持改进的邮件系统状态码时 ,下面定义的改进的状态码会被使用 。与 VERIFY (VRFY) 或者 EXPAND (EXPN)命令一起使用“SMTPUTF8”参数使得该命令的回复中仅能使用 UTF-8。

　　如果返回了一个成功响应代码(比如 250) ,该响应可能包含用户的全名 ,必须包含用户的邮箱名 。它必须使用以下的格式 :

　　UserName

　　; 用户名可使用非 ASCII字符 .

　　uMailbox

　　如果 SMTP 的返回中需要 UTF-8字符串 ,但是 UTF-8在返回中又不被允许 , 服务器支持改进的邮件系统状态码 ,其改进的状态码是“X. 6. 8”,表示 “一个包含了 UTF-8字符串的回复显示邮箱名 ,但是客户端不允许此种形式的响应 ”。

　　如果 SMTP客户端不支持 SMTPUTF8扩展 ,但是如果在回复中接收到了 UTF-8字符串 ,它可能不会报告此回复给用户 ,而一些客户端可能面临崩溃 。在响应中的 UTF-8信息仅仅在上面讨论的情况下的命令中使用 。其他情况下 ,UTF-8文本不应该在响应中出现 。

　　尽管 UTF-8信息可以在上面定义的规则下使用 ,在响应中被用来表示邮件地址,此标准不允许除

　　上述目的以外的其他目的而使用 UTF-8。SMTP服务器不应该在回复中包含非 ASCII字符串 ,但是在本部分规定的有限的特殊情况下除外 。

　　5. 8 中文电子邮件地址的注册和使用

　　当 SMTP作为最终的接收邮件服务器使用时 ,通常会为每个邮件用户分配邮件账号 ,这些账号 一般会作为邮件地址的 local-part来使用 。 在中文电子邮件地址中含有中文字符 。 中文字符存在着 “变体 ”, 同一个字可能有多种表示方式 ,这样可能导致某些中文字符可能被认为是同一个字符 ,但在计算机使用的字符集中 , 同一个概念上的字符会通过几个不同的码位来识别 。外形相同的字符 ,或者是有相同或相似语义却被分配了不同码位的字符有可能使用户产生混淆 。 为了防止混淆和钓鱼行为 , 中文邮箱在注册管理时候有必要采取相应的措施使中文电子邮件地址本地部分的简繁体(变体)等名字在收发邮件时候是等效的 。本标准建议对每个成功注册的中文电子邮件地址的中文邮箱 ,根据中文异体对照表 ,生成一个本地 Local-part包 。Local-part包内的所有 Local-part名字字段归同一个邮件注册人持有 。