GB T 16520-1996 消息处理 电子数据交换消息处理业务.pdf

1、中华人民共和国国家标准消息处理电子数据交换消息处理业务发布实施国家技术监督局发布前言本标准等同采用国际电报电话咨询委员会现国际电信联盟制定的建议消息处理电子数据交换消息处理业务编写格式遵循了标准化工作导则第单元标准的起草与表述规则第部分标准编写的基本规定的规定本标准主要包括下列内容消息处理业务消息处理系统责任与转发命名寻址和号码簿的使用安全与物理投递业务的互通为使用的消息存储服务要素及服务要素的分类服务质量本标准的附录和附录都是标准的附录本标准的附录附录和附录都是提示的附录本标准由中华人民共和国邮电部提出本标准由邮电部电信科学研究规划院归口本标准由邮电部数据通信技术研究所负责起草本标准主要负责

2、人陈淑仪前言国际电报话咨询委员会负责研究技术的操作的和资费的问题并且为了实现全世界电信标准化对上述问题发布建议每年召开一次的全体会议确定研究课题并批准由各研究组起草的建议在两次全体会议之前的成员可按第号决议年订于墨尔本拟定的程序批准建议建议由第研究组起草并根据第号决议的程序于年月日被批准中华人民共和国国家标准消息处理电子数据交换消息处理业务国家技术监督局批准实施引言本标准是有关消息处理的一组标准之一这一组标准为由任意个合作开放系统组成的消息处理提供了一个综合性的规范消息处理系统和服务能使用户在存储转发的基础上交换消息由某个用户始发者提交的一份消息由消息传送系统即一个较大型消息处理系统的基本组成

3、部分加以运送然后投递给一个或多个其他用户消息接受者一个是由各种各样的互连功能实体组成的消息传送代理合作完成存储转发式的消息传送功能消息存储为消息提供存储功能并提交检索和管理这些消息用户代理帮助用户访问访问单元提供接至其他通信系统的和各种类型的服务例如其他远程信息处理业务和邮政业务的连接本标准规定了称为消息处理的消息处理应用的总的系统与业务说明范围本标准规定了消息处理的总系统与业务在其他标准中规定了消息处理系统与业务的其他方面消息处理系统和业务诸标准布局示于表系列标准规定了在上构成的公用业务以及公用业务对间的查互访问系列建议规定了技术方面的内容在建议中规定了总的系统结构在建议中规定了消息处理技术

4、方面的内容引用标准下列标准所包含的条文通过在本标准中引用而构成为本标准的条文本标准出版时所示版本均为有效所有标准都会被修订使用本标准的各方应探讨使用下列标准最新版本的可能性消息处理系统与业务综述消息处理系统文本消息处理面向消息的文本互换系统和业务综述消息处理业务公用消息处理业务的命名与寻址消息处理业务与公用物理投递业务的互通消息处理系统总体结构面向消息的文本交换系统总体结构消息处理系统消息存储抽象服务定义面向消息的文本交换系统消息存储抽象服务定义消息处理系统电子数据交换消息处理系统面向消息的文本交换系统号码簿模型信息处理系统开放系统互连号码簿模型号码簿鉴别框架信息处理系统开放系统互连号码簿鉴别

5、框架号码簿已选的客体类别信息处理系统开放系统互连号码簿已选客体类别定义本标准采用下列定义以及附录中的定义本标准的附录中包含有适用于消息处理的服务要素的定义在本标准中提出了适用于消息传送业务和由消息处理所用的服务要素但其定义则放在的附录中转发将收到的向前传送给由进行转发的用户代理消息存储决定的一个还是多个接受者在已投递到某个用户代理或消息存储的消息向前转发给另一个用户代理或消息存储时发生转发消息在消息处理用户间传送电子形式的信息消息在消息处理用户间运送的主信息客体类别的成员参见的第章消息处理用户参与消息处理的用户消息处理用户始发接收或既始发又接收消息消息处理环境包含任意数目的消息处理用户消息处理

6、用户可以是人也可以是计算机进程消息处理用户可通过访问单元访问消息处理系统通知次信息客体类别的成员它给消息的始发者指出消息的责任的安排消息责任消息责任指出某个特定的用户是否已通过它的用户代理消息存储提供可用的主题消息消息责任在本标准和建议中不具有法定意义缩略语美国国家标准协会访问单元号码簿信息树分发表号码簿用户代理电子数据交换电子数据交换用于行政商业和运输消息消息处理环境消息处理消息处理系统访问单元消息存储用户代理通知已转发通知标识符管理域消息处理消息处理系统消息存储消息传送消息传送代理消息传送系统未投递通知否定通知始发者接受者物理投递物理投递访问单元物理投递系统肯定通知专用管理域远程信息处理代

