- 您的位置:
- 标准下载网 >>
- 标准分类 >>
- 通信行业标准(YD) >>
- YD/T 2030-2009 互联网中文电子邮件地址框架总体技术要求

【YD通讯标准】 互联网中文电子邮件地址框架总体技术要求
- YD/T2030-2009
- 现行
标准号:
YD/T 2030-2009
标准名称:
互联网中文电子邮件地址框架总体技术要求
标准类别:
通信行业标准(YD)
标准状态:
现行出版语种:
简体中文下载格式:
.zip .pdf下载大小:
708.53 KB

点击下载
标准简介:
YD/T 2030-2009.General technical specification for Chinese internet email address.
1范围
YD/T 2030规定了在互联网体系上使用中文电子邮件地址的框架体系总体技术要求,从服务器端和客户端提出相应的技术规范。
YD/T 2030适用于各级电子邮件地址注册管理机构、电子邮件地址服务提供商以及软件厂商开发支持中文电子邮件地址的应用或者服务等。
2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准。然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。
ISO/IEC 10646信息技术通用多八位编码字符集(UCS)
IETF RFC 822互联网信息格式旧版
IETF RFC 1652 SMTP扩展支持8比特MIME传输
IETF RFC 1939邮局协议第三版本
IETF RFC 2822互联网信息格式新版
IETF RFC 3454国际化字符串预处理
IETF RFC 3492一种适用于国际化域名应用的对UNICODE的编码方法: Punycode
IETF RFC 3501互联网信息交互协议第四版本.
IETF RFC 5335国际化电子邮件地址格式的邮件头技术要求
IETF RFC 5336SMTP扩展支持国际化电子邮件地址技术要求
IETF RFC 5504国际化电子邮件地址与普通邮件系统兼容技术要求
3术语、 定义和缩略语
3.1 术语和定义
下列术语和定义适用于本标准。
3.1.1
电子邮件
在计算机网络.上,用户终端之间往来的信函。

