中文电子邮件地址的格式

ICS33.
040.
40M32丫D中华人民共和国通信行业标准丫D汀2144-2010基于简单邮件传输协议(SM丁尸)的互联网中文电子邮件地址技术要求TechnicalspecificationforSMTPextensiontosupportchineseinternetemailaddress2010-12-29发布中华人民共和国工业和信息化部2011一1-01实施发布丫D汀2144-2010目次澎去澎郁规范性引用文件……术语、定义和缩略语前引123术语和定义缩略语……11勺'J飞口协议概述···························································……:···.
······································.
.
.
.
.
.
.
.
4协议要求···············································································································….
.
.
45.
1总体要求·······················································································.
·················……45.
2中文电子邮件的SMTP扩展框架·······································································……'·'.
45.
3UTF8SMTP扩展·····························································································……55.
4邮箱地址语法扩展·····························,·········································,·············……""'55.
5ALTADDRESS参数··········································································.
.
·····.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
75.
6ALT-ADDRESS用法和响应码·······.
······································································……85.
7正文部分和SMTP扩展····················································································……'二85.
8附加的ESMTP变化和说明·.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8YD汀2144-2010月Ii舀本标准在技术内容上与IETFRFC5336《支持国际化电子邮件地址的SMTP扩展的技术要求》(2008年英文版)保持一致,实现本标准与实现IETFRFC5336的结果是一样的.
本标准是"互联网中文电子邮件地址,,系列标准之一,该系列标准的名称和结构如下:一互联网中文电子邮件地址框架总体技术要求;一简单邮件传输协议SMTP扩展支持互联网中文电子邮件地址技术要求;一互联网中文电子邮件地址格式的邮件头技术要求;一互联网中文电子邮件地址与普通邮件系统兼容技术要求;一在POP中支持互联网中文电子邮件地址技术要求;一在IMAP中支持互联网中文电子邮件地址技术要求;一互联网中文电子邮件地址客户端技术要求本标准由中国通信标准化协会提出并归口.
标准起草单位:中国互联网络信息中心(CNNIC)、工业和信息化部电信研究院、中兴通讯股份有限公司、清华大学、中国移动通信集团公司.
标准主要起草人:李晓东、姚健康、曹蓟光、李明栋、崔勇、段晓东.
YD汀2144-2010引言互联网是一个基于开放互联协议的网络,电子邮件发送是互联网上的基础服务,可以用来传送互联网信息,电子邮件服务是互联网信息的传递更加快捷.
传统的电子邮件地址都是ASCII格式的,随着中文域名的推广使用,人们越来越迫切需要中文电子邮件地址.
随着互联网的发展,中文用户的数量不断增加,对于中文域名的使用需求也在增加.
但是中文域名的最大应用中文电子邮件地址由于缺乏相关标准,没有得到很好的应用和推广.
中文电子邮件地址和传统的英文电子邮件地址有较大差别,比如:中文电子邮件地址的字符集比传统的英文域名的字符集大很多.
为了规范中文电子邮件地址的使用,让中文用户能够方便的通过中文电子邮件地址来使用互联网的各种应用服务,尽快制定中文电子邮件地址标准,进而推动中文电子邮件地址的使用是十分重要的.
本标准主要采用了IETF的标准RFC5336(SMTP扩展支持国际化电子邮件地址技术要求》(英文版)和IETF国际化电子邮件地址工作组的相关RFC标准和草案,以及我国的实际情况起草的,目的在于推动中文电子邮件地址在中国的应用、发展和普及,有利于在中文用户群体中推广使用中文化的电子邮件地址.
本标准在技术内容上与RFC5336保持一致,实现本标准与实现RFC5336的结果是一样的.
本标准是"互联网中文电子邮件地址"系列标准之一中的第二个标准,它规定了如何利用SMTP扩展支持中文电子邮件地址.
该系列标准的名称和结构如下:实现对中文电子邮件地址的支持首先应实现对国际化电子邮件地址的支持.
该标准保持一致的IETFRFC5336是国际化电子邮件地址的标准.
IETFRFC5336是针对国际化电子邮件地址问题而提出的.
本标准的第3章"术语和定义"是将RFC4952和RFC5336中的术语和定义修改归集,并增加了一些适合本标准的特定的术语和定义.
本标准的第4章和第5章主要对应IETFRFC5336,主要规定了SMTP扩展支持中文电子邮件地址的总体技术要求,将其中有关国际化电子邮件地址的规定都转换成只针对中文电子邮件地址的规定,以符合中国国情,但是其技术思路并未作修改.
要实现对本标准的支持,亦可直接参照IETFRFC53360YD厅2144-2010基于简单邮件传输协议(SM下尸)的互联网中文电子邮件地址技术要求范围本标准规定了从服务器端在互联网体系上使用SMTP扩展支持中文电子邮件地址的技术要求.
本标准适用于各级电子邮件地址注册管理机构、电子邮件地址服务提供商以及软件厂商开发支持中文电子邮件地址的应用或者服务.
2规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款.
凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准.
然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本.
凡是不注日期的引用文件,其最新版本适用于本标准.
IETFRFC5504互联网中文电子邮件地址与普通邮件系统兼容技术要求IETFRFC5335互联网中文电子邮件地址格式的邮件头技术要求IETFRFC821简单邮件传输协议IETFRFC822邮件格式头要求IETFRFC1034域名概念和指南IETFRFC1035域名的实现与规范IETFRFC1122互联网主机传输层要求IETFRFC1123互联网主机的应用与支持要求IETFRFC1652SMTP8bitMIME传输IETFRFC2234语法规范的扩展巴科斯范式:ABNFIETFRFC2821简单邮件传输协议IETFRFC2822互联网信息格式IETFRFC3461SMTPDSN扩展IETFRFC3463增强的邮件系统状态码IETFRFC3464投递状态通知IETFRFC3490国际化域名应用IETFRFC3492一种适用于国际化域名应用的对UNICODE的编码方法:PunycodeIETFRFC3629UTF-8编码IETFRFC4409邮件信息提交IETFRFC5234增强的BNF范式IETFRFC5248增强的邮件系统状态码登记IETFRFC5337国际化电子邮件格式的投递状态通知要求YD厅2144-20103术语、定义和缩略语3.
1术语和定义下列术语和定义适用于本标准.
3.
1.
1电子邮件在计算机网络上,用户终端之间往来的信函.
3.
1.
2最终投递MTA一种SMTP月民务器,它可以控制邮件地址本地部分的格式并且允许检查和解释地址的本地部分,它从网络接受信息投递给邮箱或者其他本地过程而不是中转(relay).
从网络的观点来看,任何本地的投递安排,比如保存在一个信息仓库,转交给特殊的信息投递程序或代理以及获取信息机制全都是在最终投递MTA之后,因此并不是SMTP传输或者最终投递MTA过程的一部分.
3.
1.
3Unicode字符Unicode根据其位置或码位来识别字符,给每个字符提供的一个惟一的数字.
比如说,U+12AB指的是在Unicode3.
2表中位于12AB处的字符.
本标准参考了Unicode标准3.
2版本(等同于ISO10646).
Unicode字符集包含ASCII字符集.
3.
1.
4UTF-8Unicode是分配整数给字符的编码表,UTF-8是将Unicode中的一串字符表示为一串字节的方法.
在UTF-8中,字符采用1-6个8bit字节的序列进行编码.
仅仅一个8bi序节的一个序列中,字节的最高比特为0,其他的7bit用于字符值编码.
n(n>1)个8bit字节的一个序列中,初始的8比特字节中高n比特为1,接着一比特为0,此字节余下的比特包含被编码字符值的比特.
接着的所有8bit字节的最高比特为1,接着下一比特为0,余下每个字节6bit包含被编码字符的比特.
3.
1.
5ASCII地址如果一个地址中的每一个字符都属于ASCII字符集,且符合IETFRFC821中规定格式的,那么这个地址是"全部ASCII''的地址或者是一个"ASCII地址".
3.
1.
6UTF8SMTP地址如果电子邮件地址中至少有一个字符满足属于Unicode字符集但是不属于ASCII字符集,那么这个地址被称为'`UTF8SMTP地址".
3.
1.
7中文域名ChineseDomainName含有中文域名字段的域名.
3.
1.
8中文电子邮件头YD汀2144-2010含有《互联网中文电子邮件地址格式的邮件头技术要求》所规定的信息的电子邮件头部.
3.
1.
9il8mail用户一个"i18mail用户',指拥有一个或多个UTF8SMTP地址,这些用户可能也拥有ASCII地址.
如果用户拥有多于一个账户和相应的电子邮件地址,或者同一个电子邮件地址有多于一个别名,他可以通过某种方法选择在发出的邮件中使用哪个地址,在这种情况下,是不可能通过地址来辨别发件人或者收件人是否是一个i18mail用户.
3.
1.
10信息message一个信息是从一个用户(发送者)利用特定的电子邮件地址发送到另一个或者多个接收电子邮件地址(经常仅仅称作用户或接收用户).
3.
1.
11追踪头tracefield邮件头部信息中为了追踪邮件所经过的路径而专门设的主机字段.
3.
1.
12Punycode一种编码转换规则.
运用这种规则应可实现Unicode字符串和ASCII字符串的相互转换.
详见IETFRFC349203.
1.
13中文电子邮件系统支持本标准的邮件系统.
3.
1.
14ASCII电子邮件系统只支持IETFRFC822和IETFRFC2822所规定的ASCII格式形式地址的邮件系统.
3.
1.
15电子邮件地址本地部分电子邮件地址"@"的左半部分.
3.
1.
16电子邮件地址域名部分电子邮件地址"@"的右半部分.
3.
1.
17邮件交换MaileXchanger专门负责"处理"或者"转发"某个域名的邮件的主机.
3.
2缩略语下列缩略语适用于本标准.
ACEASCIICompatibleEncodingASCII兼容编码CDNChineseDomainName中文域名YD厅2144-2010CDNADNSEmailESMTPMDAMSAMTAMUASMTP4协议概述ChineseDomainNamesinApplicationsDomainNameSystemElectronicMailSMTPServiceExtensionsMessageDeliveryAgentMessageSubmissionAgentMailTransferAgentMailUserAgentSimpleMailTransferProtocol中文域名与应用域名系统电子邮件简单邮件传输协议扩展邮件递送代理邮件提交代理邮件传递代理邮件用户客户端简单邮件传输协议中文电子邮件地址包括两部分,本地部分和域名部分.
互联网协议使用电子邮件地址的方法与使用域名的方法是不同的.
最显著的不同是电子邮件是通过一系列的邮件服务器来投递的,而域名通过服务器解析来获得结果.
电子邮件传输协议SMTP和ESMTP提供了一个协商机制,客户端服务器可以通过这种机制决定以后的动作.
所以中文电子邮件地址的实现方式不同于中文域名的实现(CDNA).
电子邮件可以通过开发协商机制来解决而CDN不能使用协商机制,所以中文电子邮件地址应该在传输层通过协商机制来解决.
本标准规定的技术协议是一个基于MTA的解决方案.
本标准规定了中文电子邮件地址投递的SMTP扩展,也涉及了向下兼容现有电子邮件系统的降级机制.
4'协议要求5.
1总体要求本标准要求更新现有的SMTP协议和电子邮件地址的格式以便允许中文电子邮件地址的显示和传输.
下面具体从SMTP月及务器端来具体要求协议的实现.
为了使用中文电子邮件地址,我们需要同时处理中文电子邮件地址的域名部分和本地部分.
电子邮件的域名部分已经通过CDNA(见IETFRFC3490)得到了处理,但是没有具体规定如何处理邮件地址的本地部分.
原始的互联网电子邮件的地址的语法将域名部分限制为一个7bitASCII的子集,对于本地部分并没有做过多限制,这些限制在IETFRFC2821中定义.
为了能够投递中文电子邮件地址通过SMTP服务器,我们需要升级SMTP服务器来支持中文电子邮件地址.
老的SMTP服务器和邮件阅读客户端以及其他相关的邮件系统可能没有准备处理好中文电子邮件地址,基于SMTP的UTF8SMTP扩展被定义来识别和保护这样的系统.
本标准规定了电子邮件传输机制的扩展以允许信息的信封和头部域中存在非ASCII字符的中文电子邮件地址.
5.
2中文电子邮件的SMTP扩展框架SMTP协议要求进行扩展来支持中文电子邮件地址,并遵循以下原则:1)SMTP服务扩展名称是"邮件地址国际化E-mailAddressInternationalization"2)与本扩展相关的EHLO关键字值是"UTF8SMTP".
YD汀2144-20103)EHLO命令不带参数.
客户端要忽略该命令的任何参数.
服务器端一旦在EHLO响应里包含了UTF8SMTP,就要实现本标准规定的扩展功能.
4)一个可选的参数是ALT-ADDRESS被加入到MAIL和RCPT命令中.
ALT-ADDRESS规定了在做向下兼容ASCII邮件系统时作为中文电子邮件地址的的替代ASCII地址.
更详细的规定如何应用ALT-ADDRESS,见IETFRFC5504《互联网中文电子邮件地址与普通邮件系统兼容技术要求》.
5)一个可选的参数是'`UTFSREPLY',被加入到VRFY和EXPN命令中.
参数UTF8REPLY没有具体的值,它标示SMTP客户端可以接受发送VRFY和EXPN命令后的返回信息可以是用UTF8编码的Unicode字符串.
6)本扩展没有定义其他命令.
7)如果服务器支持本扩展,必须也要支持8BITMIME扩展.
8)MAIL和RCPT中的reverse-path和forward-path允许UTF-8编码的邮件地址.
9)邮件消息体也进行了扩展,详见IETFRFC5335《互联网中文电子邮件地址格式的邮件头技术要求》.
10)由于增加了ALT-ADDRESS关键字和值,MAIL和RCPT命令行的最大长度可以增加到460个字符.
11)UTF8SMTP扩展在邮件提交协议MSA(见IETFRFC4409)上有效.
5.
3UTF8SMTP扩展一个声明了支持电子邮件地址UTF8SMTP扩展的SMTP服务器必须能够准备接受在邮箱中任何可能的位置出现UTF-8字符串.
这个字符串仍然必须按照邮箱格式的规定解释,比如将邮箱分割为来源路由(sourceroute),本地部分((localpart)和域名部分(domainpart),按规定只使用字符冒号(U+003A),逗号(U+002C),和@(U+0040).
即使SMTP月及务器支持了电子邮件地址UTF8SMTP扩展,也必须按照IETFRFC2821的要求.
除了SMTP服务器是最终投递服务器(LastMTA)之外,传输过程中的SMTP服务器不应解析邮件地址的本地部分.
对于域名部分的处理,要遵循中文域名相关标准的要求.
任何将要通过DNS查找的域名,如果不是全ASCII字符的域名,那么必须首先通过ToASCII()函数处理成CDNA定义的ACE格式,再提交给相应的DNS服务器.
.
一个SMTP客户端,如果收到的对于"EHLO',命令的响应中包含关键字"UTF8SMTP",那么可以使用UTF-8形式传输中文电子邮件地址,也允许传输含有中文电子邮件地址以UTF-8形式表示的头部.
对于域名部分的字符串,可以使用ACE传输,也可以以UTF-8形式传输.
如果原始SMTP客户端发送信息到MSA,MSA应根据CDNA规则检查域名部分的合法性.
如果服务器提供了电子邮件地址UTF8SMTP扩展,那么任何中间环节的服务器不能够以任何方式解析、或者试图改变电子邮件地址本地部分.
如果服务器没有提供UTF8SMTP扩展,SMTP客户端就不应该传输中文电子邮件地址,也不应该在邮件信息中包含IETFRFC5335《互联网中文电子邮件地址格式的邮件头技术要求》中规定的中文电子邮件地址头部,此规定适合于MIME结构中的任何层次.
(注意,以CDNA中定义的ACE编码的中文域名不在此列).
相反,如果SMTP客户端(发信人)尝试传输了中文电子邮件地址,但是遇到了不支持UTF8SMTP扩展的服务器,则SMTP客户端必须做如下四个选择之一:YD汀2144-20101)在IETFRFC4409中规定的当且仅当SMTP客户端是一个邮件传输服务器(MSA),那么它可能会对相应的服务器提供一些通用的预防措施,能够重写信封,头部或者邮件内容来使得这些部分改变为全部为ASCII字符,符合IETFRFC2821和IETFRFC2822的规定.
2)在SMTP事务中拒绝邮件,或者接收邮件然后生成和发送一个无法投递的通知.
通知要遵守IETFRFC2821.
IETFRFC3464和IETFRFC5337的规定.
3)找到一个到达目的地的允许电子邮件地址UTF8SMTP扩展的替代路由.
这样的路由可能可以通过尝试替代的MX主机(使用IETFRFC2821的规定)或者SMTP发送者可以使用的其他方法来得到.
4)当且仅当全ASCII地址对于所有的出现在回复地址和每个指定的转发地址位置上的地址是可用的,可以把一封邮件向下兼容处理成为一封全ASCII格式的邮件.
如果信封上的原始地址是全ASCII字符的或者一个中文电子邮件地址指定了一个ASCII地址作为UTF8SMTP地址的替代地址参数,那么这个ASCII地址被认为是对于某个特定地址是可用的.
1)和4)的区别在于1)是由邮件传输MSA(见IETFRFC4409)规定的,而4)是由IETFRFC5504《互联网中文电子邮件地址与普通邮件系统兼容技术要求》规定的.
5.
4邮箱地址语法扩展IETFRFC2821的第4.
1.
2节规定了ASCII形式的邮箱语法,中文电子邮件地址邮件标准针对邮箱地址主要的修改是:a)"sub-domain',的定义修改为允许原来的定义或者允许一个符合IDNA(见1ETFRFC3490)的代表DNS标签的UTF-8字符串.
b)"Atom"的定义修改为允许原来的定义或者允许一个UTF-8字符串.
这个字符串必须不能包含任何在"atext"中不允许的ASCII字符(控制字符或者图形字符).
根据上面的描述,一个中文电子邮件地址的邮箱名字(地址)应该有如下的ABNF(见IETFRFC5234)定义:uMailbox二uLocal-part"@"uDomain;替换IETFRFC2821中第4.
1.
2节中的Mailbox定义uLocal-part=uDot-string/uQuoted-string;MAYbecase-sensitive;替换IETFRFC2821中第4.
1.
2节中的Local-part的定义uDot-string=uAtom*(".
"uAtom);替换IETFRFC2821中第4.
1.
2节中的Dot-string的定义uAtom=1*ucharacter;替换IETFRFC2821中第4.
1.
2节中的Atom的定义ucharacter=atext/UTF8-non-asciiatext=uQuoted-string=DQUOTE*uqcontentDQUOTE;替换IETFRFC2821中第4.
1.
2节中的Quoted-string的定义DQUOTE=uqcontent=qcontent/UTF8-non-asciiYD厅2144-2010qcontent=uDomain=(sub-udomainI*(".
"sub-udomain))/address-literal;替换IETFRFC2821中第4.
1.
2节中的Domain的定义address-literal=sub-udomain=uLet-dig[uLdh-str];替换IETFRFC2821中第4.
1.
2节中的sub-domain的定义uLet-dig二Let-dig/UTF8-non-asciiLet-dig=uLdh-str=*(ALPHA/DIGIT/"一,,/UTF8-non-ascii)uLet-dig;替换IETFRFC2821中第4.
1.
2节中的Ldh-str的定义UTF8-non-ascii=UTF8-2/UTF8-3/UTF8-4UTF8-2=UTF8-3=UTF8-4="udomain"的值应该根据CDNA中定义的测试进行验证.
如果验证失败,那么带有udomain的电子邮件地址不能作为一个有效的电子邮件地址.
5.
5ALT-ADDRESS参数如果提供了UTF8SMTP扩展,SMTPMAIL和RCPT命令就要扩展成支持可选的ESMTP一关键字"ALT-ADDRESS".
关键字指定可选的All-ASCII地址,可能会在兼容性处理的时候用到.
如果它被使用了,就应该被赋予一个ESMTP值.
仅当ALT-ADDRESS参数所关联的主要地址是UTF8SMTP地址,且消息被做兼容性处理时,Alt-ADDRESS才有意义.
基于IETFRFC2821中关于邮件参数的定义,MAIL和RCPT命令中ALT-ADDRESS参数的使用有如下的定义.
"MAILFROM:"(""/uReverse-path)[SPMail-parameters]CRLF;更新IETFRFC2821中第4.
1.
1.
2节中的MAIL命令"RCPTTO:'甲"/uForward-path)[SPRcpt-parameters]CRLF;更新IETFRFC2821中第4.
1.
1.
2节中的RCPT命令uReverse-path=uPath;替换Reverse-path的定义.
uForward-path=uPath;替换Forward-path的定义.
uPath二""【A-d-l":"』uMailbox"";替换IETFRFC2821中第4.
1.
2节中的Path的定义.
YD厅2144-2010;uMailbox在本标准的第5.
4节中定义.
A-d-1=ALT口ADDRESS-parameter二"ALT-ADDRESS="ALT-ADDRESS-valueALT-ADDRESS-value=xtextxtext=ALT-ADDRESS参数在命令中出现次数不能超过一次.
其值必须是all-ASCII电子邮件地址.
5.
6ALT-ADDRESS用法和响应码本标准规定禁止发送带有中文电子邮件地址头部信息的邮件到不支持UTF8SMTP扩展的SMTP月民务器.
本节中规定的三位数字表示的响应码的含义和IETFRFC2821中的规定一致.
如果邮件被拒绝由于RCPT命令需要ALT-ADDRESS参数时,用响应码533表示"出现不允许的邮箱名"如果邮件被拒绝由于其他原因如MAIL命令需要ALT-ADDRESS参数时,用响应码550表示"邮箱名不可用".
当服务器支持增强邮件系统状态码(见IETFRFC3464)时,返回码"X.
6.
7"(见IETFRFC5248)表示''ALT-ADDRESS参数是必须的却未提供".
这里使用的三位的返回代码与IETFRFC2821中所定义的含义是一致的.
如果响应代码产生在DATA命令最后的',.
''之后,那么响应代码554用来表示"传输失败".
当服务器支持增强邮件系统状态代码时,响应代码""X.
6.
9"(见IETFRFC5248)表示"UTF8SMTP兼容失败".
5.
7正文部分和SMTP扩展没有ESMTP参数可以用来断定一个邮件是否为一封含有符合IETFRFC5335《互联网中文电子邮件地址格式的邮件头技术要求》规定的邮件信息的中文电子邮件,所以一个SMTP服务器如果需要精确的知道一封邮件是否含有中文电子邮件头信息的中文电子邮件,就需要解析邮件正文部分中所有的邮件头部域和MIME头部域.
电子邮件地址UTF8SMTP扩展规定了服务器必须支持8BITMIME扩展(见IETFRFC1652)来确保服务器拥有足够的能力来处理8bit数据以及避免更多复杂的编码问题.
使用国际化的邮件没有要求在MIME的信息里,邮件要出现含非ASCII字符的正文内容.
如果邮件正文内容符合要求,电子邮件地址UTF8SMTP扩展可以与BODY=8BITMIME参数一起使用.
或者如果服务器广播了BINARYMIME并且BODY=BINARYMIME相关的参数是合适的,那么也可以使用电子邮件地址UTF8SMTP扩展.
假设服务器广播了UTF8SMTP和8BTTMIME,收到了至少一个非ASCII地址,有或者没有替代地址,关于MAIL命令中的"NoBODYparameter","BODY=8B1TMIME","BODY=BINARYMIME',的准确翻译是:1)如果没有"BODY"参数,那么头部包含UTF-8字符,但是所有的正文内容((body)部分是全部ASCII的(可能是作为内容传输编码的结果).
2)如果出现BODY=8BITMIME参数,那么头部包含UTF-8字符,一些或者所有的正文内容部分包含8bit面向行的数据.
3)如果出现BODY=BINARYMIME参数,那么头部包含UTF-8字符,一些或者全部正文内容部分包含二进制数据,不受行长度或者分隔符的限制.
YD汀2144-20105.
8附加的ESMTP变化和说明在邮件传输过程中,针对不同的上下文,在MAIL和RCPT命令及相应的扩展命令中包含了邮箱地址和域名.
总体的规则是当IETFRFC2821规定了邮箱的格式,这个规则期望字符串的全部都使用UTF-8;当IETFRFC2821规定了域名的格式,如果原始的格式是非ASCII,则此名称应该转换成ACE的格式.
以下的部分列出并讨论了全部的相关情况.
1)初始SMTP交换当建立了一个SMTP连接,正常情况下服务器发送由响应代码220和其他信息组成的'`greeting"消息给客户端,客户端在此之后发送EHLO命令.
客户端查询EHLO命令的响应中是否有UTF8SMTP扩展以确定服务器是否支持UTF8SMTP.
在对话过程或者EHLO的响应中出现的任何域名都必须符合IETFRFC1034关于主机名的规定.
例如,中文域名必须是ACE的形式.
2)MaileXchangers每个机构通常授权多个服务器去接收发送给它们的邮件.
这些授权过的邮件服务器通常会列在IETFRFC2821中描述的MX记录中.
当多个服务器根据邮箱的域名部分接收邮件时,本标准建议所有对应同一个邮件域的服务器选择全部支持或不支持UTF8SMTP扩展.
否则可能引起意外的向下兼容导致临时性错误,而用户可能把它当作严重的可靠性问题.
3)Trace消息当一个SMTP月及务器因为投递邮件接收一条消息,或者进行更多的处理,它必须在消息内容的开始部分插入trace("Timestamp''或者"Received")消息.
"Timestamp''或者"Received"出现在"Received''行中.
该行的用处主要是诊断邮件错误.
当SMTP月及务器做消息的"最后投递"时,它在邮件数据的开始部分插入Return-path行,这样做的主要目的是指定一个邮件地址作为当消息没有投递或者其他的邮件系统错误发生时的目标地址.
对trace消息,本标准更新了timestamp行和return-path行(见IETFRFC2821),正式的定义如下:uReturn-path-line="Return-Path:"FWSuReverse-path;代替了IETFRFC2821第4.
4节的Return-path-line;uReverse-path在本标准里有定义uTime-stamp-line="Received:"FWSuStamp;代替了IETFRFC2821第4.
4节的Time-stamp-lineuStamp=From-domainBy-domainuOpt-info";,,FWSdate-time;代替了IETFRFC2821第4.
4节的StampuOpt-info=[Via][With][ID][uFor];代替了IETFRFC2821第4.
4节的Opt-info;With的协议值讲允许使用UTF8SMTP值uFor="FOR"(FWS(uPath/uMailbox))CFWS;代替For;uPath和uMailbox在本标准相关部分有定义丫0汀2144-2010注:For参数被改变了,即允许在Fort旬中仅使用一个地址,用来与IETFRFC2821bis的定义匹配.
除了在"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信封地址,服务器不应该返回包含了非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在IETFRFC2821中有定义,表示"不能认证用户,但是会接受此消息,尝试投递".
响应代码550也在IETFRFC2821中有定义,表示"请求的行为没有被执行:邮箱不存在".
当服务器支持改进的邮件系统状态码(见IETFRFC3463)时,下面定义的改进的状态码会被使用.
与VERIFY(VRFY)或者EXPAND(EXPN)命令一起使用'`UTF8REPLY',参数使得该命令的回复中仅能使用UTF-80如果返回了一个成功响应代码(比如250),该响应可能包含用户的全名,必须包含用户的邮箱名.
它必须使用以下的格式:UserName;用户名可使用非ASCII字符.
uMailbox如果SMTP的返回中需要UTF-8字符串,但是UTF-8在返回中又不被允许,服务器支持改进的邮件系统状态码(见IETFRFC3463),其改进的状态码是"X.
6.
8"或者"X.
6.
10"(见IETFRFC5248),表示"一个包含了UTF-8字符串的回复显示邮箱名,但是客户端不允许此种形式的响应".
YD汀2144-2010如果SMTP客户端不支持UTF8SMTP扩展,但是如果在回复中接收到了UTF-8字符串,它可能不会报告此回复给用户,而一些客户端可能面临崩溃.
在响应中的UTF-8信息仅仅在上面讨论的情况下的命令中使用.
其他情况下,UTF-8文本不应该在响应中出现.
尽管UTF-8信息可以在上面定义的规则下使用,在响应中被用来表示邮件地址,此标准不允许除上述目的以外的其他目的而使用UTF-8GSMTP月及务器不应该在回复中包含非ASCII字符串,但是在本标准规定的有限的特殊情况下除外.