7、理用户代理联合国贸易数据交换协调通用时间约定在第章中引用的是取得一致的标准使用大写字母时尽可能地使用通用语言习惯消息处理业务引言消息处理业务给消息处理用户提供一些特性以便有助于与其他消息处理用户消息处理在大多数情况下消息处理用户是计算机进程消息处理业务利用消息传送业务的能力参见发送和接收消息描述消息处理业务特性的服务要素在附录中定义并在第章中进行分类电子数据交换可描述为计算机与计算机之间结构化的事务数据交换例如发票和购货单在某些情况下消息处理业务可用来将一次互换发送到物理呈现系统例如物理投递系统或传真机消息处理业务由消息处理提供消息处理消息处理由消息的交换和通知组成这些消息和通知均是在中规定的

8、信息客体消息处理环境消息处理产生的环境可以被模型化为以下称为消息处理环境的功能客体细分按功能分解时可以看作是由称为消息处理主客体的更小客体组成这种主客体包括单个中心客体消息处理系统和若干个称为消息处理系统用户用户的外围客体结构见图图消息处理环境消息处理用户消息处理用户用户是参与消息处理的用户用户可以始发接收或者既始发又接收可包含任意数目的用户用户可以是人也可以是计算机进程用户通过访问单元访问消息处理系统引言消息处理系统是所有用户都通过相互进行消息处理的功能客体可被模型化为由更小的相互作用的功能客体组成这些更小的功能客体称为消息处理的次客体它们包括单个中央客体即消息传送系统和三个种类的若干个外围

9、客体用户代理消息存储和访问单元结构见图如图所示和是用来给用户提供业务的客体图消息处理系统用户代理用户代理是定制成更适用于单个用户参与消息处理的用户代理它帮助用户始发和接收含有的消息包含任意数目的注和用户间的边界的确切定义已超出本标准范围消息存储消息存储是定制成更适用于单个参与消息处理的消息存储它帮助提交投递存储和检索含有的消息消息传送系统在目前的情况下消息传送系统在间或在与访问单元间运送或通知包含有单个用户可以通过访问单元访问或接受的访问其中一种类型的访问单元是物理投递访问单元在中物理投递访问单元通过物理投递系统向接受者提供发送消息的能力其他类型的例如传真访问单元可能是将来标准化的课题中的信息

10、流图是对图的扩展并示出消息处理中的主信息流注缩写词和缩写语见本标准的第章和附录图消息处理信息流程消息处理业务的功能模型图示出消息处理业务的功能模型消息处理业务中所用的由一类特定类别的合作的组成任选的准许用户发送消息给消息处理环境外的间接用户消息处理业务中所用的消息存储具有专用的相关功能并可由用户任选地用来代表它们自己投递消息图中所示的远程信息处理代理准许访问远程信息处理业务它可能是将来标准化的课题图消息处理业务的功能模型消息的结构类的创建含有消息处理业务特定内容的消息从一个发送给另一个的特定内容是始发者的结果这个始发者通常是一个应用进程它组成并发送消息该消息称为消息携带交换信息并可选用地携带交

11、换有关的其他信息在一个中只包含一个交换每个在始发时应包含一个交换的信体部分转发时除已转发信体部分不能被移出外任何后续的信体部分都可以被移出全部移出而不是部分移出转发时用位置留用区代替被移出的信体部分以指出何种类型的信体部分被移出转发时的标题是不应被移出的结构当它与基本消息结构有关时示于图当通过传送时是用信封传送图消息结构图一个典型的交易的消息结构图中所示的典型的交换与相应的消息结构间的映射交换可以全部映射到称为主信体的信体部分内交换可以是或专门定义的交换其他信体部分可以用来运送与该交换相关的信息例如图或解说性文本等标题包含各种信息字段有些信息字段可以出现在交换头部字段中或是对应的或段其他的信息

12、字段包含来自始发者的业务请求标题和信体部分形成通知用户可请求接受者返回一个通知指明收到的消息的安排该通知由始发提出请求并由接受者或生成请求和报告有三种可能的状态导致生成肯定通知否定通知或已转发通知和响应的意义按的描述收到的消息可原样转发响应通知请求的责任也有可能转发给被转发消息的接受者或中间接受者中间接受者则应有责任对消息的原始发者进行响应始发可请求告知响应通知请求的责任是否已转发在这种情况下转发的或应给始发发送已转发通知在所有情况下包括已被转发的发送的通知都应包含由原始发者所指定的接受者的名始发可向任意组合的发送接受者请求若干个任意组合的若始发者没有请求通知则接受者什么也不应发送责任与转发引