部分标准内容:
中华人民共和国通信行业标准
YD/T 2030-2009
互联网中文电子邮件地址框架
总体技术要求
General technical specification for Chinese internet email address(IETF RFC 4952,Overview and Frarnework for Internationalized Email,NEQ)2009-12-11发布
2010-01-01实施
中华人民共和国工业和信息化部发布前
1范围·
2规范性引用文件,
3术语、定义和缩略语
4协议概述
协议要求·
-IKANIKAa
YD/T2030-2009
YD/T2030-2009
本标准是互联网中文电子邮件地址系列标准之一。该系列标准预计的名称利结构如下:1.互联网中文电子邮件地址框架总体技术要求;2.简单邮件传输协议(SMTP)扩展支持互联网中文电子邮件地址技术要求:3.互联网中文电子邮件地址格式的邮件头技术要求;4.互联网中文电子邮件地址与普通邮件系统兼容技术要求;5.在POP中支持互联网中文电子邮件地址技术要求:6.在IMAP中支持互联网中文电子邮件地址技术要求:7.五联网中文电子邮件地址客户端技术要求。本标准对应IETFRFC4952《国际化电子邮件地址框架》(英文版),与IETFRFC4952的一致性程度为非等效。本标推在技术内容上与IETFRFC4952保持一致,其中第3章“术语和定义”是将IETFRFC4952中的术语和定义修改归集,并增加了一些适合本标准的特定的术语和定义:第4章和第5章则依据IETFRFC4952和IETF国际化电子邮件地址工作组的相关核心草案的基本思路,将其中有关国际化电子邮件地址的规定都转换成只针对中文电子邮件地址的规定,但是其技术思路未作修改本标准由中国通信标准化协会提出并归口。本标准起草单位:中国互联网络信息中心(CNNIC)、工业和信息化部电信研究院、中兴通讯股份有限公司、清华大学、中国移动通信集团公司。本标准主要起草人:李晓东、姚健康、曹勤光、李明栋、崔勇、段晓东。引言
YD/T2030-2009
互联网是一个基于开放互联协议的网络,电子邮件发送是互联网上的基础服务,可以用来传送互联网信息,电子邮件服务使互联网信息的传递更加快捷。传统的电子邮件地址都是ASCII格式的,随着中文域名的推广使用,人们越来越追切需要中文电子邮件地址。实现对中文电子邮件地址的支持首先应实现对国际化电子邮件地址的支持。随着互联网的发展,中文用户的数量不断增加,对于中文域名的使用需求也在增师。但是中文域名的最大应用文电子邮件地址由于缺乏相关标准,没有得到很好的应用和推广。中文电子邮件址和传统的英文电子邮件地址有较大差别,比如:中文电子邮件地址的字符集比传统的英文域名的字符集大很多。为了规范中文电子邮件地址的使用,让中文用户能够方便的通过中文电子邮件地址来使用互联网的各种应用服务,尽快制定中文电子邮件地址标准,进而推动中文电子邮件地址的使用是十分重要的。H
ikAoNikAca
1范围
互联网中文电子邮件地址框架总体技术要求YD/T2030-2009
本标准规定了在互联网体系上使用中文电子邮件地址的框架体系总体技术要求,从服务器端和客户端提出相应的技术规范。
本标准适用于各级电子邮件地址注册管理机构、电子邮件地址服务提供商以及软件厂商开发支持中文电子邮件地址的应用或者服务等。2规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标推。然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本标准。IS0/TEC10646
IETFRFC822
IETFRFC1652
IETF RFC 1939
IETF RFC 2822
IETF RFC 3454
IETFRFC3492
IETF RFC 3501
IETF RFC 5335
IETF RFC 5336
IETF RFC 5504
3术语、定义和缩略语
3.1术语和定义
信息技术通用多八位编码字符集(UCS)互联网信息格式旧版
SMTP扩展支持8比特MIME传输
邮局协议第三版本
互联网信息格式新版
国际化字符串预处理
一种适用于国际化域名应用的对UNICODE的编码方法:Punycode互联网信息交互协议第四版本
国际化电子邮件地址格式的邮件头技术要求SMTP扩展支持国际化电子邮件地址技术要求国际化电子邮件地址与普通邮件系统兼容技术要求下列术语和定义适用于本标准。3.1.4
电子邮件
在计算机网络上,用户终端之间往来的信函。3.1.2
最终投递MTA
-种SMTP服务器,它可以控制邮件地址本地部分的格式并且允许检查和解释地址的本地部分,它从网络接受信息投递给邮箱或者其他本地过程而不是中转(relay)从网络的观点来看,任何本地的投1
YD/T 2030-2009
递安排,比如保存在一个信息仓库,转交给特殊的信息投递程序或代理以及获取信息机制全都是在最终投递MTA之后,因此并不是SMTP传输或者最终投递MTA过程的一部分。3.1.3
Unicode字符
Unicode根据其位置或码位来识别字符,给每个字符提供的一个惟的数字。比如说,U+12AB指的是在Unicode 3.2表中位于12AB处的字符。本标准的Unicode字符应符合ISO/LEC10646的规定。Unicode字符集包含ASCI字符集。
Unicode 是分配整数给字符的编码表,UTF-8是将Unicode中的串字符表示为一串字节的方法。在UTF-8中,字符采用【~6个8比特字节的序列进行编码。在一个8比特字节的一个序列中,字节的高位为0,其他的7位用于字符值编码。n(>1)个8比特字节的一个序列中,初始的8比特字节中高n位为1,接着-一位为0,此字节余下的位包含被编码字符值的位。接着的所有8比特字节的最高位为1,再接着下一位为0,余下每个字节6位包含被编码字符的位。3.1.5
ASCI地址
如果一个地址中的每一个学符都属于ASCI字符集,且符合IETFRFC821中规定的格式,那么这个地址是“全部ASCI”的地址或者是一个“ASCI地址”。3.1.6
UTF8SMTP地址
如果电子邮件地址中至少有一个字符满足属于Unicode字符集但是不属于ASCI字符集,那么这个地址被称为“UTF8SMTP地址”。
中文域名Chinesadomain name
含有中文域名字段的域名。
Ascil用户
一个ASC用户只使用ASCH地址,不使用也不能使用UTF8SMTP地址。3.1.9
i18mail用户
一个“i18mai用户”指拥有一个或多个UTF8SMTP地址,这些用户可能也据有ASCI地址。如果用户拥有多于一个账户和相应的电子邮件地址,或者同一个电子邮件地址有多于一个别名,他可以通过某种方法选择在发出的邮件中使用哪个地址。在这种情况下,是不可能通过地址来辨辩别发件人或者收件人是否是一个i18mail用户。
信息 message
TIKAONIKACa-
YD/T 2030-2009
一个信息是从一个用户(发送者)利用特定的电子邮件地址发送到另一个或者多个接收电子邮件地址(经常仪仅称作用户或接收用户)。3.1.11
追踪头tracefield
邮件头部信息中为了追踪邮件所经过的路径而专门设的主机字段。3.1.12
Punycode
一种编码转换规则。运用这种规则应可实现Unicode字符串和ASCII字符串的相互转换。详见IETFRFC3492。
中文电子邮件系统
支持本标准的邮件系统。
ASCI电子邮件系统
只支持IETFRFC822和IETFRFC2822所规定的ASCI格式形式地址的邮件系统。3.1.15
电子邮件地址本地部分
电子邮件地址“@”的左半部分。3.1.16
电子邮件地址域名部分
电子邮件地址“@”的右半部分。3.1.17
POP协设
IETFRFC1939规定的邮周协议。
IMAP协设
LETFRFC3501规定的互联网信息交互协议。3.1.19
字符串预处理Stringprep
按照IETFRFC3454的规定,对字符串进行处理的过程。3.2缩略语
下列缩略语适用于本标准。
ASCII Compatible Encoding
Chinese Domain Nane
Domain Name System
Electronic Mail
InteractiveMailAccessProtocolASCH兼容编码
中文域名
域名系统
屯子邮件
交互式邮件接入协议
YD/T 2030-2009
4协设概述
Message Delivery Agent免费标准下载网bzxz
Message Store
Message Submission Agent
MailTransferAgent
Mail User Agent
Post Office Protocol
SimpleMailTransferProtocol
邮件递送代理
信息存储器
邮件提变代理
邮件传递代理
邮件用户客户端
邮局协议
简单邮件传输协议
IETFRFC3490已经允许国际化域名和中文域名CDN的使用。目前,国内还没有完全中文化的互联网名字体系。域名只是各种需要中文化的名字和标识符中的一种。在很多环境中,仪仪是中文域名并不能很好地方便用户使用中文化的互联网,需要更多的中文标识符来支持。广大中文域名用户在使用中文域名的时候都追切需要与中文域名相关的应用,与中文域名最相关的一个应用就是中文电子邮件地址的使用。
中文电子邮件地址更能符合中文互联网用户的上网。为了支持中文电子邮件地址,需要对原有的邮件系统进行扩展支持中文电子邮件地址。中文电子邮件地址的本地部分和域名部分可以先通过字符串预处理的方式米判定该电子邮件地址是否合适作为合法的电子邮件地址。电子邮件地址中文化不是简单的把SMTP信封做些改变,或修改“From,To和Ce”字段,或进行特殊的编码来显示本地的字符。为了对收到的电子邮件地址更有用,处理的中文电子邮件地址必须和它们产生时的环境保持一致。因此必须建立一个中文化电子邮件通信环境以便使用中文的用户能够很好的进行交流,需要允许在邮件的信封和信头里都能够使用UTF-8格式的字符,而这要求SMTP扩展支持UTF-8编码以允许中文电子邮件地址的发送和接收,5协设要求
5.1总体要求
本标准要求更新现有的SMTP协议和电子邮件地址的格式,以便充许中文电子邮件地址的显示和传输。下面从服务器端和客户端来具体介绍协议的实现。5.2SMTP扩展支持中文电子邮件地址SMTP协议要求进行扩展来支持中文电子邮件地址。这个扩展的关键字是“UTF8SMTP”,作为一个SMTP扩展,“UTF8SMTP”定义为:一允许在电子邮件地址中使用UTF-8字符串,包括电子邮件地址本地部分和域名部分。一允许在电子邮件地址中有选择的使用UTF-8格式的中文字符串。一要求服务器声明8BITMIME扩展[IETFRFC1652]以及客户端支持8比特传输,这样头部信息可以不用通过特殊的内容传输编码(content-transfer-encoding)就能够传输。提供必要的信息来支持向下兼容机制。支持中文电子邮件地址的中文电子邮件系统应遵循以下原则:4
TIKAONIKACa-
YD/T2030-2009
a)中文电子邮件地址可能会进入不同的系统或子系统,这些系统可能会对中文电子邮件地址进行学符转换或进行编码转换。如果电子邮件地址的本地部分含有中文,域名部分不宜使用punycode编码来显示给用户,以保持编和式的一致性。b)→个SMTP中继可以有以下选择:1)或者明确的识别格式,可以通过ESMTP的“UTF8SMTP”声明,来明确标示支持中文电子邮件地址:
2)可以选择和使用ASCI地址,对信息进行处理以便与现有的ASCII电子邮件系统兼容:3)拒绝发送邮件,然后给发送者返回一个未投递通知信息,这样发送者可以采取其他方法米发送邮件,如果因为下一跳的系统不支持“UTF&SMTP”扩展,前.没有足够的信息可以利用实现降级,那么必须拒绝或者产生并且发送一个未投递信息给发送者。c)自前没有…一种可行的方法来正确识别TF-8学符,允许多种编码的字符容易弓起混乱,恶不利丁世界范围内的邮件的互通互联,本标准规定在电子邮件地址及其头部禁止使用非UTF-8编码的字符。在SMTP服务器做DNS域名记录查询时,应遵循IETFRFC3490中规定的格式,以punycode编码的ACE格式向DNS服务器提交数据·
5.3邮件头和信封支持中文电子邮件地址传统的邮件信息格式只允许ASCI字符出现在邮件头里,本标雅要求中文电子邮件地址系统必须允许非ASCI字符出现在邮件头垦,这些字符是以UTF-8编码格式的UNICODE-符,通过UTF-8编码传输电子邮件头部域。
允许在邮件头里使用非ASCII字符,会影响SMTP客户端、SMTP服务器,邮件用户客户端和网关等各种解析和处理邮件信息的进程。在IETFRFC5336里规定了用“UTF8SMTP”扩展来阻止非ASCII孚符的传输,来避免在传输过程中带有邮件头的信息被错误解析。使用“UTF8SMTP”扩展并不能阻止非ASCI邮件头信息传递给邮件存储器,如果这些存储器没有更新支持中文电子邮件系统,可能不会正确解析这些邮件信息,因此这些存储系统如POP、IMAP等也必须更新支持中文电子邮件地址系统。本节的日的是允许非ASCI字符在邮件头里传输,并不规定如何将这些信息传递给非中文电子邮件系统。TTETFRFC5504规定了在邮件传输过程中遇到不支持中文电子邮件地址系统的SMTP服务器时候的具体处理办法。在邮件头里将主要做如下变化:a)允许邮件头里出现UTF-8编码的UNICODE学符b)在MIME头里增加message/global类型:c)邮件头的语法格式进行扩展支持UTF-8编码d)追踪头(tracefield)的格式语法更新。5.4兼容现有的ASCI电子邮件系统由于中文电子邮件系统的出现,互联网上必然也存在ASCII电子邮件系统。对于任何SMTP扩展机制,都有可能一个SMTP客户端要求一些性而服务器并不支持要求的属性。如果:个信封地址或邮件头信息包含非ASCI字符,这封邮件就不能投递给不支持UTF-8扩展的SMTP服务器。对于中文电子邮件地址的投递,需要在传输过程中每一个邮件服务器都支持“UTF8SMTP”扩展。当其中的个别服务器不支持这个扩展时候,在IETFRFC5336中规定了4种方法来处理。如果客户端使用的电子邮件地址中带有服务器端可以使用的alt-address参数,本标准规定可以依照本节描述的方法进行向后兼容处理。对于发送服务5
YD/T 2030-2009
器的选择基本上处丁发送者客户端的控制之下,并且中问可能的中转服务器的选择也可能在最终投递MTA服务器的管理之下。为了中文电子邮件能够顺利的投递,发送服务器和最终投递的服务器的管理考应该尽可能的使传输过程中所涉及到的邮件服务器都支持中文电子邮件地址系统。1ETFRFC5504规定了具体的向后兼容支持中文电子邮件地址系统的详细要求。向后兼容机制可以在行使SMTP客户端功能的MUA、MSA和MTA端实现,也可以在MDA、POP和IMAP等存储邮件端实现。向后兼容机制应尽量保护原来的信息不受被坏。向后兼容机制主要包含下列4个部分:a)新的头学段定义;
b)SMTP向后兼容;
c)邮件头字段向后兼容:
d)MLME头字段向后兼容机制。
5.5POP扩展支持中文电子邮件系统5.5.1 LANG 能力
POP3允许大多数的响应需要返问给用户可读的文本,但是POP3协议规定这些文本必须用ASCII字符。LANG功能和命令允许POP3客户端与服务器协商应该使用什么语言来传递这些文本。为了简化解析,所有的POP3服务器都应允许中文字符5.5.2UTF8 能力
这个功能向POP3增加UTF8\命令,这个命令切换会话进程从ASCI到UTF8模式。邮件投递系统可以存储UTF8格式的信息或只存储ASCI格式的字符或二者都可以。UTF8模式对邮件投递系统中的ASCII格式的信息没有影响。在UTF8模式下,UTF8和ASCII信息都被不经转化的直接发送给客户端,如果不是UTF8模式,那么邮件投递系统中的UTF8信息必须使用IETFRFC5504中的方法做向下兼容的处理。5.6IMAP扩展支持中文电子邮件系统现有的IMAP基础协议禁止在基础字串中或带引号的字中中使用8位的字符。支持中文电子邮件地址的IMAP应扩展支持“UTF-8”能力从而支持8位学符,应允许IETFRFC5335规定的邮件头格式,同时也要确立一种机制来支持UTF-8格式的邮箱名字和登录用户名及密码,TMAP客户端使用ENABLE命令来通知服务器可以使用与UTF-8相关的机制。5.7邮件客户端扩展支持中文电子邮件系统邮件客户端具有和邮件提交代理MSA相互作用的界面来发送邮件,和邮件存储交互来收取邮件。收取邮件的接口直接进入文件系统或进入POP或IMAP服务器。客户端也提供了用户界面,允许终端用户读取、显示、撰写邮件。
支持中文电子邮件地址的客户端应该有能够支持UTF-8格式的字符的能力。对于一个支持UTF8SMTP的MUA,会遇到多种可能性,基于电子邮件信封和正文是否包含非ASCII学符以及MSA是否支持UTF8SMTP扩展等问题。
如采MSA不支持UTF8SMTP扩展的话,MUA不应该发送带有UTF8SMTP头部的信息,可以采用IETFRFC5336中提供的4种方法来处理,这4种方法是:一用ASCII重写部:
—拒绝信息:
KAONIKACa
一寻找一个能够到达目的的替代路由(如果客户端与MSA通过接口相连MTA):向下兼容信息。
YD/T2030-2009
在邮件的接收过程中,有可能原始的邮件是一个UTF&SMTP邮件而在传输过程中向下兼容为ASCI。一个邮件头部如果有一个或者多个头部带有前缀\Downgraded-\的字段,可以确认这封邮件在传输过程中进行了向下兼容处理。
中华人民共和国
通信行业标准
互联网中文电子邮件地址架总体技术要求YD/T 2030-2009
人民邮电出版社出版发行
北京市崇文区夕照寺街 14 号A座邮政编码:100061
北京新瑞铭印刷有限公司印刷
版权所有不得翻印
开本:880×12301/16
印张:0.75
字数:22千字
2010年1月第1版
2010年1月北京第1次印刷
ISBN 978 -7-115 -1969/10 - 31定价:8元
-KANIKACa
600000
小提示:此标准内容仅展示完整标准里的部分截取内容,若需要完整标准请到上方自行免费下载完整标准文档。

