ICS M32 YD中华人民共和国通信行业标准YD/T ××××—×××× 简单邮件传输协议（SMTP）扩展支持互联网中文电子邮件地址技术要求 Technical specification for SMTP extension to support chinese internet email address （报批稿） ××××-××-××发布 ××××-××-××实施 发布中华人民共和国工业和信息化部
YD/T ××××—×××× 目 次 前 言 ............................................................................. II 引 言 ............................................................................ III 1 范围 ................................................................................ 1 2 规范性引用文件 ...................................................................... 1 3 术语、定义和缩略语 .................................................................. 2 术语和定义 ........................................................................ 2 缩略语 ............................................................................ 3 4 协议概述 ............................................................................ 4 5 协议要求 ............................................................................ 4 总体要求 .......................................................................... 4 中文电子邮件的SMTP扩展框架 ....................................................... 4 UTF8SMTP扩展 ...................................................................... 5 邮箱地址语法扩展 .................................................................. 5 ALT-ADDRESS参数 ................................................................... 7 ALT-ADDRESS用法和响应码 ........................................................... 8 正文部分和SMTP扩展 ............................................................... 8 附加的ESMTP变化和说明 ............................................................ 8 I
YD/T ××××—×××× 前 言 本标准在技术内容上与IETF RFC5336《SMTP扩展支持国际化电子邮件地址技术要求》（2008年英文版）保持一致，实现本标准与实现IETF RFC5336的结果是一样的。 本标准是“互联网中文电子邮件地址”系列标准之一，该系列标准的名称和结构如下： - 互联网中文电子邮件地址框架总体技术要求； - 简单邮件传输协议SMTP扩展支持互联网中文电子邮件地址技术要求； - 互联网中文电子邮件地址格式的邮件头技术要求； - 互联网中文电子邮件地址与普通邮件系统兼容技术要求； - 在POP中支持互联网中文电子邮件地址技术要求； - 在IMAP中支持互联网中文电子邮件地址技术要求； - 互联网中文电子邮件地址客户端技术要求 本标准由中国通信标准化协会提出并归口。 标准起草单位：中国互联网络信息中心（CNNIC）、工业和信息化部电信研究院、中兴通讯股份有限公司、清华大学、中国移动通信集团公司。 标准主要起草人：李晓东、姚健康、曹蓟光、李明栋、崔勇、段晓东。 II
YD/T ××××—×××× 引 言 互联网是一个基于开放互联协议的网络，电子邮件发送是互联网上的基础服务，可以用来传送互联网信息，电子邮件服务是互联网信息的传递更加快捷。传统的电子邮件地址都是ASCII格式的，随着中文域名的推广使用，人们越来越迫切需要中文电子邮件地址。 随着互联网的发展，中文用户的数量不断增加，对于中文域名的使用需求也在增加。但是中文域名的最大应用中文电子邮件地址由于缺乏相关标准，没有得到很好的应用和推广。中文电子邮件地址和传统的英文电子邮件地址有较大差别，比如：中文电子邮件地址的字符集比传统的英文域名的字符集大很多。为了规范中文电子邮件地址的使用，让中文用户能够方便的通过中文电子邮件地址来使用互联网的各种应用服务，尽快制定中文电子邮件地址标准，进而推动中文电子邮件地址的使用是十分重要的。 本标准主要采用了IETF的标准RFC 5336《SMTP扩展支持国际化电子邮件地址技术要求》（英文版）和IETF国际化电子邮件地址工作组的相关RFC标准和草案，以及我国的实际情况起草的，目的在于推动中文电子邮件地址在中国的应用、发展和普及，有利于在中文用户群体中推广使用中文化的电子邮件地址。本标准在技术内容上与RFC5336保持一致，实现本标准与实现RFC5336的结果是一样的。 本标准是“互联网中文电子邮件地址”系列标准之一中的第二个标准，它规定了如何利用SMTP扩展支持中文电子邮件地址。该系列标准的名称和结构如下： 实现对中文电子邮件地址的支持首先应实现对国际化电子邮件地址的支持。该标准保持一致的IETF RFC5336是国际化电子邮件地址的标准。IETF RFC5336是针对国际化电子邮件地址问题而提出的。本标准的第3章“术语和定义”是将RFC4952和RFC5336中的术语和定义修改归集，并增加了一些适合本标准的特定的术语和定义。本标准的第4章和第5章主要对应IETF RFC5336，主要规定了SMTP扩展支持中文电子邮件地址的总体技术要求，将其中有关国际化电子邮件地址的规定都转换成只针对中文电子邮件地址的规定，以符合中国国情，但是其技术思路并未作修改。要实现对本标准的支持，亦可直接参照IETF RFC5336。 III
YD/T ××××—×××× 简单邮件传输协议（SMTP）扩展支持互联网中文电子邮件地址技术要求 1 范围 本标准规定了从服务器端在互联网体系上使用SMTP扩展支持中文电子邮件地址的技术要求。 本标准适用于各级电子邮件地址注册管理机构、电子邮件地址服务提供商以及软件厂商开发支持中文电子邮件地址的应用或者服务。 2 规范性引用文件 下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。 YD/T XXXX-XXXX 互联网中文电子邮件地址与普通邮件系统兼容技术要求 YD/T XXXX-XXXX 互联网中文电子邮件地址格式的邮件头技术要求 IETF RFC821 简单邮件传输协议 IETF RFC822 邮件格式头要求 IETF RFC1034 域名概念和指南 IETF RFC 1035 域名的实现与规范 IETF RFC 1122 互联网主机传输层要求 IETF RFC 1123 互联网主机的应用与支持要求 IETF RFC1652 SMTP八比特MIME传输 IETF RFC 2234 语法规范的扩展巴科斯范式：ABNF IETF RFC 2821 简单邮件传输协议 IETF RFC 2822 互联网信息格式 IETF RFC3461 SMTP DSN扩展 IETF RFC3463 增强的邮件系统状态码 IETF RFC3464 投递状态通知 IETF RFC3490 国际化域名应用 IETF RFC 3492 一种适用于国际化域名应用的对UNICODE的编码方法：Punycode IETF RFC3629 UTF-8编码 IETF RFC4409 邮件信息提交 IETF RFC5234 增强的BNF范式 IETF RFC5248 增强的邮件系统状态码登记 IETF RFC5337 国际化电子邮件格式的投递状态通知要求； 1
YD/T ××××—×××× 3 术语、定义和缩略语 术语和定义 下列术语和定义适用于本标准。 电子邮件 在计算机网络上，用户终端之间往来的信函。 最终投递MTA 一种SMTP服务器，它可以控制邮件地址本地部分的格式并且允许检查和解释地址的本地部分，它从网络接受信息投递给邮箱或者其他本地过程而不是中转（relay）。从网络的观点来看，任何本地的投递安排，比如保存在一个信息仓库，转交给特殊的信息投递程序或代理以及获取信息机制全都是在最终投递MTA之后，因此并不是SMTP传输或者最终投递MTA过程的一部分。 Unicode字符 Unicode根据其位置或码位来识别字符，给每个字符提供的一个唯一的数字。比如说，U+12AB指的是在Unicode 表中位于12AB处的字符。本标准参考了Unicode 标准版本（等同于ISO10646）。Unicode字符集包含ASCII字符集。 UTF-8 Unicode 是分配整数给字符的编码表. UTF-8是将Unicode中的一串字符表示为一串字节的方法.在UTF-8中，字符采用1到6个8比特字节的序列进行编码。仅仅一个8比特字节的一个序列中，字节的高位为0，其他的7位用于字符值编码。n（n>1）个8比特字节的一个序列中，初始的8比特字节中高n位为1，接着一位为0，此字节余下的位包含被编码字符值的位。接着的所有8比特字节的最高位为1，接着下一位为0，余下每个字节6位包含被编码字符的位。 ASCII地址 如果一个地址中的每一个字符都属于ASCII字符集，且符合IETF RFC821中规定格式的，那么这个地址是“全部ASCII”的地址或者是一个“ASCII地址”。 UTF8SMTP地址 如果电子邮件地址中至少有一个字符满足属于Unicode字符集但是不属于ASCII字符集，那么这个地址被称为“UTF8SMTP地址”。 中文域名 Chinese Domain Name 含有中文域名字段的域名。 中文电子邮件头 含有《互联网中文电子邮件地址格式的邮件头技术要求》所规定的信息的电子邮件头部。 i18mail 用户 一个“i18mail 用户” 指拥有一个或多个UTF8SMTP地址，这些用户可能也拥有ASCII地址。如果用户拥有多于一个账户和相应的电子邮件地址，或者同一个电子邮件地址有多于一个别名，他可以通过某种方法选择在发出的邮件中使用哪个地址，在这种情况下，是不可2
YD/T ××××—×××× 能通过地址来辨别发件人或者收件人是否是一个i18mail用户。 信息 message 一个信息是从一个用户（发送者）利用特定的电子邮件地址发送到另一个或者多个接收电子邮件地址(经常仅仅称作用户或接收用户)。 追踪头trace field 邮件头部信息中为了追踪邮件所经过的路径而专门设的主机字段。 Punycode 一种编码转换规则。运用这种规则应可实现Unicode字符串和ASCII字符串的相互转换。详见IETF RFC3492。 中文电子邮件系统 支持本标准的邮件系统。 ASCII电子邮件系统 只支持IETF RFC822和IETF RFC2822所规定的ASCII格式形式地址的邮件系统。 电子邮件地址本地部分 电子邮件地址“@”的左半部分。 电子邮件地址域名部分 电子邮件地址“@”的右半部分。 邮件交换 Mail eXchanger 专门负责“处理”或者“转发”某个域名的邮件的主机。 缩略语 下列缩略语适用于本标准。 ACE ASCII Compatible Encoding ASCII兼容编码 CDN Chinese Domain Name 中文域名 CDNA Chinese Domain Names in Applications 中文域名与应用 DNS Domain Name System 域名系统 EmailElectronicMail电子邮件 ESMTP SMTP Service Extensions 简单邮件传输协议扩展 MDA Message Delivery Agent 邮件递送代理 MSA Message Submission Agent 邮件提交代理 MTAMailTransferAgent邮件传递代理 MUA Mail User Agent 邮件用户客户端 SMTP Simple Mail Transfer Protocol 简单邮件传输协议 3
YD/T ××××—×××× 4 协议概述 中文电子邮件地址包括两部分，本地部分和域名部分。互联网协议使用电子邮件地址的方法与使用域名的方法是不同的。最显著的不同是电子邮件是通过一系列的邮件服务器来投递的，而域名通过服务器解析来获得结果。电子邮件传输协议SMTP和ESMTP提供了一个协商机制，客户端服务器可以通过这种机制决定以后的动作。所以中文电子邮件地址的实现方式不同于中文域名的实现(CDNA)。电子邮件可以通过开发协商机制来解决而CDN不能使用协商机制，所以中文电子邮件地址应该在传输层通过协商机制来解决。本标准规定的技术协议是一个 基于MTA的解决方案。本标准规定了中文电子邮件地址投递的SMTP扩展，也涉及了向下兼容现有电子邮件系统的降级机制。 5 协议要求 总体要求 本标准要求更新现有的SMTP协议和电子邮件地址的格式以便允许中文电子邮件地址的显示和传输。下面具体从SMTP服务器端来具体要求协议的实现。 为了使用中文电子邮件地址，我们需要同时处理中文电子邮件地址的域名部分和本地部分。电子邮件的域名部分已经通过CDNA（见IETF RFC3490）得到了处理，但是没有具体规定如何处理邮件地址的本地部分。 原始的互联网电子邮件的地址的语法将域名部分限制为一个7位ASCII的子集，对于本地部分并没有做过多限制，这些限制在IETF RFC2821中定义。为了能够投递中文电子邮件地址通过SMTP服务器，我们需要升级SMTP服务器来支持中文电子邮件地址。老的SMTP服务器和邮件阅读客户端以及其他相关的邮件系统可能没有准备处理好中文电子邮件地址， 基于SMTP的 UTF8SMTP扩展被定义来识别和保护这样的系统。 本标准规定了电子邮件传输机制的扩展以允许信息的信封和头部域中存在非ASCII字符的中文电子邮件地址。 中文电子邮件的SMTP扩展框架 SMTP协议要求进行扩展来支持中文电子邮件地址，并遵循以下原则： 1) SMTP服务扩展名称是“邮件地址国际化Email Address Internationalization ” 2) 与本扩展相关的EHLO关键字值是"UTF8SMTP"。 3) EHLO命令不带参数。客户端要忽略该命令的任何参数。服务器端一旦在EHLO响应里包含了UTF8SMTP，就要实现本标准规定的扩展功能。 4) 一个可选的参数是ALT-ADDRESS被加入到MAIL和RCPT命令中。ALT-ADDRESS规定了在做向下兼容ASCII邮件系统时作为中文电子邮件地址的的替代ASCII地址。更详细的规定如何应用ALT-ADDRESS，见YD/T XXXX-XXXX《互联网中文电子邮件地址与普通邮件系统兼容技术要求》。 5) 一个可选的参数是“UTF8REPLY”被加入到VRFY和EXPN命令中。参数UTF8REPLY没有具体的值，它标示SMTP客户端可以接受发送VRFY和EXPN命令后的返回信息可以是用UTF8编码的Unicode字符串。 6) 本扩展没有定义其他命令。 7) 如果服务器支持本扩展，必须也要支持8BITMIME扩展。 8) MAIL和RCPT中的reverse-path和forward-path允许UTF-8编码的邮件地址。 9) 邮件消息体也进行了扩展，详见YD/T XXXX-XXXX《互联网中文电子邮件地址格式的邮件头技术要求》。 4
YD/T ××××—×××× 10) 由于增加了ALT-ADDRESS关键字和值，MAIL和RCPT命令行的最大长度可以增加到460个字符。 11) UTF8SMTP扩展在邮件提交协议MSA(见IETF RFC4409)上有效。 UTF8SMTP扩展 一个声明了支持电子邮件地址UTF8SMTP扩展的SMTP 服务器必须能够准备接受在邮箱中任何可能的位置出现UTF-8 字符串。这个字符串仍然必须按照邮箱格式的规定解释，比如将邮箱分割为来源路由（source route）,本地部分（local part）和域名部分（domain part），按规定只使用字符冒号(U+003A), 逗号(U+002C), 和 @ (U+0040)。即使SMTP服务器支持了电子邮件地址UTF8SMTP扩展，也必须按照IETF RFC2821的要求。除了SMTP服务器是最终投递服务器（Last MTA）之外，传输过程中的SMTP服务器不应解析邮件地址的本地部分。对于域名部分的处理，要遵循中文域名相关标准的要求。任何将要通过DNS查找的域名，如果不是全ASCII字符的域名，那么必须首先通过ToASCII()函数处理成CDNA定义的ACE格式，再提交给相应的DNS服务器。。 一个SMTP客户端，如果收到的对于“EHLO”命令的响应中包含关键字“UTF8SMTP”，那么可以使用UTF-8形式传输中文电子邮件地址，也允许传输含有中文电子邮件地址以UTF-8形式表示的头部。对于域名部分的字符串，可以使用ACE传输，也可以以UTF-8 形式传输。如果原始SMTP客户端发送信息到MSA，MSA应根据CDNA规则检查域名部分的合法性。如果服务器提供了电子邮件地址UTF8SMTP扩展，那么任何中间环节的服务器不能够以任何方式解析、或者试图改变电子邮件地址本地部分。 如果服务器没有提供UTF8SMTP扩展，SMTP客户端就不应该传输中文电子邮件地址，也不应该在邮件信息中包含YD/T XXXX-XXXX《互联网中文电子邮件地址格式的邮件头技术要求》中规定的中文电子邮件地址头部，此规定适合于MIME结构中的任何层次。(注意，以CDNA中定义的ACE编码的中文域名不在此列)。相反，如果SMTP客户端(发信人)尝试传输了中文电子邮件地址，但是遇到了不支持UTF8SMTP扩展的服务器，则SMTP客户端必须做如下四个选择之一： 1) 在IETF RFC4409中规定的当且仅当SMTP客户端是一个邮件传输服务器（MSA），那么它可能会对相应的服务器提供一些通用的预防措施,能够重写信封，头部或者邮件内容来使得这些部分改变为全部为ASCII字符，符合IETF RFC2821和IETF RFC2822的规定。 2) 在SMTP事务中拒绝邮件，或者接收邮件然后生成和发送一个无法投递的通知。通知要遵守IETF RFC2821、IETF RFC3464和IETF RFC5337的规定。 3) 找到一个到达目的地的允许电子邮件地址UTF8SMTP扩展的替代路由。这样的路由可能可以通过尝试替代的MX主机(使用IETF RFC2821的规定)或者SMTP发送者可以使用的其他方法来得到。 4) 当且仅当全ASCII地址对于所有的出现在回复地址和每个指定的转发地址位置上的地址是可用的 ，可以把一封邮件向下兼容处理成为一封全ASCII格式的邮件。如果信封上的原始地址是全ASCII字符的或者一个中文电子邮件地址指定了一个ASCII地址作为UTF8SMTP地址的替代地址参数，那么这个ASCII地址被认为是对于某个特定地址是可用的。 1)和4)的区别在于1）是由邮件传输MSA（见IETF RFC4409）规定的，而4）是由YD/T XXXX-XXXX《互联网中文电子邮件地址与普通邮件系统兼容技术要求》规定的。 邮箱地址语法扩展 IETF RFC2821的第节规定了ASCII形式的邮箱语法，中文电子邮件地址邮件标准针对邮箱地址主要的修改是： a) “sub-domain”的定义修改为允许原来的定义或者允许一个符合IDNA（见IETF RFC3490）的代表DNS标签的UTF-8字符串。 5
YD/T ××××—×××× b) “Atom”的定义修改为允许原来的定义或者允许一个UTF-8字符串。这个字符串必须不能包含任何在“atext”中不允许的ASCII字符（控制字符或者图形字符）。 根据上面的描述，一个中文电子邮件地址的邮箱名字（地址）应该有如下的ABNF（见IETF RFC5234）定义： uMailbox = uLocal-part "@" uDomain ; 替换 IETF RFC 2821中 第节中的Mailbox 定义 uLocal-part = uDot-string / uQuoted-string ; MAY be case-sensitive ; 替换IETF RFC 2821中第节中的Local-part 的定义 uDot-string = uAtom *("." uAtom) ; 替换IETF RFC 2821中第节中的Dot-string 的定义 uAtom = 1*ucharacter ; 替换IETF RFC 2821中第节中的Atom 的定义 ucharacter = atext / UTF8-non-ascii atext = <See Section of IETF RFC 2822> uQuoted-string = DQUOTE *uqcontent DQUOTE ; 替换IETF RFC 2821中第节中的Quoted-string 的定义 DQUOTE = <See appendix of IETF RFC 5234> uqcontent = qcontent / UTF8-non-ascii qcontent = <See Section of IETF RFC 2822> uDomain = (sub-udomain 1*("." sub-udomain)) / address-literal ; 替换IETF RFC 2821中第节中的Domain 的定义 address-literal = <See Section of IETF RFC 2822> sub-udomain = uLet-dig [uLdh-str] ; 替换IETF RFC 2821中第节中的sub-domain 的定义 uLet-dig = Let-dig / UTF8-non-ascii Let-dig = <See Section of IETF RFC 2821> uLdh-str = *( ALPHA / DIGIT / "-" / UTF8-non-ascii) uLet-dig 6
YD/T ××××—×××× ; 替换IETF RFC 2821中第节中的Ldh-str的定义 UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4 UTF8-2 = <See Section 4 of IETF RFC 3629> UTF8-3 = <See Section 4 of IETF RFC 3629> UTF8-4 = <See Section 4 of IETF RFC 3629> “udomain”的值应该根据CDNA中定义的测试进行验证。如果验证失败，那么带有udomain的电子邮件地址不能作为一个有效的电子邮件地址。 ALT-ADDRESS参数 如果提供了UTF8SMTP扩展，SMTP MAIL和RCPT命令就要扩展成支持可选的ESMTP-关键字“ALT-ADDRESS”。关键字指定可选的all-ASCII地址，可能会在兼容性处理的时候用到。如果它被使用了，就应该被赋予一个ESMTP值。 仅当Alt-ADDRESS参数所关联的主要地址是UTF8SMTP地址，且消息被做兼容性处理时，Alt-ADDRESS才有意义。 基于IETF RFC2821中关于邮件参数的定义，MAIL和RCPT命令中ALT-ADDRESS参数的使用有如下的定义。 "MAIL FROM:" ("<>" / uReverse-path) [ SP Mail-parameters ] CRLF ; 更新IETF RFC 2821中 第节中的MAIL命令 "RCPT TO:" ("<Postmaster@" uDomain ">" / "<Postmaster>" / uForward-path) [ SP Rcpt-parameters ] CRLF ; 更新IETF RFC 2821中 第节中的RCPT命令 uReverse-path = uPath ; 替换 Reverse-path 的定义. uForward-path = uPath ; 替换 Forward-path 的定义. uPath = "<" [ A-d-l ":" ] uMailbox ">" ; 替换IETF RFC 2821中 第节中的Path 的定义. ; uMailbox 在本标准的第节中定义. A-d-l = <See Section of IETF RFC 2821> ALT-ADDRESS-parameter = "ALT-ADDRESS=" ALT-ADDRESS-value ALT-ADDRESS-value = xtext 7
YD/T ××××—×××× xtext = <See Section of IETF RFC 3461> ALT-ADDRESS 参数在命令中出现次数不能超过一次。其值必须是all-ASCII电子邮件地址。 ALT-ADDRESS用法和响应码 本标准规定禁止发送带有中文电子邮件地址头部信息的邮件到不支持UTF8SMTP扩展的SMTP服务器。 本节中规定的三位数字表示的响应码的含义和IETF RFC 2821中的规定一致。 如果邮件被拒绝由于RCPT命令需要ALT-ADDRESS参数时，用响应码533表示“出现不允许的邮箱名”如果邮件被拒绝由于其他原因如MAIL命令需要ALT-ADDRESS参数时，用响应码550表示“邮箱名不可用”。当服务器支持增强邮件系统状态码(见IETF RFC3464)时，返回码“” (见IETF RFC5248)表示“ALT-ADDRESS参数是必须的却未提供”。这里使用的三位的返回代码与IETF RFC 2821中所定义的含义是一致的。 如果响应代码产生在DATA命令最后的“.”之后，那么响应代码554用来表示“传输失败”。当服务器支持增强邮件系统状态代码时，响应代码“"” (见IETF RFC5248)表示“UTF8SMTP兼容失败”。 正文部分和SMTP扩展 没有ESMTP参数可以用来断定一个邮件是否为一封含有符合YD/T XXXX-XXXX《互联网中文电子邮件地址格式的邮件头技术要求》规定的邮件信息的中文电子邮件，所以一个SMTP服务器如果需要精确的知道一封邮件是否含有中文电子邮件头信息的中文电子邮件，就需要解析邮件正文部分中所有的邮件头部域和MIME头部域。 电子邮件地址UTF8SMTP扩展规定了服务器必须支持8BITMIME扩展(见IETF RFC1652)来确保服务器拥有足够的能力来处理8-bit数据以及避免更多复杂的编码问题。使用国际化的邮件没有要求在MIME的信息里，邮件要出现含非ASCII字符的正文内容。如果邮件正文内容符合要求，电子邮件地址UTF8SMTP扩展可以与BODY=8BITMIME参数一起使用。或者如果服务器广播了BINARYMIME并且BODY=BINARYMIME相关的参数是合适的，那么也可以使用电子邮件地址UTF8SMTP扩展。 假设服务器广播了UTF8SMTP和8BITMIME，收到了至少一个非ASCII地址，有或者没有替代地址，关于MAIL命令中的“No BODY parameter”，“BODY=8BITMIME”，“BODY=BINARYMIME”的准确翻译是： 1) 如果没有" BODY "参数，那么头部包含UTF-8字符，但是所有的正文内容（body）部分是全部ASCII的（可能是作为内容传输编码的结果）。 2) 如果出现BODY=8BITMIME参数，那么头部包含UTF-8字符，一些或者所有的正文内容部分包含8-bit面向行的数据。 3) 如果出现BODY=BINARYMIME参数，那么头部包含UTF-8字符，一些或者全部正文内容部分包含二进制数据，不受行长度或者分隔符的限制。 附加的ESMTP变化和说明 在邮件传输过程中，针对不同的上下文，在MAIL和RCPT命令及相应的扩展命令中包含了邮箱地址和域名。总体的规则是当IETF RFC2821规定了邮箱的格式，这个规则期望字符串的全部都使用UTF-8；当IETF RFC2821规定了域名的格式，如果原始的格式是非ASCII，则此名称应该转换成ACE的格式。 以下的部分列出并讨论了全部的相关情况。 1) 初始SMTP交换 8
YD/T ××××—×××× 当建立了一个SMTP连接，正常情况下服务器发送由响应代码220和其他信息组成的“greeting”消息给客户端，客户端在此之后发送EHLO命令。客户端查询EHLO命令的响应中是否有UTF8SMTP扩展以确定服务器是否支持UTF8SMTP。在对话过程或者EHLO的响应中出现的任何域名都必须符合IETF RFC1034关于主机名的规定。例如，中文域名必须是ACE的形式。 2) Mail eXchangers 每个机构通常授权多个服务器去接收发送给它们的邮件。这些授权过的邮件服务器通常会列在IETF RFC2821中描述的MX记录中。当多个服务器根据邮箱的域名部分接收邮件时，本标准建议所有对应同一个邮件域的服务器选择全部支持或不支持UTF8SMTP扩展。否则可能引起意外的向下兼容导致临时性错误，而用户可能把它当作严重的可靠性问题。 3) Trace消息 当一个SMTP服务器因为投递邮件接收一条消息，或者进行更多的处理，它必须在消息内容的开始部分插入trace(“Time stamp”或者“Received”)消息。“Time stamp”或者“Received”出现在“Received”行中。该行的用处主要是诊断邮件错误。当SMTP服务器做消息的“最后投递”时，它在邮件数据的开始部分插入Return-path行，这样做的主要目的是指定一个邮件地址作为当消息没有投递或者其他的邮件系统错误发生时的目标地址。对trace消息，本标准更新了time stamp行和return-path行（见IETF RFC2821），正式的定义如下： uReturn-path-line = "Return-Path:" FWS uReverse-path <CRLF> ; 代替了IETF RFC2821 第节的Return-path-line ; uReverse-path在本标准里有定义 uTime-stamp-line = "Received:" FWS uStamp <CRLF> ; 代替了IETF RFC2821 第节的Time-stamp-line uStamp = From-domain By-domain uOpt-info ";" FWS date-time ; 代替了IETF RFC2821 第节的Stamp uOpt-info = [Via] [With] [ID] [uFor] ; 代替了IETF RFC2821 第节的Opt-info ; With的协议值讲允许使用UTF8SMTP值 uFor = "FOR" ( FWS (uPath / uMailbox) ) CFWS ; 代替For ; uPath和uMailbox在本标准相关部分有定义 注：For参数被改变了，即允许在For句中仅使用一个地址，用来与IETF RFC2821 bis的定义匹配。除了在“uFor”句子和“uReverse-path”值中可能使用非ASCII域名，在Received域中出现的的中文域名必须以ACE的形式传输。当此扩展被使用时，WITH子句的协议值是UTF8SMTP值的一部分。 4) 响应信息中的UTF-8字符串 a) MAIL和RCPT命令 如果客户端发送包含了非ASCII字符的RCPT命令，服务器被允许在邮件地址中使用与响应代码251和551相关的UTF-8字符串。 如果SMTP客户端遵照了此规定，发送包含了非ASCII的RCPT命令，它必须能够接收和处理包含UTF-8邮件地址的251或551响应。如果给定的RCPT命令不包含非ASCII信封地址，服务9
YD/T ××××—×××× 器不应该返回包含了非ASCII邮箱的251或者551的响应。相反，它必须转换响应信息为不包含非ASCII邮箱地址的250或550响应。 b) VRFY和EXPN命令及UTF8REPLY参数 如果VRFY，EXPN命令和可选参数“UTF8REPLY”一起传输，它表示客户端可以接受这些命令的回复中包含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 "UTF8REPLY"] CRLF "EXPN" SP ( uLocal-part / uMailbox ) [ SP "UTF8REPLY" ] CRLF “UTF8REPLY”参数没有使用值。如果对VERIFY (VRFY)或者EXPAND (EXPN)命令的回复需要UTF-8，但是SMTP客户端没有使用“UTF8REPLY”参数，那么服务器就必须使用252或者550响应代码。响应代码252在IETF RFC2821中有定义，表示“不能认证用户，但是会接受此消息，尝试投递”。响应代码550也在IETF RFC2821 中有定义,表示“请求的行为没有被执行：邮箱不存在”。当服务器支持改进的邮件系统状态码（见IETF RFC3463）时，下面定义的改进的状态码会被使用。与VERIFY (VRFY) 或者 EXPAND (EXPN)命令一起使用“UTF8REPLY”参数使得该命令的回复中仅能使用UTF-8。 如果返回了一个成功响应代码(比如250)，该响应可能包含用户的全名，必须包含用户的邮箱名。它必须使用以下的格式： User Name <uMailbox> ; 用户名可使用非ASCII字符. uMailbox 如果SMTP的返回中需要UTF-8字符串，但是UTF-8在返回中又不被允许，服务器支持改进的邮件系统状态码（见IETF RFC3463），其改进的状态码是“”或者“” （见IETF RFC5248），表示“一个包含了UTF-8字符串的回复 显示邮箱名，但是客户端不允许此种形式的响应”。 如果SMTP客户端不支持UTF8SMTP扩展，但是如果在回复中接收到了UTF-8字符串，它可能不会报告此回复给用户，而一些客户端可能面临崩溃。在响应中的UTF-8信息仅仅在上面讨论的情况下的命令中使用。其他情况下，UTF-8文本不应该在响应中出现。 尽管UTF-8信息可以在上面定义的规则下使用，在响应中被用来表示邮件地址，此标准不允许除上述目的以外的其他目的而使用UTF-8。SMTP服务器不应该在回复中包含非ASCII字符串，但是在本标准规定的有限的特殊情况下除外。 10