13、言包括一种称为责任的概念这种概念是下面描述和转发的关键为简化下面文本的描述起见所示的所有转发由来完成应当注意的是这里描述同样适用于完成的转发引入责任概念的目的主要是在之间提供一种运送消息证实的方法在某种情况下责任可适用于访问单元责任的概念描述如下责任指出接收所收到的可为用户所用当转发时不论增加还是移出信体部分责任总应当被接受不能离开除非责任已被接受投递到是一种特殊情况按的描述若始发请求这样做则接受者以及可能是中间若请求应给始发发送接收时若被请求有它应发送适当的通知始发接受者已接受或拒绝责任发送的各种情况在后面中详细说明若请求通知则当接受拒绝或转发责任时它应发送适当的给始发者若转发它应在已转发的

14、中创建适当的标题字段这些操作的详细情况在中描述被转发的信体部分无论如何是不能被修改的若责任被转发被转发的无论如何也是不能被修改的若责任被接受则在创建已转发的时信体部分可从始发移出也可以加到始发上转发时被移出的信体部分可用位置留用区代替以指出何种类型的信体部分被移出责任转发的接受者只限于一个包括转发时防止环路的机制转发和二次分发在中可能希望由中央的用户代替接收消息然后再转发给最终的用户代理例如这种做法使大型的组织能对进入该组织的全部消息业务量执行例如日志审计等集中的功能在这些功能执行后消息处理业务量可分配给为接受者应用服务的用户代理同样增值网络的业务提供者也可代表它的用户操作一个类似的中间步骤下

15、面描述了如何将用作这个中间步骤中间的通常不是最终的因此在中需要对提供责任接受端对端的证实通知请求服务要素准许始发者从每个接受者请求发回肯定否定和已转发通知通知请求允许中间的用已转发消息和建议所定义的协议要素指出是否已接受责任这些方法准许责任接受推迟到到达最终的并提供一个指示表明哪一个将给原始发者返回一个通知为了说明作为中间步骤的使用情况下面描述三种情况无论在那种情况下都始发于和终结于是中间在情况和情况中假设是内容不改变的转发在所有三种情况下均假设已请求通知注下列表中所描述的事件都不必按表中所给出的顺序严格执行情况无转发制备的寻址到提交给然后传送给再投递给最后由用户检索用适当的响应接受责任即若已

16、决定用户不能检索消息用响应拒绝责任即信息流按图中所示和的顺序在表中列出传送的方向传送的方向图情况无转发表情况无转发事件提交至传送至投递至提交至传送至投递至情况内容不改变和转发责任在这种情况下中间将消息从转发到最终的接受者是执行转发操作将责任转发给由制备的寻址到投递给时根据已知道的选择准则把它不改变地转发给责任处理如下转发责任时它应创建已转发使接收请求的详见建议这样就可发送下列若请求转发责任通知就给发送已转发通知成功地将提交给时就可发送若从经接收未投递通知它可给发送否定通知注意在这种情况下可以选择发送或不发送不可以请求或发送其他的例如不能向请求通知也不能给发送在未投递的情况下可试图重新提交给指定

17、的接受者在这种情况下只有当决定不再试图重新提交给时才发送给若转发成功应发送适当的给接受或拒绝责任图中表明上述情况所描述的信息流和可能的顺序解释在表中解释事件和和和是相互排斥的和传送的方向传送的方向图情况责任转发表情况责任转发事件未投递通告提交至传送至投递至若请求提交至把要转发提交至传送至传送至表完事件未投递通告发送至投递至投递至提交至提交至传送至传送至投递至投递至应注意下列事项若请求已转发通知它通常会接收到若干个可不按创建时的顺序来接收无论是否请求了也有可能接收不到例如将投递给后发生了灾难性的故障由正确处理以上三项例如通过跟踪下列内容对第一项进行处理原接受者提交时间和预期的通知可以使用在中包含

18、的时间创建时间来对第二项进行处理第三项可用的超时机制来处理处理以上三项的机制是属于本地的实施事宜因而超出本标准的范围情况不转发责任这种情况是制备的寻址到先接受消息的责任再转发给例如若在转发改变内容时增加或移出信体部分则就会出现这种情况在接受责任时发送给始发者即并创建已转发这样始发者就不能再接收更多的详见建议同情况一样将寻址到与前述的两种情况一样表示最终目的地检索到时给返回一个适当的通知于是该消息转发给由于现在已接受了初始责任可根据需要自由地请求或不请求责任若请求其结果是责任的关系只在和间应用与前面的情况不同不是端对端的这里描述的前提是假设已被请求责任从而用适当的通知来响应图和图给出了情况的信息

19、流和的顺序解释都在表中解释传送的方向传送的方向图情况不转发责任第一部分传送的方向传送的方向图情况不转发责任第二部分表情况不转发责任事件图图提交至传送至投递至提交至把要转发提交至传送至传送至投递至投递至提交至传送至投递至命名寻址和号码簿的使用的第章对号码簿规定的使用是用来提供了消息处理所需的号码簿的业务每个管理域都应给它的用户提供号码簿业务消息处理命名和寻址及后来的号码簿业务要求列于本标准的附录安全的第章中规定的安全能力也适用于消息处理另外对的提供了下列扩展扩展的安全能力的概述如下通知证明使的接受者能创建一个的接受者可用此来鉴别的始发者通知不可否认给的接受者提供了源的证明防止的始发者再有任何试图