标准图片预览:





- 热门标准
- YD通讯标准标准计划
- DZ/T0064.29-2021 地下水质分析方法 第29部分:锂量的测定火焰发射光谱法
- YD/T1757-2008 电信网和互联网管理安全等级保护检测要求
- YD/T1764-2008 IP 网络管理层功能要求
- YD/T1769-2008 光线路保护管理系统技术要求
- YD/T1759-2008 非核心生产单元安全防护检测要求
- YD/T1786-2008 移动多媒体广播业务业务保护技术要求
- YD/T1770-2008 接入网用室内外光缆
- YD/T1789-2008 移动多媒体广播业务终端/卡设备技术要求
- YD/T1765-2008 通信安全防护名词术语
- YD/T1121-2001 信息寻呼网络数据传输协议(FLEX 部分)
- YD/T1460.4-2006 通信用气吹微型光缆及光纤单元 第4部分:微型光缆
- YD/T1460.5-2006 通信用气吹微型光缆及光纤单元 第5部分:高性能光纤单元
- YD/T1790-2008 移动多媒体广播业务应用层接口技术要求
- YD/T1118.2-2001 光纤用二次被覆材料 第2部分:改性聚丙烯
- YD/T1533.2-2006 固定网多媒体消息业务技术要求 第2部分:多媒体消息业务接口
网站备案号:湘ICP备2023016450号-1