20、否认发送了接收内容证明使的始发者能验证接受者所收到的消息内容与始发者始发的消息内容相同始发内容不可否认给的接受者提供所收到的消息内容与始发的消息内容有相同的证明这就防止始发者再有任何试图否认始发的消息内容接收内容不可否认给的始发者提供所收到的消息内容与始发的消息内容有相同的证明这就防止接受者再有任何试图否认所收到的内容表部件提供和使用的安全消息传输的服务要素服务要素始发者接受者通知证明通知不可否认接收内容证明始发内容不可否认接收内容不可否认服务提供者服务用户附录描述脆弱性并详细介绍各种脆弱性的克服方法的附录描述了所需的对安全模型的增强增强型安全服务描述了安全服务的操作和规程与物理投递业务的互通

21、引言与所规定的一样互通是消息传送业务的类属能力若要使用这种能力始发者在提交时可采用邮政地址或者在提交时若采用号码簿名则要选择物理投递作为请求的投递方法并要从服务要素中表中选择某些所需要的选项始发者按规定的接受者地址提供邮政地址这可以通过号码簿来实现投递和通知在从最终的传递到到时发生了到访问单元的投递如下面图所示与物理投递应用有关的投递通知通知按中的规定并增加了这些通知由被认为是共置的系统部件产生提供时间的定义可定义为的生成和投递注起始时间对应于生成的时间结束时间对应于用户可用的的时间责任的传递直到将发送给它的去物理再现并接着投递时决不能为接受责任若要求通知请求则存在两种可能性若决定它能为物理投

22、递再现时则它应给的始发者返回一个然而若决定它不能再现或投递时则它应给的始发者返回一个物理再现的附录规定的基本物理再现的细节应作为基础主要用于路由和投递信息的呈现例如地址块相对于窗口的页面位置等对于专用于的硬拷贝物理呈现标识有三种方法标准化的再现专用定义的呈现再现的伴随信息可能是将来标准化的课题另外若可能的话假定接受者能用该信息通过其它的手段提供的指导或消息工作若没有可用的再现规则时则可简单地按原样打印增加供物理再现之用的指导和规则可能是将来标准化的课题图投递和通知的时间模型为使用的消息存储消息存储特性可用于消息处理通用的服务要素存储消息提取存储消息列表存储消息概要存储消息删除和存储消息提醒都适

23、用于消息处理描述了一般的属性和自动动作描述了专用的属性和自动动作一个专用的服务要素存储消息自动转发为消息处理提供适当的一个自动转发能力安全政策可限制消息存储服务要素的使用服务要素服务要素是的特有的特性功能或能力适用于消息处理的服务要素由服务要素和消息处理服务要素组成消息处理用的服务要素在本标准的表至表中列出在的附录中对其进行了规定专用消息处理服务要素的规定列于表至表其定义在附录中适用于消息处理的所有服务要素的实现方法在系列的其他建议中描述服务要素的分类基本的消息处理业务使用服务的基本的消息处理业务使用户能发送和接收消息用户借助用户代理制备消息相互合作帮助相应的用户间进行消息处理要发送消息时始发

24、用户将消息提交给它的指定该消息接受者的名具有标识码的消息被始发者的通过消息传送服务发送给接受者在成功地投递到接受者之后消息可供接受者使用为了方便实现有意义的消息处理接受者可在它允许投递给的消息中规定编码信息类型以及它愿意接受的消息的最大长度给每份投递的消息都提供有原编码信息类型及指明是否已完成转换的指示和最终编码信息类型另外给每份消息还提供有提交时间和投递时间基本的服务提供有未投递通知属于基本的消息处理服务的服务要素在表中列出表属于基本消息处理业务的服务要素服务要素参考访问管理内容类型指示已转换指示投递时戳指示消息标识消息标识未投递通知原编码信息类型指示提交时戳指示类型化信体用户能力登记注参考

25、是对应建议的附录参考是对应本标准的附录消息处理业务的可选用户设施消息处理业务的一组服务要素都是可选的用户设施消息处理业务可选的用户设施可以每份消息为基础选用也可以商定的合同时间内选用分别在表和表中列出以每份消息为基础选用的消息处理业务的用户可选设施由分为始发和接收两类若管理域为提供始发用的用户可选设施则用户根据相关服务要素规定的过程创建并发送消息若管理域为提供接收用的用户可选设施则接收就应能接收和识别相关服务要素的指示并能将请求可选用户设施通知给用户可从两个方面为的每个可选用户设施分类为附加的和基本的表以每份消息为基础消息处理可选用户设施服务要素始发接收参考附加物理再现允许替换接受者应用安全要

26、素基本物理再现字符集内容机密性内容完整性转换禁止丢失信息情况下的转换禁止营业处收集具有通知的营业处收集交叉参考信息延迟投递延迟投递取消投递通知经公众传真业务的投递由号码簿名指定的接受者公开其他接受者分发表扩展历程的指示禁止分发表扩展转发消息类型通知请求标准指示允许责任转发指示接收方特快专递业务日期时间到期指示显式转换投递选择等级不完整拷贝指示交换头最迟投递的指定消息流机密性消息源鉴别消息安全标记表续服务要素始发接收参考消息顺序完整性多址投递多部分信体始发内容不可否认接收内容不可否认接收内容不可否认请求投递不可否认通知不可否认通知不可否认请求源不可否认提交不可否认废弃指示普通邮件始发者指示始发者

27、请求的替换接受者进行的物理投递通知进行的物理投递通知允许物理转发禁止物理转发防止未投递通知探查探查源鉴别接收内容证明接收内容证明请求投递证明通知证明通知证明请求提交证明接受者指示始发者不允许改投挂号邮件给个人的挂号邮件相关消息报告源鉴别转发地址请求请求投递方法业务指示特种投递存储消息删除存储消息提取表完服务要素始发接收参考存储消息列表存储消息概要带有返回物理消息的不可投递邮件分发表的使用应提供可选基本用户设施只适用于的基本可选用户设施只适用于的基本可选用户设施可提供的附加可选用户设施不适用和相关至少应能支持或特种投递注若由接收归纳为类服务要素则需要双方协议参考对应的附录参考对应本标准的附录表在

28、商定的合同时间内消息处理可选用户设施服务要素分类参考替换接受者的指定保持投递隐式转换登记入消息改投有限制的投递安全访问管理存储消息自动转发存储消息提醒存储消息自动转发该服务要素将在的下一个版本中定义并指定为号码它所描述的能力在中支持但在中未描述对于消息处理不鼓励使用这个一般能力的服务要素存储消息自动转发是专用的能力可提供一种合适的替代者注参考对应的附录参考对应本标准的附录业务质量消息状态每份消息的唯一的标识使系统能提供例如与一份消息状态有关的信息在系统出故障时所有收到的和未投递的消息都应是可跟踪的若消息不能投递则应通过未投递通知业务提供者的支持就涉及的系统组成部分而言若在预定的时间内没有收到未

29、投递通知则业务提供者应给用户提供帮助对消息状态和跟踪提供的附加支持在本国的责任范围内投递和通知时间的模型投递和通知时间的模型见图投递时间注的起始时间对应于提交时戳指示所标明的时间的结束时间对应于投递时戳指示所标明的时间通知投递时间注的起始时间对应于投递时戳指示所标明的时间的结束时间对应于用户通过或可以获得投递通知的时间通知生成和投递时间注的起动时间对应于生成的时间的结束对应于用户可以获得的时间图投递和通知时间的模型消息投递时间的目标值投递时间包括传送时间的目标值取决于消息传送系统中转域的数目和消息的长度这个值为业务目前所规定的目标值要小得多若消息在提交后的小时内或是延期投递所指出的日期和时间之

30、前还未投递接受者的管理域应强制发出未投递通知的值取决于始发者请求的投递等级对业务的这些值的规定可能是将来标准化的课题通知时间的目标通知投递时间的目标值取决于本地的安排当接受方发起时的时间目标值与导致产生的消息有相同的时间目标值表时间的目标值投递等级在下述时间之前被投递加急普通慢件注与互通不包括在时间目标计算内这些值是暂定的可根据成熟的经验进行修改物理投递的业务质量见本标准的第章差错保护传输中的差错保护由提供并服从在业务规定中所提供的下层协议业务的可用性原则上业务应是连续可用的或应能连续用以提交和投递除非调用保持投递在不能连续用于投递的情况下应使用附录标准的附录术语的词汇表注下面给出的说明未必是

31、严格的定义参见附录中的定义和中的词汇表以及其他的系列建议尤其是中所提供的术语这些术语不是来自一个出处要视其来源而定应用创建与或处理消息的一个计算机进程参见交换参与方之间按有一定消息和服务段的结构化组的形式进行的消息处理这个组以交换控制头开始并以交换控制尾结束见在消息处理的情况下指的是消息的主信体部分的内容消息见本标准第章中的定义消息存储见中的定义消息处理消息处理包括消息和通知的交换以及相关的规程这些都是中规定的信息客体消息处理环境在消息处理所发生的环境可以模型化为称之消息处理环境的功能客体当细分即按功能划分时则消息处理环境可以看成是由更小的称之为消息处理的主客体组成它们包括单个中央客体消息处理

32、系统和许多称为消息处理用户的外围客体消息处理业务把一些特征提供某个消息处理用户有助于与其它消息处理用户进行通信的一种业务在许多情况下消息处理用户都是计算机进程消息处理业务使用消息传送业务能力发送和接收消息描述消息处理业务特性的某些服务要素在附录中定义并在本标准的第章中进行分类消息处理系统消息处理系统是功能客体用户通过它在消息处理中进行相互通信消息处理系统可模型化为相互作用的更小的功能客体组成这些功能客体称之为消息处理的次客体它们包括单个中央客体消息传送系统三个为数众多的外围客体即用户代理消息存储和访问单元消息处理用户见本标准中的定义注在的情况下为了简化起见术语用户具有用户的含义参见下面的通知见

33、本标准中的定义在消息处理中用户可以请求接受者返回一个通知指出它对收到的消息的安排情况该通知由发用户代理请求并由接受者用户代理消息存储或访问单元生成可能请求并报告的情况有三种导致生成肯定通知否定通知或已转发通知这个通知服务用于携带肯定通知否定通知或转发通知有可能收到一份不加改变地转发的消息并把响应通知职责转发给请求的转发接受者或中间接受者然后接受者对原始发者进行响应始发可请求给予通知响应通知请求的责任是否已被转发在这种情况下转发消息的或应给始发发送一个已转发通知在所有情况下包括消息已转发到的所发送的这类通知都应包含原始发者规定的接受者名始发可请求来自消息已发送到任意组合的接受者的任意组合的通知若

34、始发者未请求通知则接受者什么也不应发送通知不能被转发也不能为通知请求通知消息责任见本标准中的定义注责任是一种连续跟踪手段用于证实和跟踪用户代理和消息存储中消息所经过的路线安全使用了第章和第章所规定的的安全能力这些能力为消息处理系统提供安全特性消息处理系统的脆弱性及其对策概述在本标准的附录中用户见用户是一个不一定属于消息处理环境的客体在消息处理的行文中很大程度上和消息处理用户等同参见上述的和的注用户代理见中的定义注和消息处理用户两者的界限的确切定义已超出本标准的范围电子数据交换可以定义为计算机对计算机间结构化事务数据例如发票和购货单的交换在系列的行文中指的是采用的协议手段和本标准概括的业务来完成

35、交换的标准化方法功能组头在中的段名交换尾在中的段名交换见中的交换交换头在中的段名消息头在中的段名交易集头在中的段名传输开始在中规定服务串通知中规定交换头在中的段名功能组头在中的段名消息头在中的段名消息尾在中的段名交换尾在中的段名附录标准的附录服务要素的定义本附录包含只有消息处理才有的服务要素的定义本附录不包含适用于消息处理的业务的服务要素的定义这些服务要素的定义包含在的附录中标题行中的缩写词指的是该服务要素可用于在每个接受者的基础上使用为了方便查阅并与消息传送和服务要素区分开来服务要素的编号采用缩写词应用安全要素该服务要素准许始发者和接受者在标题中指出应用安全信息以支持端对端的安全服务字符集该

36、服务要素准许始发者在消息的标题中指出信体所用的字符集交叉参考信息该服务要素准许始发者在消息的标题中指出在一次交换内和该消息或其它消息的信体的部分指定的应用参考之间所用的交叉参考的信息转发该服务要素使能够有所改变地或不加改变地转发收到的并使能不加改变地转发到的转发时仍需要接收方服务要素的支持消息类型该服务要素准许始发者在消息标题中指出在交换中所包含的消息的类型例如发票和购货单等通知请求该服务要素准许始发请求某个接受者是接受拒绝还是转发责任通知给它对携带这种通知请求消息可以任何组合始发运送这个请求给接受者如果接受者接受该消息的责任则它就回送一个肯定通知并不再向该消息的始发者返回其他通知当接受者不接

37、受责任并且成功转发内容未加改变的消息时则转发接受或任一个中间就响应这个请求而言与第一个接受有相同的责任并且这个响应应由这个消息的原始发者引起的给始发者返回一个转发通知如果接受者拒绝该消息的责任或者不能成功转发该消息它就回发一个带有指出原因的否定通知给消息的始发者拒绝消息的责任的原因如下交换不能传递到用户交换不能在规定的时限内传递给用户消息在处理前已废弃在投递后但在响应前已终止接受者预约尝试转发和责任转发但未成功不能再现消息安全出错未规定的本地原因在物理投递访问单元中是无意义的因此返回一个已转发通知给始发者以取代否定通知指出该消息将不会到达用户并意指将不会被应用所处理因安全政策的关系消息存储的能

38、力可能受到限制例如在请求安全通知时就不准消息存储生成标准指示该服务要素使始发能在一份消息的标题中指出在该消息中正在使用的标准类型例如等消息标识该服务要素使合作的能为每一个已发送或收到的消息运送一个全球唯一的标识符该消息标识符由始发者的名和就其名称是唯一的标识符构成和用户使用这种标识符作为前面已发送的或收到的消息的参考例如在通知中准许责任转发指示该服务要素准许始发指出可由接受者转发该消息的责任接收方该服务要素准许始发者或转发给接受者指出请求通知应返回到这个地址日期时间到期指示该服务要素准许始发者给接受者指出始发者认为消息无效的日期和时间该服务要素的目的是要说明始发者对当前消息可用性的评价未规定接

39、受者或接受者的特定的动作可能的动作是在传递的日期到期后存档或删除该消息不完整拷贝指示该服务要素准许一个转发指出转发的消息是一份与始发消息具有同样的消息标识符的不完整拷贝在不完整的拷贝中缺少始发消息的一个或多个信体部分交换头该服务要素使始发能将交换头的数据要素放入相应的字段中多部分信体该服务要素准许始发者给接受者发送由几个部分组成的消息信体每个信体部分的特性和属性或者类型都与信体部分一起运送始发内容不可否认该服务要素使始发能为接受者提供一个不可取消的证明用此证明是对消息提交至环境时的内容确实性和完整性视现行的安全政策可用两种方式提供相应的证明数据采用用始发消息源不可否认的安全服务或通过公证机制注

40、使用的公证机制不反映在协议要素中但服从于双方协定接收内容不可否认该服务要素使始发能从接受者那里得到一个不可取消的证明用以证明始发主题消息内容已被接受者接受且责任已被接受转发或拒绝该服务提供不可取消的证明用以证明所接收内容的完整性和消息接受者的确实性该服务应防止接受者任何尝试否认后续收到的消息内容因此该服务强于接收内容证明服务视现行的安全政策可用两种方式提供相应的证明数据通过返回通知的源不可否认它应与下列内容紧密结合始发者的源不可否认变元若存在如果不存在源不可否认变元的话则是完整的始发消息内容通过公证机制注使用的公证机制不反映在协议要素中但服从于双方协定接收内容不可否认请求该服务要素使始发能够请

41、求接受者借助于通知提供给它一个接收消息内容不可取消的证明注该服务要素也要求存在通知请求通知不可否认该服务要素给消息始发者提供不可取消的证明用以证明接受者收到主题消息和责任的接受转发或拒绝该服务应防止接受者任何尝试否认后续收到的消息和已按指示那样接受的该消息责任该服务要素给始发者提供不可取消的通知证明的证明目前在的中规定的借助于源不可否认安全服务所提供的这种证明适用于通知该服务强于通知证明服务通知不可否认请求该服务要素与通知请求一起使用使始发能够请求响应提供给它以源通知不可取消的证明注该服务要素替代通知请求证明并假定已有通知请求废弃指示该服务要素准许始发者给接受者指出始发者先前发送的一个或多个消

42、息已废弃携带该指示的消息替代废弃的消息接受者或接受者的采取的这种行动是本地的应用其目的是准许或接受者例如去移出或归档一个废弃消息始发者指示该服务要素准许将始发者的身份运送给接受者接收内容证明该服务要素准许始发能从接受者得到证明证实始发主题消息内容已被接受者接收且责任已被接受转发或拒绝相应的证明是通过返回通知的源地址证明获得的证明包含始发者消息源鉴别和或内容完整性变元若有的话否则就包含完整的源消息内容接收内容证明请求该服务要素使始发能请求接受者通过通知提供消息内容已被接收的证明注该服务要素也要求存在通知请求通知的证明该服务要素准许消息的始发者获得确证的手段确切证实主题消息已被接受者接收责任已被接

43、受转发或拒绝借助于消息源鉴别安全服务所提供的这种证明目前在的中规定适用于通知通知证明请求该服务要素与通知请求一起使用使始发给请求响应的提供一个通知源证实注该服务要素假定已存在通知请求接受者指示该服务要素准许始发者给指定消息的接受者提供一个或多个用户名或名此外有可能对每个接受者规定动作请求限定符例如采取行动拷贝其他按双方规定的注该限定符表示始发者方面对于的意图但接受者不必受这个意图的约束相关消息该服务要素准许始发者将共享同一标识空间例如消息的一份或多份其他多个消息的全球唯一的标识符与正被发送的消息联系起来该接受者的例如能够从存储器中恢复一个参考消息的拷贝服务指示该服务要素准许始发者在消息标题中给

44、那些双方含义都超出本标准的服务提供者指出各种服务的请求存储消息自动转发该服务要素准许用户在接受或不接受责任的情况下消息存储拥有自动执行转发能力用户通过使用登记服务要素建立选择的标准完整的同从始发者接收一样可以不加改变地转发如果有请求可由产生一个适当的责任转发只限于一个接受者转发时仍需要支持接收方的服务要素鉴于现行的安全政策的要求消息存储的能力可能受到限制例如在请求安全通知时就不准许消息存储生成类型化信体该服务要素准许把信体的性质和特性与信体一起运送可容许的信体部分类型有信体转发的信体和外部定义的信体部分附录提示的附录安全综述引言本附录详细描述内标识的各种脆弱性和克服这些脆弱性需要的各种安全服务

45、本附录基于这样的假设即可以使用规定的各种安全消息处理服务对现有的安全服务不能有效克服各种脆弱性的情况但是规定了附加的安全服务对规定的某些安全服务是通用的消息处理特性其余的则是专为规定的对规定的安全服务是专用于的全部在中规定脆弱性下面标识的绝大多数范围中也有各种脆弱性及应用级即用户相应的服务设想本文提出的安全模型的假设这些设想超出本标准考虑的内容安全模型假设用户能为就用的操作提供足够的安全和可信的功能足以满足用户对安全政策的要求注实际上可能需要应用和共置除非建立适合两种部件的安全环境下面对各种脆弱性的描述是以附录中对威胁下的规定为依据的此外有必要考虑检查与消息顺序无关的消息丢失和信息修改同时还有

46、必要考虑目前未标识出的各种脆弱性内的安全模型未考虑到的环境中的一个重要方面是在环境中消息通路的每一阶段消息责任的概念在情况中商业服务提供者有可能要增加若干个这或许要求明确标识出责任的转发无论是对终端用户还是对这种服务提供者都要保证提供进一步的保护因此需要建立责任域的概念这又涉及到有关法律问题的其他考虑可按下列的一种可能划分责任域用户环境加管理域消息存储如果与上述两者之一没有共置假冒按附录的规定消息顺序按附录的规定用户不应假定以正确的顺序投递只要提供保护防止消息在环境中信息被修改应用就应能从消息重复和失序中恢复消息丢失消息丢失脆弱性在环境中认为是很严重的两种消息丢失的区别灾难性的或故障单个消息的

47、丢失用户和服务提供者可能需要更加周密地考虑责任域间的消息传送问题来自始发用户域中继的各域间至接受者用户域信息修改按附录的规定拒绝服务按附录的规定否认按附录的规定环境中的这种否认弱点被认为是很严重的使用某些服务例如自动转发和改向时这种弱点还会增加信息的泄漏按附录的规定用户对信息的处置共同体还附带地标识了另外的一种脆弱性消息内容的完整性在交换之后被修改即由始发者和或接受者修改这种脆弱性包括的提交不可否认后始发者本地存储中的消息内容的处理和或投递的不可否认后接受者存储中的消息内容的处理其他脆弱性规定的其他脆弱性认为是很重要的例如错误路由的选择错误投递在改向的情况下尤其重要内部威胁接受了应用不准备接受

48、的数据脆弱性的克服的第章为消息传送提供了一种抽象的安全模型这种安全模型提供了一种描述安全服务的框架这些服务可用于克服内和用户至用户间潜在的脆弱性还可用现有模型之外的安全服务来克服脆弱性下面的章节描述如何使用的安全服务规定的增强型安全服务和本标准规定的各种普遍性机制来克服脆弱性假冒能克服这种脆弱性现有的安全服务是消息源鉴别安全访问管理安全标记投递证明提交证明由于在结构中被看成是属于一个用户的所以对可能执行的各种操作都提供选择性的访问控制认为是不合适的但需要进行安全审计跟踪来记录用户的活动在本标准中这种安全审计跟踪可作为普遍性机制来实现对术语普遍性机制作了规定支持审计能力的各种协议可能是将来标准化

49、的课题消息顺序能克服这种脆弱性现有的安全服务是消息顺序的完整性这种安全服务以始发提供的整数为依据而不保证唯一性或连续性因此它的作用是有限的考虑到环境不应要求保证消息顺序的完整性但应支持顺序完整性故障的检测通过提供附加的审计日志设施和或提供第三方公证人服务在本标准中考虑从顺序差错和消息拷贝中恢复是用户的责任消息丢失消息丢失可能潜在发生在端对端的消息传输链路上例如故意破坏的活动或由于任何部件和的故障或不正确的行为有意无意的所致区别下列消息类型的丢失灾难性消息丢失即某部件出故障中单个消息的丢失无论是有意的还是无意的消息丢失灾难性故障故障超出本标准的范围故障可能是灾难性的需要某种保护至少需要检测这要求提供脱机存档来保存提交和投递的全部消息在本标准中使用这种存档机制检测并恢复消息丢失是本地的应用中任何部件出故障也同样可能是灾难性的这同样可以脱机存档加以保护至于使用存档机制来存储消息检测并恢复消息丢失是本地的事情超出本标准的范围特定的消息丢失在消息存储中单个消息的丢失不管是有意无