验证电子消息的传递和内容的系统及方法

专利名称：验证电子消息的传递和内容的系统及方法
技术领域：
本发明一般地涉及验证电子消息的传递和内容的一种系统及方法，特别是涉及随后提供关于电子邮件的传递和内容的证据的一种系统及方法。更特别是，本发明涉及通过互联网发送已登记邮件、同时验证电子消息的传递和内容、随后提供关于已登记电子邮件的传递和内容的证据的一种系统及方法。
背景技术：
近些年来，电子邮件已经成为不可或缺的业务工具。电子邮件已经替代了用于许多业务的“传统邮递邮件”，因为电子邮件比“传统邮递邮件”更快、更便宜并且通常更可靠。但是，还是保留了硬拷贝仍然占主导地位的某些邮件应用，比如，挂号邮件和保证邮件。例如，当通过保证邮件发送信件时，给发送者提供一张收据以证明信件被邮寄。返回的挂号邮件添加邮局服务确认，证实该信件已经被成功地传递给收件人或者收件人授权的代理。此外，私人邮递公司，比如FedralExpress(联邦快递)和United Parcel Service(UPS，联合邮政服务)提供某种类型的传递确认。由于每一封邮递邮件实际上都要登记，因此当顾客想要传递证明时，自然会求助于这些服务。
许多现存的电子邮件系统和电子邮件程序已经提供了某种形式的传递证明。例如，目前有一些电子邮件系统允许发送者制作具有“请求通知”标签的消息。这种标签允许发送者请求关于消息被传递和/或消息被打开时的通知。当发送者请求传递通知时，互联网电子邮件系统向发送者提供电子邮件收据，说明消息被传送到邮件服务器或者收件人的电子邮箱。收据消息可以包括消息的名称、目的地地址、传送时间。该收据消息还可以包括(取决于发送邮件软件中设置和激活的“标记”的类型)所有互联网“站”的目录，消息经由这些互联网“站”到达目的地。这种报告格式被做成实现电子邮件的某些规则和协议的组成部分。此外，当“阅读通知”请求与消息一同发送时，收件人的电子邮件程序可以向发送者发送一个收件人打开该消息进行阅读的电子邮件通知。许多电子邮件客户机能够支持该类型的数据报告；但是，互联网协议没有把这种报告设成强制性的。
然而，这不意味着与通知请求一同发送的电子邮件像挂号邮件那样在所有方面都是有效的。人们证实和登记信件是因为想要传送信件的证据，即在民事或者刑事诉讼中可以使用的证据，或者使管理员或者客户或者政府机构相信消息已经发送、工作已经完成、命令已经发出、或者合同要求已经达到的证据。
来自美国邮政管理局(USPS)的登记收据构成传递的证据，因为USPS是它的后盾。收据代表邮政局的确认，证明所涉及的信件或包裹确实被传递给收件人或者收件人的授权代表。另一方面，对于电子邮件收据，要使它成为被承认的值得信赖的证据，也就是，使传送消息的证据成为法庭上有说服力的证据，还存在各种障碍。毕竟这种收据可能恰好是由任何人在任何时候更改或者创建的另一个电子邮件消息。
因此，需要一种可以提供电子邮件消息内容和传递的可靠证据的电子邮件系统和/或方法，以便更全面利用经由电子邮件通信的便利性和低成本的优点。
为了满足这种需要，已经建立了某些系统，发送者通过在服务中进行登记，可以接收第三方的传递证据，由此a)发送者向第三方发送电子消息和文件的预期收件人名单。
b)第三方向消息的每一个预期收件人发送一个通知，邀请他们访问能够查看该消息的第三方网站。
c)如果预期收件人访问第三方网站，查看该消息，则第三方记录该次访问，使发送者能够知道该消息已经被收件人阅读。
这种系统的缺点是多方面的。首先，这种系统基本上依赖于电子邮件的收件人的合作，以从第三方服务收集他的消息。但是，发送者想要消息传递的证据的情形经常是，不能假定预期收件人会在接收消息时予以合作。在这种情况下，例如，在消息的确认收据将给收件人带来财务或者法律麻烦的情况下，收件人可以完全不理睬‘他可以接收邮件’的通知。需要注意的是，在这样的系统中，不能保证预期收件人已经收到等候邮件的通知。第二，由于要求发送者和/或收件人连接环球网站以发送、收集和验证每个消息传递，与常规的电子邮件相比，这种系统不仅使用麻烦而且速度慢。此外，利用这种方法传送文件可能需要发送者和接收者双方将文件上载和下载到一个网站上。最后，由于这些方法需要第三方保留每个消息的全部拷贝，直至它们被收集或者(时间)到期，因此这些方法可能需要其供应者在扩展的一段时间内，将相当大的计算资源用于数据存储和数据跟踪。作为一种提供传递证据的替代方法，一些系统提供专有的电子邮件客户机或者网络浏览器插件，只要收件人也使用相同的电子邮件客户机，则在接收到一个消息时，所述电子邮件客户机或者网络浏览器将通知发送者。
因此，需要这样一种电子邮件系统/方法，该电子邮件系统/方法可以提供电子消息内容和传递的可靠证据，并且，不需要收件人的配合或者协作，不需要在发送者或者收件人部分加载特殊的电子邮件软件，而且操作具有与传统电子邮件相同的便利性和速度，以及服务供应者能够很经济地进行操作。

发明内容
本发明(在共同待审的非临时申请09/626,577中所公开和要求的，该申请的代理人案卷为RPOST-57228，由T.A.托姆科夫在2000年7月27日提交，并在该申请中签署了给受让人的转让记录)的一般目的是提供一种系统和方法，通过安全的和防窜改文件，可靠地验证诸如电子邮件这样的电子消息的内容和传递。理论上，在共同待审的申请09/626,577(代理人案卷为RPOST-57228)中所公开和要求的本发明将给予电子邮件和其它电子消息一个至少与挂号的美国邮件同等的法律地位。然而对本发明来说，由于不管本发明提供有用信息和验证，不需要把任何特定的法律地位给予依据在此教授的方法发送的消息。
在共同待审的非临时申请09/626,577中所公开和要求的本发明包括一个电子消息系统，它建立和记录经由该系统发送的每个电子消息的数字签名。始发者可以向该系统发送电子消息的拷贝，或者在该系统内产生电子消息。然后，该系统向所有收件人(或者，向与收件人相关联的指定消息管理人)转发和传送电子邮件消息，所述的收件人包括“to”收件人和“cc”收件人。此后，该系统把传送的收据回送给电子消息的始发者。其中，收据包括原始消息、消息的数字签名、握手和传送历史，包括传送给收件人的次数。为了日后验证和鉴定收据中含有的信息，始发者或者用户将收据的拷贝发送给该系统。然后，该系统验证数字签名是否与原始消息和收据的其余部分相匹配。如果这两者相匹配，则该系统发送一封验证电子消息没有改变的信件或者提供验证电子消息没有改变的其它真实性确认。
在共同待审的非临时申请09/626,577中所公开和要求的系统可以包括连接互联网的一种电子邮件服务器，该系统可以被应用在许多方面。例如，个人用户通过把一个“副本”发送给系统或者在系统内构成消息，可以注册他们的电子消息。公司和电子商务用户可以将它们的服务器换成结合本发明的服务器并且登记它们的所有外部电子消息，这些电子消息具有使系统保留和归档收据的选项。该系统可以接受和验证已加密的电子消息并且管理“防火墙”内和/或外的电子消息。对于基于环球网的用户，即使用基于环球网电子邮件(比如MSNHotmail或者Yahoo Mail)的个人或者公司，这些用户可以检查邮件箱或者把一个标志设置在它们的电子邮件程序内，以便以逐件处理为基础，选择是否使用在共同待审的非临时申请09/626,577中所公开和要求的本系统登记电子邮件和/或归档消息。
数字签名可以使用已知的数字签名技术来创建，比如可以通过对消息进行散列函数运算来产生消息摘要，然后对消息摘要加密。可以为消息正文、任何附件创建单独的数字签名，以及为包括正文、附件、各个消息摘要的整体消息创建单独的数字签名。已加密的消息摘要提供一种消息鉴别或者验证码，或者安全文件。也可以生成和使用其它的消息鉴别和/或验证码。
一个方面，在共同待审的非临时申请09/626,577中所公开和要求的本发明是一种提供有关电子消息的传送和内容的证据的方法，包括经由计算机网络从发送者接收一个电子消息，该消息具有与其关联的传送地址；根据该消息计算消息摘要，加密消息摘要；把该消息电子化地发送到与传送地址对应的目的地；记录实现消息传送的简单邮件传输协议(SMTP)或者扩展的SMTP(ESMTP)对话；接收与所述消息和传送地址相关联的传送状态通知信息；向发送者提供一个电子收据，所述收据包括消息的副本，已加密的消息摘要，(E)SMTP抄本，和至少一个传送状态通知信息的子集，并且在日后，电子接收来自发送者的电子收据，验证已加密的消息摘要对应于所述消息，验证所述消息被关联传送地址的电子消息处理器接收。
另一方面，在共同待审的非临时申请09/626,577中所公开和要求的本发明包含一种验证电子消息传送的方法，包括在广域网计算机系统中，接收来自消息发送者的消息，以路由发送到目的地地址；建立与关联目的地地址的电子消息服务器的通信，所述服务器定义一个目的地服务器；查询所述目的地服务器，以确定目的地服务器是否支持传送状态通知(DSN)功能；接收对所述查询的响应，所述查询和响应共同定义一个SMTP对话；根据SMTP对话的结果，请求来自目的地服务器的传送状态通知信息；把电子消息发送到目的地地址；接收来自目的地服务器的关于电子消息传送的DSN信息；向消息发送者提供至少一部分SMTP对话和至少一部分DSN信息。
又一方面，在共同待审的申请09/626,577中所公开和要求的本发明包含一种验证已接收电子消息内容的方法，包括接收电子消息；生成对应于已接收消息的内容的数字签名；向指定地址提供消息和数字签名；此后，验证数字签名对应于所述消息。
根据在共同待审的申请09/626,577中所公开和要求的本发明的又一方面，所述方法包含确立收件人是否电子接收到消息的步骤，包括提供待电子发送的消息以及来自发送者的收件人地址；创建与所述消息关联的签名；把所述消息电子地发送到收件人地址；跟踪所述消息，以确定发送到收件人地址的消息的最终传送状态；接收到所述消息的最终传送状态时，生成一个收据，所述收据包括消息的拷贝、签名、消息的最终传送状态；给发送人提供所述收据，以便日后确立所述消息被收件人电子接收。
根据在共同待审的申请09/626,577中所公开和要求的本发明的另一方面，提供一种证明发送给收件人的电子消息被阅读的方法，包括提供电子消息与收件人地址；计算对应于电子消息的数字签名；把电子消息发送到收件人地址；请求来自收件人的邮件用户代理(电子邮件客户“阅读”)通知；收到阅读通知时，生成一个阅读收据，该阅读收据包括来自收件人的消息拷贝、对应于电子消息的数字签名、所述阅读收据的第二个数字签名；提供阅读收据，用于以后验证收件人接收到所述消息。
根据在共同待审的申请09/626,577中所公开和要求的本发明的另一方面，提供了一种确认电子消息的有效拷贝(purported copy)的完整性的方法，包括接收有效电子消息拷贝，所述有效拷贝包括与其关联的加密消息摘要；解密消息摘要；根据有效拷贝的内容生成第二消息摘要；通过比较已解密的消息摘要和第二消息摘要以确定这两个消息摘要是否匹配，确认所述有效拷贝。
根据在共同待审的申请09/626,577中所公开和要求的本发明的又一方面，提供了一种确认已接收的登记电子邮件的方法，包括接收一个电子收据，所述收据包括基本消息和加密的消息摘要；解密已加密的消息摘要；从基本消息生成第二消息摘要；如果解密的消息摘要与第二消息摘要相匹配，则确认电子邮件。
在另一方面，在共同待审的申请09/626,577中所公开和要求的本发明包含一种用户可以发送和接收安全消息的网站，具有充当独立第三方的网站主机，该网站主机发送和接收消息并且提供关于消息的内容和传送的安全文件。
当本领域的技术人员阅读下面的优选实施例的详细说明和查看附图时，将会明白在共同待审的申请09/626,577中所公开和要求的本发明的上述目的和其它特点以及本发明的优点。在附图中，相同的标号指相同的部件和所附的权利要求。


下面参考附图详细说明本发明的优选实施例。
图1是在共同待审的申请09/626,577中所公开和要求的本发明的第一实施例的系统图，其中，输出消息是通过一个特定邮件传送代理(MTA)进行发送而登记的；图2A～2F构成了根据图1实施例登记输出电子邮件的代表性流程图；图3是在共同待审的申请09/626,577中所公开和要求的本发明的第二实施例的系统图，在其中发送者可以指引邮件传送代理经由一个单独的MTA发送已选择的消息，构造该单独的MTA是为了登记已选择的消息。
图4是在共同待审的申请09/626,577中所公开和要求的本发明的第三实施例的系统图，其中，将输出消息的副本(cc’s)发送给一个特殊服务器进行登记；图5是在共同待审的申请09/626,577中所公开和要求的本发明的第四实施例的系统图，其中，用户在一个指定网站构成要登记的输出消息；图6是在共同待审的申请09/626,577中所公开和要求的本发明的第五实施例的系统图，其中用户可以发送已登记的电子邮件，并且把由此而来的收据存储在基于环球网的邮件用户代理(MUA)中；图7是确认已登记的电子邮件收据的流程图；图8是用于登记输入消息的本发明一个实施例的系统图；图9是用于登记输入消息的流程图；图10是用于确认已接收的登记消息的流程图；图11是一个系统图，显示在共同待审的申请09/626,577中所公开和要求的本发明的示例使用，电子商务使用本发明登记和确认输入和输出通信。
图12是一个块图，显示在一个系统中登记邮件的方法的流程图，诸如在前面图中所示不同实施例的单个个体中所示的系统，并且显示从发送者到具有指令表示登记邮件的服务器的一个消息，如何提供从服务器到收件人的该消息的传送，消息传送是通过一个特殊路径，该特殊路径不同于从服务器到收件人的传送消息的通常路径；图13是一个块图，表示与图12中所示流程图相类似的一个流程图，但具有另外的块，以提供除了图12中流程图提供的功能以外的特殊功能；和图14是部分的形式图，其被发送者用于登记消息，该消息是由服务器发送到收件人。
具体实施例方式
本说明书没有限定性意义，而仅仅是用于解释本发明的一般原理。本详细说明的段落标题和整体组织仅仅为了便于解释的目的，而不是限制本发明。所以，本发明将对使用互联网网络体系结构和基本设施的电子邮件消息发送系统进行说明。应当理解的是，这里所述的特殊消息类型和网络体系结构仅仅是示例；本发明还可以应用于使用包括有线和无线网络的其它计算机网络体系结构的其它电子消息协议和消息类型。为了便于讨论，根据在共同待审的申请09/626,577中所公开和要求的本发明处理的消息可以被称为“已登记”消息。在下面的讨论中，术语“RPost”是指第三方实体的通用术语，它创建和/或操作实现本发明的软件和/或硬件，和/或充当一个公正的第三方消息验证器。根据本发明处理的消息被称为“已登记的”发明。所用术语仅为了方便示例的讨论，不能理解为限定本发明。
I.作为输出邮件服务器实施例的RPost图1是本发明的第一实施例的系统图，其中输出的电子邮件根据在共同待审的非临时申请09/626,577中所公开和要求的本发明进行登记。在该实施例中，RPost登记服务器14用作一个消息发送者的邮件用户代理(MUA)13的主要输出邮件传送代理(MTA)。尽管消息收件人18在技术上是收件人，因而仅仅在此时是预期收件人或者预期目的地，但是为了便于说明，该实体将被称为收件人、收信人或者目的地。需要注意的是，单个消息可以有许多不同的目的地，并且可以经由不同的MTA到达这些目的地中的每一个。发送已登记消息的方法可以被划分成三个部分1)预处理在发送消息前采取的步骤；2)传送传递消息给收信人的方法；3)后处理收集消息传送后的关于该消息的信息，建立收据，和确认收据的处理过程。
I.1预处理收到要传送的消息时，RPost服务器将为每个消息在数据库中建立记录，该数据库将存储这样的信息a)接收消息的时间；b)消息附件的名称；c)消息地址的数目；对于消息的每个目的地，该数据库将记录目的地的名称(如果可得到)；b)目的地的互联网地址；c)消息被传送到目的地邮件服务器的时间；d)该目的地的传送状态。
该系统使用的收件人传送状态将包括UNSENT该状态指示还没有发送消息。
DELIVERED-AND-WAITING-FOR-DSN该状态指示已经把消息传送给ESMTP适应的MTA，该MTA支持传送状态通知(DSN)，所以可以预计成功/失败通知。
DELIVERED该状态表示发送给这个收件人的消息的拷贝已经被成功地传送给不支持ESMTP DSN的一个服务器。
DELIVERED-TO-MAILBOX该状态表示已经接收到DSN消息，所述DSN消息指示发送给这个收件人的消息的拷贝被传送给该收件人的邮件箱。
RELAYED该状态表示已经收到MTA DSN，它指示发送给这个收件人的消息的拷贝已经被向前转送到另一个服务器。
UNDELIVERABLE该状态指示在重复尝试之后，RPost已经不能连接MTA，以把消息传递给这个收件人。
FAILED该状态表示已经接收到MTA DSN，它指示不能将消息的拷贝传送给这个收件人。
此时，该系统将还对消息内容执行散列法函数运算。
PRost服务器14利用散列函数和加密算法。该散列函数可以是已知的任何一种散列函数，包括MD2、MD5、安全散列算法(SHA)，或者将来可能开发出来的其他散列函数。散列算法和方法被公开在下列文件中Bruce Schneider，Applied CryptographyProtocols，Algorithms，and Source Code in C，John Wiley & Sons，Inc.(New York)1993；FederalInformation Processing Standard Publication 180-1(FIPS PUB180-1)Secure Hash Standard，National Institute of Standards andTechnology；and U.S.Pat.No.5,530,757 issued to Krawczyk，entitled“Distributed Fingerprints for Information Integrity Verification”，这里作为散列函数、加密和实现这些函数的方法和系统的教学参考引出。也可以使用检测消息内容是否已经被改变的其他已知的或者新的方法。
好的散列函数H是单向的；也就是说它是难于逆向的，其中“难于逆向”是指给出一个散列值h，它不可能通过计算发现某个输入x，使H(x)＝h。此外，散列函数至少应当是弱无冲突的，这意味着，给定一个消息x，不能通过计算发现某个输入，使H(x)＝H(y)。其结果是了解所使用的算法和得到的散列值或者消息摘要的伪造者不能建立会散列成同一个数的伪造消息。散列函数返回的散列值h通常被称为消息摘要。消息摘要有时被称为消息x的“数字指纹”。目前，建议单向散列函数产生至少128比特长的输出，以确保结果是安全的而且是不可伪造的。随着最新技术状态的进步，安全散列函数的推荐长度也许会增加。
RPost服务器14计算消息正文的消息摘要和消息的每个附件的独立消息摘要，并以这样一种方式存储它们它们以后可能被包含在该消息的收据内。
在以要求注册的方式改变消息之前，存储原始消息及其附件的拷贝，使系统随后可以恢复它们。
RPost服务器14在将消息发送给收件人的MTA之前，可以以几种方式改变该消息。
尽管给消息加标签对本发明的实践不是必需的，但是，标签指出消息已经被登记的事实，对消息加标签可以这样实现，比如在消息的“主题”行的开头插入“已登记”，在原始消息的结尾添加一个标签，比如“这个消息已经被RPost登记。关于附加信息，访问我们的网站，www.RPost.com。”或者添加其他标签。此外，该标签可以包含指令、环球网地址、或者链接，该链接通过链接到可以构成和发送已登记消息的网页邀请并允许收件人来给消息发送一个已登记的答复。
尽管加标签是任选的，但是通常将已传递的消息称为加标签消息。
互联网协议提供两种用于电子邮件的收据格式MTA NOTIFICATIONS这些是收件人的MTA发送的电子邮件，它通知消息的名义发送者各种事件已经发生。符合SMTP协议的MTA通常只在邮寄者不能把消息传递给收信人的邮箱的情况下(如果地址无效或者收信人的邮箱已经超过分配的存储配额，则可能发生这种情况)发送通知。
由于引入了扩展的SMTP标准，因此发送MTA有可能请求消息传递的成功和失败通知。这些传递状态通知(DSN)是当某些事件发生时，由一个接收MTA发送给消息的名义发送者的电子邮件，所述的某些事件例如是消息已经被成功放置到收件人的邮箱中；由于某种原因，消息不能传递到收件人的邮箱；收件人的消息已经被转送到不能给出DSN收据的另一个服务器上。
需要注意的是，只有支持扩展的SMTP(ESMTP)协议的电子邮件服务器支持DSN的这种格式，而且支持该功能对ESMTP服务器来说是可选的，并且依赖于服务器管理员选择的配置。
尽管DSN是一个随着ESMTP的出现才开始使用的术语，但是在下文中，我们将使用‘DSN’指代任何MTA生成的消息，这些消息与已接收消息的状态有关，而不管它们是否符合ESMTP协议。
MUA NOTICES(READING NOTIFICATIONS)这些是当某些事件发生时，由收件人的邮件用户代理(MUA)(电子邮件程序)发送给消息的(名义)作者的电子邮件。所述的某些事件例如是打开消息进行阅读，或者从系统中删除消息而不阅读。按照互联网协议(RFC 1891)，不能强迫MUA程序生成这样的通知。MUA是否将生成这些收据将依赖于它的用户选择的配置。
RPost服务器14将以试图从顺从的MTA和MUA中引出MTA DSN和MUA通知的方式配置和发送消息。为了从顺从的MUA中得到阅读收据，某些报头应该被包含在电子邮件消息的报头部分中。不同的MUA响应不同的报头；因此，服务器14以被各种MUA识别的格式将若干不同报头添加到请求阅读通知的每个消息上。这些报头采用以下格式报头标记用户名(用户地址)例如Dispoition-notification-to(设置-通知-至)john smith<jsmith@adomain.com>
read-notification-to(阅读-通知-至)johnsmith<jsmith@adomain.com>
其中，‘john smith’是接收MUA通知的用户的姓名，‘<jsmith@adomain.com>’是用户的互联网地址。通常，这种报头应当涉及消息的作者，但是在本方法中，要求把该通知返回到RPost，使RPost能够处理该通知。为了确保实现上述目的，服务器14将插入报头，请求把MUA收据发送到可以由RPost处理的地址，例如readreceipt@RPost.com。这将指示任何顺从的收件人MUA把它们的通知发送给一个RPost地址，用于处理。
处理返回的MUA通知的任务引发了另一个问题，必须在该阶段进行处理。没有管理MUA通知的格式或者内容的标准。它们通常将提供原始消息的主题和它们正在报告的事件(例如，“打开阅读”)的时间。但是，即使这个信息被包含在该通知中，也不足以唯一地识别提示它的消息或者识别该消息的作者。当系统接收到一个MUA通知时，该系统能够识别提示它的消息，以便把通知信息包含在RPost将为发送者生成的收据中。作为选择，该系统应该至少能够可靠地识别MUA通知涉及的消息的发送者，使通知信息可以以RPost阅读收据的形式被传送给发送者(参见下文)。
为了实现后一个目的，系统可以利用互联网地址具有两个分量的事实。这两个分量是一个姓名字段和一个地址字段，其中地址字段由角形引用号“<>”分开。大多数MUA将把这两个字段包含在它们的MUA通知的目的地地址中。在构成其MUA收据的请求时，RPost系统将包括服务器14，阅读收据处理地址作为通知的地址，但是将使用报头姓名字段中的原始发送者的地址。例如，当消息的原始发送者是互联网地址为jsmith@adomain.com的用户John Smith时，RPost服务器将包含以下形式的报头设置-通知-至jsmith@adomain.com readreceipts@RPost.com这通常将导致顺从的MUA向readreceipts@RPost.com发送一个通知，编址如下所示jsmith@adomain.com<readreceipts@RPost.com>
当在地址“readreceipts@RPost.com”收到这样一个通知时，服务器通过分析地址字段，可以确定该通知涉及一个由jsmith@adomain.com原始发送的消息，即使不能通过检查该通知的内容来确定这一点。有了这个信息，服务器随后可以将通知的内容封装在一个有数字签名的RPost阅读收据中，并且把该收据发送到地址jsmith@adomain.com。
RPost系统还将努力得到和收集由收件人MTA生成的MTA DSN通知。由于这种通知总是被发送给消息报头的“FROM”字段中列出的地址，因此服务器14必须改变每个消息报头，以便使接收的消息好像来自(“FROM”)可能处理DSN的RProst地址。
然而，处理DSN的问题引发了该阶段必须处理的另一个问题。DSN没有任何标准内容和格式；通常不能仅仅通过检查这些电子邮件的内容来确定电子邮件的内容正在给出什么消息的通知。对于依据ESMTP协议生成的DSN，该问题应该已经通过使用DSN封装ID编号予以解决(参见RFC1869)。根据该协议，一个发送的MTA可以包括其对DSN的请求和一个基准编号。该编号被引用在任何返回的DSN中，允许发送者识别DSN的主题消息。然而，事实上，许多报告它们自己支持ESMTP DSN的MTA不返回足以可靠地识别主题消息的DSN封装ID或者任何其它信息。最后，即使DSN返回足以可靠地识别正在发出通知的消息的信息，但它通常将不包含足够的信息来识别已经提示通知的消息的特定收件人。因而，单个消息可能被发送给一个域的两个收件人；一个可以被成功地传送到收件人的邮箱；另一个则不能。用于该域的MTA可以在DSN中报告这些事件，其报告方式没有为DSN的收件人提供方法来确定成功地传送给哪一个收件人(例如，如果DSN报告收件人的地址为本地别名，而不是原始消息中包含的地址时，则可能发生这种情况)。
本发明通过四个步骤解决该问题1)为每个输出消息生成唯一的标识编号(例如，基于时间标记)。该编号被存储在一个数据库中。
2)列举每个消息的收件人，并且把识别的编号存储在一个数据库中。
3)把消息分别分送到每个预期收件人的MTA。(即使两个收件人具有共同域名和MTA，服务器14还是将在两个单独的SMTP远程网会话中把该消息发送给MTA。)4)当服务器14发送消息到收件人的MTA时，它将增加该消息的“FROM”字段，以显示该消息已经从并入了消息的唯一ID和发送者的识别编号的地址发送了。该地址还包括能够使服务器把返回消息识别为DSN的子串(例如，“rcpt”)。
这样，来自名为John Smith的发送者的，由服务器14命名为“mmyyddss”的单一消息可以借助一个报头被发送给它的第一个预期收件人(由系统命名为“a”)FromJohn Smith<rcptmmddyyssa@RPost.com>
同样的消息将借助以下报头被发送给第二收件人FromJohn Smith<rcptmmddyyssb@RPost.com>
许多电子邮件的MUA将仅仅显示消息的发送者的姓名，因此大多数收件人将看不见具体的地址。
这种编址方式的结果是，当收件人MTA发出DSN(无论ESMTP顺从或者不顺从)时，它们将这些DSN发送到不同的RPost收件人。当收到这些DSN时，服务器14通过他们的“RCPT”前缀把它们识别为DSN消息，并且通过分析收件人，可以确定哪个消息和哪个收件人是DSN的对象。
当系统14每次试图发送消息给收件人的MTA时，它将把每个消息的‘FROM’字段改为消息的收件人。
为了确保正确引导收件人对所发送消息的答复，服务器14将一个明确的“答复(reply-to)”消息报头添加到列出原始发送者姓名和互联网地址的消息中。在本实例中，这将是Reply-tojohn smith<jsmith@adomain.com>
这将引导收件人MUA把对已接收消息的答复发送到实际发送者的地址，而不是发送到所构造的RPost地址。
I.2发送如上所述，它是RPost服务器向消息的每个收件人发送该输出消息的分离拷贝的方法的一部分。此外，RPost试图使每个这样的传递经由一个与记录每个目的地的邮件交换器(MX)的直接SMTP连接。
注意每个有效互联网电子邮件地址包括一个互联网域名或者IP地址。每个域名/地址与授权为该域中的收件人接收邮件的电子邮件服务器相关联。需要注意的是，某些域具有一个以上的服务器。负责每个域的域名服务器经由互联网广播它的邮件服务器的身份。该信息是公开的，但必须遵守管理互联网电子邮件和域名服务的规则和协定来管理和传送它。
在传送消息拷贝给任何目的地之前，RPost服务器14将执行互联网名称服务器查找，以识别与目的地的域关联的一个MTA。在识别了负责代表目的地地址接收邮件的MTA后，系统将试图打开远程登录，连接目的地的本地MTA。
通常的做法是，互联网电子邮件从MTA转送到MTA，直至它们到达它们的最终目的地。提供RPost服务器14与目的地MTA之间一个直接连接的主要目的是使RPost服务器可以记录消息的传递，(该记录采取SMTP对话的形式)，且电子邮件服务器专门负责接收给收件人域名的电子邮件。
该记录的存在提供了消息被传递的有用证明，与挂号邮件收据提供传递证明大体相同。USPS挂号邮件被视为可验证传递了的邮件，如果能证明它已经被传递到收件人授权的代理(例如，秘书或者邮件室的职员)。如果对RPost传递收据的证据价值提出合法性置疑，则将认识到在选择互联网电子邮件服务提供者时，收件人已经授权该提供者代表他收集电子消息。反过来，服务提供者通过广播它的MTA地址作为该域的接收电子邮件服务器，确认其作为该域名的电子邮件收件人的授权代理的地位。
所以，将消息直接传递到负责接收收件人的电子邮件的邮件服务器后，RPost已经将消息传递给收件人已经合法授权接收他的邮件的代理。通过记录传递事务(该事务采用SMTP对话的形式)，RPost可以声称具有传递到收件人已授权代理的证据。
需要注意的是，尽管这里所述的方法试图收集传递到每个目的地的其它形式的证据，但是这些尝试是否成功将依赖于RPost无法控制的因素，(例如，在收件人的邮件服务器上配置的SMTP支持的形式)。另一方面，每个直达收件人的邮件服务器的成功传递将总是生成SMTP记录，对该记录进行记录允许RPost提供传递到任何有效的互联网目的地的证据，该有效互联网目的地遵守互联网邮件的最低协议(SMTP)。这表示本方法与也许试图通过依赖ESMTP DSN来证明传递的其它方法相比，具有重要优点。
在识别用于消息目的地的MTA后，RPost服务器14将通过发出服从RFC 1869的“EHLO”握手来试图打开与目的地MTA的ESMTP连接。如果服务器16支持ESMTP，则它将通过列出它支持哪些ESMTP服务来进行响应。
如果服务器16支持ESMTP，则RPost服务器将首先确定服务器16是否支持ESMTP服务“VERIFY”。该验证服务允许一个呼叫SMTP服务器来确定MTA域中的地址是否是真的。如果RPost服务器通过这些方法确定它正在试图向其传送消息的地址是无效的，则它将终止连接，停止将消息传递给该收件人，并且在它的数据库中把该消息目的地的状态记录为UNDELIVERABLE(无法传递)。
无论结果如何，Rpost服务器14都将在一个文件中记录ESMTPVERIFY对话并存储它，以便以后可以把该对话加入或者包含在该消息的传递收据中。应当注意的是，出于安全考虑，仅少数ESMTP服务器支持VERIFY功能。
如果系统16不支持VERIFY方法，那么RPost服务器14将仍然试图把消息传递到系统16。MTA通常将接受给它的域中空有其名的任何地址的消息，并且，如果该地址是无效的，则随后发送一个DSN。
RPost服务器14然后将试图确定目的地服务器是否支持ESMTP服务DSN。如果是，则RPost将发送带有一个请求的消息，请求服务器16通知带有ESMTP DSN的消息的发送者，无论到收件人的传递是成功还是失败。当消息成功传递到该目的地之后，该系统将把该目的地的传递状态记录为DELIVERED-WAITING-FOR-DSN.
如果服务器16答复“EHLO”握手，在某种意义上指示它不支持ESMTP，则RPost服务器14将发出“HELO”消息，以启动SMTP连接。如果实现了该连接，则Rpost服务器14将发送服从SMTP协议的消息，并且把目的地的传递状态记录为DELIVERED。
无论该连接是SMTP还是ESMTP，RPost服务器14将记录这两个服务器之间的整个协议对话。该对话通常将包括协议消息，其中，目的地服务器进行自我识别，授权上载给指定收件人的消息，并确认该消息被接收。RPost将保存这次事务的记录，这样，以后可以检索该记录，并且把该记录包含在或者加入到该消息的RPost传递收据中。
由于各种原因，Rpost可能不能实现与收件人的MTA的SMTP连接，或者它也许实现了这样一种连接，但是不允许收件人发送该消息。在这种情况下，如果互联网DSN查找揭示目的地地址由多个MTA服务，则RPost服务器14将试图把它的消息依次传递给每个MTA。每当系统资源许可时，RPost将连续尝试到适当MTA的传递。如果，在一段时间之后，RPost不能传递消息到一个地址，它将把该消息的收件人的状态标示成“UNDELIVERABLE”，并且停止发送该消息到该目的地地址的尝试。
当RPost服务器14成功发送一个消息给明确支持ESMTP DSN的目的地服务器时，RPost将把该消息的这个收件人的状态记录为“DELIVERED-AND-WAITING-FOR-DSN”。
当RPost服务器14经由一个不明确支持ESMTP DSN的连接成功发送一个消息给目的地服务器时，RPost将把该消息的这个收件人的状态记录为“DELIVERED”。
I.3.后处理DSN处理
MTA DSN将被返回到编址为其专有域中的虚拟地址的RPost服务器14(例如，“RPost.com”)，这个地址按照上述说明构成。RPost服务器将扫描对该域寻址的所有入站邮件，并且通过识别子串(例如，“rcpt”)检测DSN消息。通过按上述方式分析这些地址，系统可以识别消息和已经提示DSN通知的收件人。
没有用于DSN消息的标准格式；也没有报告它们的结果的任何标准词典。为了估计已接收的DSN，该系统必须在DSN消息的主题行和正文中查找表达DSN含义的字和短语。例如，诸如“成功传递”或者“传递到邮箱”或者“被传递”这样的短语通常表示DSN关注的消息被放置到目的地的邮箱中。当检测到这样的短语时，该系统将把该消息的这个目的地的传递状态改为“DELIVERED TO MAILBOX”。
诸如“不能传递”、“致命错误”、“失败”和“不成功”这样的短语通常表示一个报告MTA传递消息到目的地失败的DSN。当它检测到DSN中的这些短语时，该系统将把收件人的传递状态的记录改成“FAILED”。
尽管该系统总是传递邮件到目的地域的专有MTA，但是这些MTA将在有些时候把消息转送到不同服务器(例如，如果接收的MTA在防火墙后发送邮件，则可能出现该情况)。在这种情况下，DSN将包含诸如“转送”或者“向前转送”的短语。在这种情况下，该系统将收件人的传递状态改成“RELAYED”。
因此，当估计DSN和更新收件人的传递状态后，该系统将保存DSN和它包含的任何附件，以使该消息可以被包含在和/或加入到RPost传递收据中。
消息管理有时，该系统会扫描每个已发送的消息和检查该消息的每个目的地的状态，以便确定该系统是否已经完成目的地的传递的处理。完成的标准依赖于以下的目的地传递状态DELIVERED该状态指示给这个收件人的消息拷贝已经被传递到不支持ESMTP DSN的一个MTA。这样的MTA在消息不可能被传送到收件人的邮箱的情况下，也许仍然发送一种形式的传递状态通知(例如，如果目的地地址与该域中的有效帐户不符，则可能发生发生这种情况)。所以，直至经过给收件人MTA传递之后的一段时间，该系统才把对这样一个收件人的传递视为完成。该时段(通常是二至二十四小时)代表大多数服务器返回传递失败的通知所需的估计最长时间。如果特定目的地的域遥远或者得知可立即产生或者延迟产生这样的通知，则可以调整上述时段。
RELAYED该状态表示已经收到一个DSN，该DSN指示收件人MTA已经把消息传送到不支持ESMTP DSN的另一个MTA。在这种情况下，已经传递消息的MTA仍然可能在适当的时候发送一个传递失败的通知。所以，处在与DELIVERED状态的收件人相同的条件下，具有这种状态的收件人被视为完成。
DELIVERED-AND-WAITING-FOR-DSN该状态表示收件人的MTA支持ESMTP DSN以及已经请求一个DSN，但是还未接收到。有时可能发生这样的情况尽管一个MTA把自己识别为支持该服务，但是，即便传递成功它也不提供DSN。因此，在一个时间段之后，即使没有收到DSN，系统也把带有该状态的、到目的地的传递看作完成。该时间段(通常是六至二十四小时)代表一个顺从的MTA返回一个DSN通常需要的最长时间的估值。
DELIVERED-TO-MAILBOX该状态表示已经为这个收件人接收了一个指示成功传递的DSN，因此完成了给该目的地的消息传递。
FAILED，UNDELIVERABLE对带有这种状态的收件人的传递总是视为完成。
当系统认为到一个消息的所有收件人的传递已经完成时，该系统将为该消息构造传递收据。
传递收据的建立传递收据是发送给已登记消息的原始发送者的电子邮件。收据20可以包含1.一个用于管理目的的标识符。该标识符可以是或者可以包括对发送者的ID的参考和/或该系统接收的发送者的消息的互联网消息ID的值；2.生成收据的日期和时间；
3.原始消息的引用正文和预期收件人的电子邮件地址；4.RPost服务器收到该消息的日期和时间；5.每个目的地的列表；(i)收件人的MTA收到消息的时间和/或系统收到来自收件人的MTA的DSN报告的时间；(ii)给该目的地的消息的传递状态。在传递收据中提供的传递状态基于目的地传递状态的系统内部记录。它们可以按以下方式记录●到状态为FAILED或者UNDELIVERABLE的目的地的传递将在收据中被记录为“失败”。
●到状态为DELIVERED或者DELIVERED-AND-WAITING-FOR DSN的目的地的传递将在收据中被记录为“传递到邮件服务器”。
●到状态为DELIVERED-TO-MAILBOX的目的地的传递将在收据中被记录为“传递到邮件箱”。
这些报告的目的是准确地通知传递的验证形式的阅读者，系统已经能够实现。
6.电子邮件的原始附件的列表和这些附件的单独的消息摘要；7.原始消息的附件的拷贝，每个原始附件作为一个附件被附加到收据上；8.包含在传递到每个目的地的消息中的所有SMTP对话的副本、概要或者副本提要；9.来自所有接收的DSN报告的正文和附件的引证，包括传递的细节或者它们可以揭示的消息的配置；和10.被作为DSN报告的附件返回到系统的任何文件。
收据的所有这些独立的要素可以具有它们自己的包含在收据内的消息摘要或者数字签名。此外，收据可以包括单一的整体加密的消息摘要或者作为收据的一部分计算和添加的数字签名，从而提供了单一的消息鉴别码，该鉴别码可以用来验证包含在收据内的所有信息。由于收据本身和SMTP对话以及收据内的DSN报告包含时间标记，因此收据包括消息收件人、消息内容及传递的时间和路径的真实记录。
MUA通知处理MUA通知可以按照与MTA DSN相同的方式来收集并且并入RPost传递收据内。然而，MTA通知通常在传递的几个小时内由接收的MTA发出，但将不生成MUA通知，如果生成MTA通知，则直到收件人打开他的MUA电子邮件客户程序并对收到的邮件进行某个操作才生成该通知。为此，在本发明的这个实施例中，从诸多MTA通知中分别收集MUA通知，并且在“RPost阅读收据”中报告它们，与RPost传递收据相分离。
由上述方式构成的消息报头引出的MUA通知将被返回到一个公共RPost地址(例如，“readreceipts@RPost.com”)，并且每个通知在它的地址的名称字段中包含该消息的原始发送者的地址。由于这是以下述方式生成RPost阅读收据所需的唯一信息，因此，系统可以处理MUA通知，不论这些通知何时到达，并且不需要把原始消息的任何信息存储在它的数据库中。
MUA通知可能报告，尤其是，收件人已经阅读的消息、收件人终端上已经显示的消息(不论是否阅读)、已经删除但没有打开的消息。这里没有用于MUA消息的内容或者格式的协议管理标准。可以配置该系统，以便以系统应用于MTADSN的相同方式检查MUA的正文来解释它们的报告。然而，在本发明的当前实施例中，RPost服务器14不估计或者解释MUA，而是传递给发送者，让他自己以RPost可以验证的一种形式进行估计。为此，系统将建立“RPost阅读通知”风格的电子邮件消息，包括以下各项1.已接收的MUA通知的主题行；2.作为阅读通知的正文提供的已接收的MUA通知的正文；3.作为附件包含的已接收的MUA通知；4.作为附件包含的已接收的MUA通知的任何附件；5.已接收的MUA通知的消息摘要以及该通知的任何附件；6.日期和时间标记；7.至少上述项目5和6的加密散列，提供一个用于文件和其内容的可验证的日期标记的数字签名。
收据设置在本发明的当前实施例的情况下，RPost传递收据和阅读通知都被发送给已登记消息的原始发送者。由于这些收据用一个加密散列被数字签名了，因此这些消息中包含的信息在任何时候为验证的目的被给予RProst时，RPost可以按照以下描述的方式验证它们。这意味着，一旦RPost把收据的拷贝传递给它的发送者(带有给发送者的指令，以保留他的记录的收据)，RPost就不再需要保留涉及该消息或者其传递的任何数据，并且可以从系统中擦除所有这种记录。因此Rpost不需要保留原始消息和收据的拷贝。这种数据存储器的节约使本发明具有超过现有各种消息验证系统的优势，现有的消息验证系统需要服务提供者有大容量数据存储。
在此情况下，保留收据数据的负担落到消息的原始发送者那里。作为选择或者补充，第三方验证器RPost可以(多半因为一个附加费)存储收据的永久拷贝或者某些或所有收据数据的永久拷贝。收据或者部分收据可以被保存在任何合适的数据存储器中，所述的数据存储器包括磁带、CD ROM、或者其它类型的存储装置。作为补充或者选择，在发送者或者发送者的机构的控制下，RPost可以把数据或者部分数据返回到专用于此目的的一个存储系统。
如上所述，RPost收据信息包括来自原始发送者的消息及它的附件的所有数据。存在这样的情形系统的用户也许不希望把收据保留在他们的记录中(例如，担心意外的数据丢失)，也不希望让RPost第三方控制他们的消息的内容。所以，RPost可以丢弃消息的内容，但是在其数据库中仅仅存储这样的信息，诸如可能由RPost提供的信息，当由发送者保留的消息拷贝展现时，以鉴别和验证消息的传递的信息(例如，发送者、组成消息的日期、消息摘要、目的地和传递状态)。
验证在发送、传递和/或阅读电子邮件以后，如果消息的始发者需要这些证据，该始发者将消息的收据呈现给系统的操作者。
例如，为了证明一个特定消息从发送者10发送到收件人18，发送者10发送给RPost一个带有请求的收据20的拷贝，请求验证该收据里包含的信息。这可以通过把收据发送给RPost上的预定邮箱(例如，verify@RPost.com)来实现。RPost随后确定该收据是否为一个有效收据。如果数字签名匹配收据的余项以及消息摘要匹配原始消息的对应的各部分，则该收据是有效收据。具体说，RPost对消息的各部分进行散列函数运算，包括消息正文、附件和包含SMTP对话和DSN报告的整体消息，以产生对应于所声称的消息拷贝的一个或多个消息摘要。RPost将包括整体消息摘要的所声称的拷贝中的消息摘要与RPost从所声称的消息拷贝中算出的消息摘要进行比较。通过解密作为所声称的收据的数字签名接收的整体消息摘要，或者通过加密从所声称的消息拷贝中算出的整体消息摘要，可以比较整体消息摘要。如果包括数字签名的消息摘要匹配，则该收据是由RPost生成的真实收据。假定使用好的散列函数以及加密散列函数所使用的密钥和数字签名加密算法没有被泄露，则几乎不可能由出示该收据的人伪造该收据。也就是说，收据一定是由RPost生成的收据，因此收据中包含的消息、送出/到达信息、传递的日期和时间、成功传递的事实、消息传送的路径、收据内包含的DSN信息必定是该信息的真实拷贝并且是准确的。RPost随后可以提供收据内包含的信息的验证、鉴别和确认。该确认可以采取电子邮件确认、来自熟悉RPost所使用方法的RPost职员的证词、书面和法庭的现场宣誓证词的形式，和其它证词的形式。RPost可以从发送者10、收件人18或者其它实体收取各种相应确认服务的费用。RPost还可以提供关于所声称收据的非真实性的证词或者确认。可以根据证据的联邦法规901(9)、901(10)、803(6)、893(7)、1001-1004、1006、702-706和对应的证据的州法规和其它可应用法规来提供证词。
总之，该系统根据公正的第三方的证词，提供可靠的证据，证明发送了具有特定内容的一个特定消息、何时发送、谁发送、谁接收、何时打开阅读、何时删除。可以在出现关于消息的内容和传递的争论的任何时候提供该证据，例如当合同形成时、股票买进或者卖出时以及许多其它应用。该系统的操作者可以证明收据中包含的信息的准确性，而不需要操作者保存收据中包含的信息的任何记录或者拷贝。
该系统的一个显著优点是，它可以由现有的MUA使用，而不需对其进行任何改变。由于计算、加密、ESMTP询问和对话、DSN报告收集和收据编辑都由第三方RPost服务器14执行，因此这些功能都不需要在任何用户的设备中实现。因此，用户可以快速和容易地利用该系统的优点。
在上述的本发明的实施例中，RPost服务器14登记经过它的所有消息的传递。作为选择，RPost服务器14可以仅仅登记那些具有某些目的地的消息(例如，一个机构的外部)或者来自某些发送者的那些消息(例如，一个顾客相关组)。作为选择或者补充，RPost服务器14可以只登记那些在消息主题或正文中具有有区别的字符或者字串的消息。例如，服务器可以只登记发送者已经把“(MR)”放入消息主题中的消息。所有其它消息可以由RPost服务器14或者由起普通互联网MTA作用的某些其它服务器传递。
在本实施例中，RPost可以以各种方式增加收入。例如，RPost可以向消息发送者10或者其机构收取费用，该费用可以以每条消息为基础、以每千字节为基础、以固定费用周期为基础(如每月)、或者以上述组合为基础。RPost还可以收取用于验证和鉴别收据的费用，收费表依赖于所寻求的验证是否为简单的返回电子邮件、书面誓词或者声明、书面或者法庭的宣誓事实证词、法庭的宣誓专家证词。如果用户选择使RPost保留收据的拷贝，则RPost可以按每条项目和/或每月每千字节收取存储费用。
II.登记输出消息的流程2A～图2G构成了一个显示本系统第一实施例的示例操作的流程图。修改该流程图以应用其它实施例是熟悉软件和电子邮件协议的的技术人员的技能。
图3A，预处理，示出了在登记服务器(本系统)发送消息之前，处理该消息的步骤。
为了登记一个电子邮件消息，在步骤201中，始发者/发送者/用户使用任何一个互联网邮件用户代理(MUA)建立电子邮件消息。可能的MUA包括(1)客户端电子邮件程序；(2)基于服务器的电子邮件程序；(3)基于web的电子邮件服务；和(4)经由网页提交的HTML表格。消息可以包含请求注解(RFC)822、2046和2047中描述的附加文件，这里作为参考引用。RFC是关于互联网的一系列注释，论述了计算机通信的许多方面，主要是网络协议、处理过程、程序和概念。
在本实施例中，系统起到发送者的输出邮件服务器的作用，因此发送者的消息将由发送者的MUA直接发送到RPost服务器(步骤202)。
在步骤203，系统建立待存储的原始消息的拷贝，用于以后处理。
在步骤204，系统在数据库中建立记录，可以包括如下的信息服务器接收消息的时间，消息的文件附件的名称和大小，消息的每个目的地的名称(如果已知)；每个目的地的互联网地址；消息被传递到目的地MTA的时间(该值最初为零)以及记录每个目的地的传递状态的单位。
在步骤205，每个目的地的传递状态被设置为“未发送(UNSENT)”。
在步骤206，系统生成和存储一个从消息正文生成的消息摘要或者数字指纹。
在步骤207，系统为包含在消息中的每个附件生成和存储一个散列或者数字摘要。
在步骤208，系统可以建立一个原始消息的已修改拷贝。在该第二拷贝中(步骤209)，可以修改该消息的原始主题行，以指示该消息被登记(例如，通过在前面加上“已登记”)。
在步骤210，可以把系统已登记消息的一个通知以及到该系统的环球网站的链接添加到消息的正文上。
在步骤211中，可以添加请求阅读通知的电子邮件报头，所使用的格式可以是由不同MUA识别的各种报头格式。通知的请求指导返回通知送到一个与系统关联的地址例如，readreceipt@RPost.com。这些报头还将包含地址名称字段中的消息的原始发送者的地址，MUA通知应当被发送到这个地址。
完成预处理后，系统将消息的拷贝发送到如图2B所示的消息的每个目的地。
图2B图示说明了发送一个已登记消息的步骤。如步骤220所示，这个处理需要为消息的每个收件人分别发送。
在步骤221中，系统改变它的正在工作的消息拷贝的报头字段，以把消息显示为“来自(FROM)”一个发送者，该发送者的名称是该消息的原始发送者，但是其地址是“RPost.com”地址，该地址根据以下各项构成a)用于识别返回MTA通知的字串(如“RCPT”)；b)唯一识别要发送的消息的字串；c)唯一识别该消息拷贝的发送目的地的标记。
在步骤222中，通过使用当前正在发送的消息的目的地的域名，系统进行域名服务器邮件交换查找，以发现负责收集该域中地址的邮件的MTA的地址。
在步骤223，系统试图将远程网直接连接到目的地的MTA。如果连接失败，则系统将试着再次连接。只要系统没有超过用于该目的地的最多重试次数(227)，则系统将可能使用该目的地域的另一个MX服务器试着重连接(228)。
如果，在重试最多次数之后，系统还不能连接到该目的地的MTA，则系统将(如步骤226)把该目的地的传递状态记录为“无法传递(UNDELIVERABLE)”并停止将消息传递到该目的地的尝试。
一旦连接到目的地的MTA，系统就开始记录它与MTA的(E)SMTP对话(225)。
在步骤229，系统试图通过发出一个“EHLO”问候，启动与目的地MTA的扩展SMTP(ESMTP)交换。
如果目的地的MTS支持ESMTP，则系统将(230)确定该目的地MTA是否支持SMTP功能VERIFY。如果MTA支持VERIFY，则系统将试图确定目的地地址是否为该域内的有效地址(231)。
如果地址无效，那么如在步骤232那样，系统将把该目的地的传递状态记录为“失败(FAILURE)”，并且将停止把消息传递到该目的地的尝试。
如果地址有效，或者如果ESMTP服务器不支持VERIFY，则系统将(233)确定接收的MTA是否支持ESMTP服务DSN(传递状态通知)。
如果MTA不支持ESMTP DSN，则系统将发送带有ESMTP请求的消息，以通知该消息的名义发送者传递成功或者失败(234)。发送消息后，系统将把该目的地的传递状态记录为“DELIVERED-AND-WAITING-FOR-DSN”(235)。
如果接收的MTA不支持扩展的SMTP，则系统使用SMTP发送消息(236)，并且把目的地的状态记录为“DELIVERED”(237)。
传递该消息后，系统将存储(E)SMTP对话，以随后可以恢复的方式记录该传递(238)，并且试图发送消息到另一个目的地。
把消息发送到其目的地后，系统必须执行若干功能，以便收集关于消息配置的信息。图2C图示说明了系统处理由收件人MTA返回的MTA通知的过程。
由于图2B步骤221示出的已发送消息的报头所使用的格式，因此MTA消息通知将被传递到服务器上的虚构的本地地址。该系统将能够通过它们地址中嵌入的字串(例如“rcpt”)来检测这些通知(241)。通过分析地址，如步骤242所示，系统可以确定目的地提示已收到通知的那个消息。
在步骤243中，系统在已接收的MTA的主题行和正文扫描短语，搜索指示MTA是否正在报告一个成功的传递、一个失败的传递，或者指示该消息已经转送到另一个服务器的短语。
在步骤243上的处理显示该通知正在报告一个成功的传递的情况下，如步骤245所示，该系统将把相关消息的相关目的地的传递状态改成“DELIVERED-TO-MAILBOX”。
如果系统确定MTA通知正在报告一个传递失败，则系统将(247)把相关消息的相关目的地的传递状态改成“FAILURE”。
如果系统确定MTA通知指示消息被转送到另一个服务器，则系统将如步骤249所示的那样，把相关消息的相关目的地的传递状态改成“RELAYED”。
处理MTA通知后，系统将以这样一种方式保存该消息及其所的附件，使得以后可以在构造该目的地的收据时恢复并使用这些消息和附件(250)。
如图2D所示，有时系统将检查每个消息的状态，以确定该系统是否已经恢复所有可能是为消息的每个目的地接收的MTA通知，从而继续构建消息的收据。
系统将检查该消息的每个目的地的传递状态。
如果任何目的地具有传递状态“UNSENT”，那么消息的处理则未完成(252)。
如果目的地的传递状态是“DELIVERED-AND-WAITING-FOR-DSN”，那么系统将不把该目的地的处理视作完成，除非，如步骤254所示，自消息传递之后的时间已经超过了系统的等候时段(例如，24小时)。
如果目的地的传递状态是“DELIVERED”(257)，那么系统将该目的地的处理视作完成，只要(258)已经经过了一段时间，而该系统的操作员认为在这段时间内足以接收来自目的地的MTA的传递失败的通知(例如，2个小时)。
任何其它的目的地传递状态(例如，“FAILED”、“UNDELIVER-ABLE”、“DELIVERED TO MAILBOX”被视为已经完成的处理。
如果任何一个消息的目的地的处理是未完成的，则系统不采取行动，而是转而考虑系统中的其它消息(步骤255)。
然而，如步骤259所示，如果消息的每个目的地的处理是完成的，则系统将生成消息的传递收据。
如图2E的实例所示，收据可以包括如方框271中所示的用于管理目的的标识符。该标识符可以是或者可以包括发送者的ID的参考值和/或由系统接收的发送者的消息的互联网消息ID值。
如方框272所示，还可以包括原始消息12的引用正文与消息的预期收件人的电子邮件地址。
如方框273所示，每个收件人的列表可以包括a)收件人的MTA接收消息的时间和/或系统从收件人的MTA收到DSN的时间；b)该目的地的消息的传递状态报告，即，“传递到邮件服务器(Delivered to Mail Server)”、“传递到邮件箱(Delivered to MailBox)”、“传发(Relayed)”、“传递失败(Delivery Failure)”、“不能传递(Undeliverable)”；如方框274所示，电子邮件的原始附件的列表和它们的独立散列值或者消息摘要。
如方框275所示，到每个目的地的消息传递中所包含的所有SMTP对话的副本或者该副本的提要。
如方框276所示，来自所有收到的DSN的正文和附件的引证，包括它们可以展现的消息传递或配置的细节。
如方框277所示，该系统可以给收据添加原始消息的所有附件的拷贝，以及如方框278所示，系统可以另外添加返回到系统的文件作为DSN的附件。
在步骤279，至此已经生成了收据的文本，然后该系统生成用于电子邮件消息的第一散列和用于收据正文的任何附件的第二散列，并且使用只有该系统操作员知道的加密密钥计算每个散列的数字签名。加密可以使用例如，联邦信息处理标准公告4-2(FIPS PUB 46-2)所述的数据加密标准、国家标准和技术学会的数据加密标准，这里作为参考引出。作为选择，可以使用加密散列值的其它已知方法或者新的方法。
在步骤280，把加密的散列附加到消息的结尾，作为“文件数字签名”。
在步骤281，通过电子邮件将现在完成的收据20发送给发送者，并建议把它留作发送者的记录。在步骤282中，系统现在可以删除原始消息、附件和DSN的所有拷贝。作为替代，系统不把收据发送给发送者，而是可以存储收据，或者发送者和系统两者都可以存储收据。
由于仅仅在收件人选择时和仅仅在收件人对收到的消息采取某个操作时返回MUA通知，因此该系统的实施例可以选择把这些返回消息视为不同于MTA通知。
图2F示出了系统如何处理这些MUA通知的情况。系统通过采用图2A的步骤211的方式把各种报头加入输出消息中，来请求MUA通知。这些报头指导顺从的MUA把通知发送给为此目的留出的一个系统地址(例如，readreciept@RPost.com)。这些报头还使用该返回地址的“名称”字段中的消息的原始发送者的电子邮件地址。所以，在步骤286中，当MUA通知被返回到readreciept@RPost.com时，系统可以通过检查通知的地址来确定应当发送一个阅读通知给什么地址。
一旦来自目的地的MUA的阅读收据到达，系统就(在步骤287)生成一个阅读收据，它包含收到的MUA通知的主题作为其主题，并且在消息正文中并入收到的MUA通知的正文。
在步骤288中，系统把可以伴随MUA收据的任何文件(这些文件通常可以包括传递或者处置的细节以及原始电子邮件的识别参考)添加到该收据上。
在步骤289中，系统为附加到收据上的任何文件生成一个散列，并且把该散列记录在收据的正文中。
在步骤290中，系统为收据正文和它的附件生成一个散列，加密该散列，并且把加密的散列结果附加到消息上，作为“文件数字签名”。
在步骤291中，系统把所得到的收据发送给消息的发送者。在步骤292中，发送该收据后，系统可以删除该次处理的所有内部记录。
III.RPOST作为第二邮件服务器的实施例图3是本发明的第二实施例的系统图，其中Rpost服务器14不用作用户的主要MTA，而是与另一个MTA合作工作。在该实施例中，通过把某种形式的标记包含在输出消息、消息主题或者消息地址中，发送者可以选择登记一个特定的输出消息。例如，当且仅当发送者把符号“(MR)”或“(Made of Record)”放入消息的主题中，发送者的MTA才指导消息经由RPost服务器14发送，以生成一个收据。
在该实施例中，RPost的操作者从发送者的MTA的操作者那里按照发送的每条消息和/或每千字节获得收入。
IV.CC TO RPost实施例图4是将副本(“cc”)发送给RPost服务器14的第三实施例的系统图。在该实施例中，用户或者消息发送者10可以使用未经修改的标准MUA和标准MTA。消息发送者10构成具有消息正文和任何数量的附件的电子邮件，并且如预期地把该电子邮件与任何副本(cc)及隐蔽副本(bcc)传递到消息收件人18。此外，消息发送者10把一个副本传递给RPost。RPost服务器14给上述的消息加标签，并且发送包括收件人的MTA 16的附件的加标签消息和任何指定的cc。当收到这样一个副本时，RPost服务器14可以发送确认收到该副本的电子邮件。
收件人18和消息的其它目的地现在将接收到相同消息的两个版本一个直接从发送者10接收的消息的第一版本，一个从RPost传送的第二加标签版本。一旦从收件人MTA16收到确认，确认消息的加标签版本被收件人MTA16成功地接收，Rpost服务器14将构成上述的消息收据20，并且把该收据发送给发送者10用于他的记录。
通过建立用于消息始发域或者各消息发送者的帐户，并且按每条消息、每千字节、每月或者这些组合在用户帐户上记帐，就可以产生收入。收入还可以这样产生在收据上放置广告，提供前述的鉴别和验证服务。
V.环球网站实施例图5示出了第四实施例的一个系统图。在该实施例中，RPost服务器14与用户构成消息的环球网站点(简称网站)相关联。消息发送者10访问RPost网站，并且在该网站上通过键入预期的“to”、“cc”、“bcc”、“主题”和消息文本信息来构成他的消息。通过使用在标准浏览器和环球网服务器上可用的功能可以加入附件。在该实施例中，发送者提供登记收据可以被发送到的一个地址。RPost服务器14经由发送者的MTA把该收据发送给发送者10。
通过建立用于消息始发域或者各消息发送者的帐户，并且按每条消息、每千字节、每月或者这些组合在用户帐户上记帐，就可以产生收入。收入还可以这样产生在收据上放置广告，提供前述的鉴别和验证服务。
VI.基于环球网的MUA实施例图6是第五实施例的系统图。在该实施例中，RPost服务器14与基于环球网的邮件用户代理相关联。除了允许用户通过环球网浏览器构成邮件外，这样的MUA还向用户提供浏览器可浏览的邮件箱，以显示存储在环球网服务器站点上的消息。预订这种服务的用户用用户名和口令访问邮件帐户。在该实施例中，消息发送者10访问RPost环球网站，通过键入用户名和口令访问基于环球网的电子邮件帐户，并且构成他的传送消息，向RPost服务器14传递。RPost服务器14生成的收据被返回到与用户帐户关联的基于环球网的邮件箱。
除了其它实施例中可得到的收入来源外，在该实施例中，操作员可以收取收件人在基于环球网的邮件箱中的存储费。
在所有这些实施例中，收据可以用作以下各项的证据(1)始发者发送了一个电子邮件消息；(2)消息在某个时间被发送了；(3)电子邮件被传递到某个收件人；(4)电子邮件被传送到它的每一个预期收件人的电子邮件箱；(5)在某个时间传递了电子邮件；(6)电子邮件通过某条网络路径传递；和(7)电子邮件消息和它的附件具有记录在收据中的特定内容。
此外，在某些情况下，系统生成一个单独的收据，它可以用作以下证据(1)电子邮件经由收件人的邮件用户代理(MUA)检查；和(2)收件人响应该消息而采取某些行动，例如，在特定时间阅读或者删除电子邮件。
如同其它实施例，该实施例产生已记录的证据，该证据可以由涉及电子消息的内容和传递的系统的公正的第三方操作员证明和验证。换句话说，可以把该系统看作，将电子邮件变换为已登记的电子邮件，以便以后使用该已登记的电子邮件证明一个特定的电子邮件被发送、被成功地传递，以及何时和如何传递。
如果发生争议，该争议可以通过由系统产生的收据来解决，因为收据的编码使得系统的操作员可以确定该收据是否为系统的产品的真实性。因此，根据包含在收据自身中的信息，而不需要操作员保存该收据中信息的任何记录或拷贝，系统的操作员就可以证实包含在真实收据中的信息的准确性。
除了这些优点外，该系统生成的收据作为诸如经由该系统发送的材料的存在和原作者的证据也是有用的。此外，该系统容易使用，因为该系统可以通过任何互联网电子邮件客户程序/MUA使用，所以不需要附加软件。
验证收据的流程7是说明验证收据的示范性方法的流程图。如果消息的发送者需要发送和传递(和/或阅读)电子邮件的证据，则发送者把对应于该消息的收据呈现给系统的操作者(步骤700)。在步骤702，系统的操作员分离和解密附加到收据上的文件数字签名。在步骤703，操作员生成余下的文件包括附件的一个散列。
在步骤704，如果当前的散列值与解密散列值不匹配，那么系统生成一个报告，声明RPost不能把该收据确认为收据中描述的消息的传递或者内容的准确记录。
如果解密的散列值等同于消息的当前散列，则系统如步骤706所示，证明消息正文中的信息未变化，因为该收据通过了该系统。如果原始消息不包含附件，则系统现在可以生成一个报告，证明该收据是RPost服务器发出的消息内容和其传递的准确记录。
如果收据报告原始消息包含附件，则该收据还将记录每个附件的名称和散列值。在生成收据时，原始消息的所有附件未加变化地附加到该收据上。所以，系统将为每个这样的附加文件生成附加文件的散列(708)，并将它与收据正文中记录的散列值比较(709)。
如果文件的计算散列值与收据中包含的散列值匹配，则系统可以证明附加到收据上的文件与附加到原始传递的消息上的文件相同。如果这两个散列不匹配，则系统将报告它不能证明该收据的附加文件与附加到原始消息上的文件相同。
对附加到原始消息上的每个文件进行这种计算后，系统准备一个报告，对收据和其每个附加文件的真实性做出报告(710)或者报告确认失败(712)。
完成评估后，系统将把收据的拷贝和它的所有附件添加到系统已经生成的报告上，并经由电子邮件将它发送到提交确认报告的用户的返回地址。
登记入站电子邮件图8是本发明另一实施例的系统图，其中对入站的电子邮件进行登记。在该实施例中，消息发送者60发送一个电子邮件消息70。发送者的MTA 62象往常一样把消息70发送到互联网上。然而，在本实施例中，RPost与服务用户/收件人68订约，以登记入站电子邮件。根据协定，RPost由Network Solution有限公司(NSI)或者其它域名管理机构指定作为收件人68的邮件收件人(MX服务器)。这使发送者的MTA 62所提出的域名服务(DNS)请求返回RPost的IP地址，以作为收件人的IP地址，又使发送者的MTA 62发送电子邮件消息给RPost服务器64。RPost服务器64充当收件人68的SMTP、POP、POP3或者IMAP MTA(统称为“POP邮件服务器”)。SMTP、POP和IMAP MTA受RFC 821、SMTP协议、RFC1939邮局协议-版本3(替代RFC1725)和RFC2060 IMAP(互联网消息访问协议)版本4修订1(替代RFC1730)管理，这里作为参考引出。
RPost64准备原始消息70的一个被登记版本74，并且将该登记的版本74而不是原始消息70放入收件人68的收件箱，或者也把原始消息70放入该收件箱。登记的版本可以有上文中结合电子邮件收据讨论的所有验证和信息特征以及选项。该信息可以包含，但不局限于每个消息正文和文本的各消息摘要、送出/到达信息、其它报头信息、每个附件、整体消息摘要和数字签名以及消息路由选择信息和标签。图6所示的消息70的登记版本74包括包含报头信息的消息正文、一个附件、用于消息正文和附件的单独消息摘要、数字签名或者加密的消息摘要。使用只有系统操作员知道的专用短句或者专用密钥执行散列功能和加密。收件人68通过收件人的MUA得到登记版本74，用于检验或者下载。
RPost服务器64可以随意地把一个确认电子邮件72发送给消息发送者60。确认消息72可以是说明消息被接收和登记的简单文本消息。确认消息72还可以包括一个消息，诸如“你的电子邮件消息在2000年3月24日下午2点5分收到。该消息的数字签名是[128比特数字签名]。欲了解更多的信息，请访问我们的网站www.RPost.com”。作为选择，或者补充，确认消息72可以包括登记版本74中包含的所有信息。
因此，系统可以向消息收件人68提供收据74或者其它可验证的确认(1)收件人收到一个电子邮件消息；
(2)该消息在某个时间收到；(3)该电子邮件是从某个发送者传送的；(4)声称该消息经由某条网络路径来传递；(5)该电子邮件消息和它的附件具有特定的内容。
因此，系统提供了可以由系统的操作者证明的证据，证明特定的电子消息和文件被传递给收件人，它们具有确定的内容并把它们自己说成是来自确定的发送者。
图9是说明登记入站邮件的一个例子的流程图。在步骤901中，RPost服务器64接收一个新的电子邮件消息。在步骤902中，系统生成包括消息报头和附件的消息内容的散列/数字签名。此外，系统可以为每个消息附件生成单独的散列。在步骤903中，系统使用只有系统操作员知道的加密密钥对散列加密。在步骤904中，将得到的加密散列附加到消息正文上。然后，在步骤905，经由收件人的MUA得到修改的消息，用于检查或下载。
图10是验证已收到的登记的电子邮件消息的一个实例的流程图。在步骤1000中，如果消息的收件人需要在特定时间收到具有特定内容的电子邮件的证据，则该收件人可以把电子邮件消息70的已登记版本74(图8)的拷贝提供给系统的操作员，用于验证。为了验证该消息，在步骤1001中，系统分离和解密附加到该消息上的文件数字签名。在步骤1002，系统生成余下文件的一个散列，且为附加到消息上的每个文件生成一个散列。在步骤1003和1004，比较这些散列，如果文件散列与解密散列匹配，那么该消息和它的附件就通过了该系统，并且自它们传递到收件人后没有改变。
确定电子邮件没有改变后，系统操作员可以证明(1)电子邮件在某一时间被系统接收；(2)电子邮件据称是经由某一互联网路径到达系统；(3)电子邮件据称是来自某一发送者；(4)电子邮件和它的附件与它们当前包含的特定内容一起被传递。
另一方面，在步骤1006中，如果这些散列值不匹配，那么操作员就不能证明电子邮件是真的，即不能证明电子邮件是系统接收的电子邮件的正确版本。
图11图示说明了利用电子工具的商务(“电子商务”)如何使用本发明。电子商务30可以利用本系统登记来自它的客户34的所有输入和输出电子邮件消息。在这个例子中，系统包括邮局服务协议(POP)服务器36和简单邮件传输协议(SMTP)服务器38。例如，电子商务30可以建立它的网站，用电子邮件把表格发送给客户，并转送来自客户34的询问和意见40。登记的询问、意见、指令、购置的提议及其它信息46由系统发送给电子商务30。然后经由SMPT服务器38把收据提供给客户34。这样就不存在关于客户是否发送通信以及该通信包含什么的问题。此外，电子商务可以经由RPost服务器建立环球网站32，以便记录与客户的每次通信。换句话说，经过环球网站形成数据序列42，并且通过系统服务器可以登记自动响应44；此外，可以登记电子商务发送给客户34的任何一个确认、收集通知、客户支持和特别建议48，并且把确认发送给客户，以消除关于谁、何时发出什么订单的争论。如果需要，可以向客户34和电子商务30提供相同的收据。作为替代，可以把SMTP服务器38和POP服务器36的功能包含在单个系统服务器中。
POP是用来从电子邮件服务器检索电子邮件的一个协议。许多电子邮件应用程序(有时称作电子邮件客户程序)使用POP协议，尽管有些可以使用较新的互联网消息访问协议(IMAP)。称为POP2的一个POP版本需要SMTP发送消息。一个较新版本，POP3可以与或者不与SMTP一起使用。SMTP是在服务器之间发送电子邮件消息的一个协议。许多经由互联网发送电子邮件的电子邮件系统使用SMTP从一个服务器向另一个服务器发送消息。然后可以用使用POP或者IMAP的电子邮件客户程序检索消息。此外，SMTP通常被用来从邮件客户程序向邮件服务器发送消息。电子邮件服务器可以使用各种协议与互联网通信。通常使用的协议包括SMTP、POP3和IMAP4。邮件阅读者位于服务器的相反端。由于邮件服务器经由SMTP接收消息，因此，电子邮件阅读者使用SMTP把电子邮件发送给邮件服务器。同样，由于邮件服务器使用POP3和任意的IMAP4发送消息，因此邮件阅读者使用POP3或者IMAP4协议接受来自邮件服务器的消息。
尽管上文一般性地说明了验证电子邮件被发送和/和被接收的系统和方法，但是在09/626,577号申请中所公开和要求的本发明可应用于任何电子消息，这些电子消息可以通过电子消息网络或者通过任何电子门发送。电子消息可以包括文本、音频、视频、图像、数据和各种文件类型的附件。这里所教的方法和技术可以被编程到服务器和其它计算机中，实现本发明的计算机程序可以被写入计算机可读介质，所述计算机可读介质包括但不限于CD ROM、RAM、硬盘驱动器、磁带。本发明的电子邮件登记服务可以与互联网服务供应者(ISP)服务捆绑在一起，以向公司或者其它机构客户提供单个ISP解决方案。实施上述发明在软件技术的普通专业人员技能的范围之内。如上文所指出的，图1～11表示，以及说明书描述的多个系统，其中，服务器接收来自发送者的一个消息，并以第一个路径把该消息传送给一个收件人，或该收件人的邮件传送代理(MTA)。有时，发送者也许希望通过一条与第一条路径相比，更常走的路径或较少走的路径，或至少是一条不同的路径使服务器把消息发送给收件人或该收件人的邮件传送代理。为完成这一任务，发送者以特殊的指示如“(R)”在特定的位置如消息的“主题”行，标记消息形式1200(图14)。这一特定的位置在图14中的消息形式1200中指出在1202。在消息的“主题”行1202标记“(R)”的步骤表示在图12的1206。
发送者把在“主题”行具有“(R)”的消息传送给构成发送者的邮件传送代理的服务器14。这表示在图12的1208。如1210所指出的，服务器扫描“主题”行以确定在该行中是否存在“(R)”。如果回答是“No”(参见1211)，服务器通过图1～11所示的、图12指出的如“通常路径”一样的和以上说明书讨论的路径，传送消息给收件人或收件人的邮件传送代理。这表示在图12的1212。如果回答是“Yes”(参见1213)，消息通过图14中1214指出的特殊网络路径来传送。
图13在许多方面与图12是一致的。但是，图13包括另外的块，以执行不同于图12中所示的另外的功能。这些包括、但不限于以下方面(1)发送者可能希望消息的拷贝应该被存档。这可通过添加一个编码来完成，如在“主题”行的“(R)”后加数字“1”，这样，该编码是“R1”。
(2)发送者可能希望传送的记录应该通过构成发送者的邮件传送代理的服务器14来记录。这可通过在消息的“主题”行中提供如“(R2)”这样的编码来完成。
(3)发送者可能希望消息传送的记录应该在数据库中记录。这可通过在消息的“主题”行中提供如“(R3)”这样的编码来完成。
(4)发送者可能希望消息传送的记录应该在数据库中记录，且带有特定注释或另外的参考。这可通过在消息的“主题”行中提供如“(R4)”这样的编码来完成。
图13提供了一个方法，即构成发送者的邮件传送代理的服务器处理所选择的电子邮件消息，如在本段中所详述的消息。
图13特别在消息的“主题”行中限制编码为“(xyz)”。在图13中，在1300的发送者构成在电子消息的“主题”行中包括“(xyz)”的电子消息。如图12和13中所指出的，构成邮件传送代理的服务器14扫描发送消息的“主题”行。如果消息的“主题”行不包括码“(R)”，则服务器通过图1～11所示的和上文讨论(参见图12和13的1212)的路径传送消息。如果服务器检测到消息的“主题”行存在码“(R)”，那么服务器通过图12和13的1214所指出的特定网络路径传送消息。
图13的1304指出，服务器从消息的“主题”行剥离码“(xyz)”。如果检测到分隔符“xyz”，则保存消息的拷贝。这在图13的1308指出。如果没有识别出分隔符“xyz”，则不保存消息的拷贝。
尽管本发明已结合优选实施例和其附图进行了详细说明，但本领域技术人员应该明白的是，在不脱离本发明的精神和范围的情况下，可完成本发明的各种修改和改变。因此，应理解的是，本文的详细描述和附图不是用于限制本发明的范围，本发明的范围仅仅依据下面的权利要求以及其适当解释的合法等同物来推定。在所附的权利要求中，那些包含单词“means for”的权利要求被规定为按照35 U.S.C.§112的第六段来解释；那些未包含单词“means for”的权利要求不按照35U.S.C§112的第六段来解释。
权利要求
1.一种从发送者到收件人通过互联网传送消息的方法，通过从所述收件人置换的服务器，包括多个步骤在所述服务器接收来自所述发送者的所述消息，和接收一个指示，表示所述发送者希望以对于所述发送者来说特殊的方式发送消息，且该方式是所述服务器通常不提供的，通过互联网以所述特殊方式从服务器到所述收件人的代理传送所述消息，与来自所述发送者的所述指示、所述服务器的标识和互联网地址、以及所述发送者的身份相一致，在所述服务器通过互联网从所述代理接收所述代理的身份和所述代理发送的所述消息收据的一个指示，以及所述服务器的所述标识和互联网地址和所述发送者的身份，和从所述服务器通过互联网给所述发送者发送信息的拷贝和来自所述代理、由所述服务器接收的信息。
2.根据权利要求1所述的方法，其中当所述发送者没有通过互联网提供一个指示，表示所述发送者希望通过互联网以特殊方式传送消息到所述收件人的所述代理时，通过互联网从所述服务器到所述收件人的所述代理的传送是以正常的方式进行的。
3.根据权利要求1所述的方法，其中所述服务器通过互联网接收的、来自所述收件人的所述代理的所述指示包括所述代理和任何传送代理的一个标识，通过这些传送代理，消息在所述服务器和所述收件人的所述代理之间通过。
4.根据权利要求1所述的方法，其中所述消息的一个数字指纹由独特的数字序列提供，并由所述服务器发送给所述发送者。
5.根据权利要求3所述的方法，其中当所述发送者没有通过互联网提供一个指示，表示所述发送者希望通过互联网以特殊方式传送消息到所述收件人的所述代理时，通过互联网从所述服务器到所述收件人的所述代理的传送是以正常的方式进行的，和其中由独特的数字序列提供所述消息的一个数字指纹，并由所述服务器发送给所述发送者。
6.根据权利要求1所述的方法，其中一个附加的指示由来自所述发送者的消息提供给所述服务器，指出从所述服务器到所述收件人的所述代理的消息的发送应该由所述服务器提供高优先级，和其中依照所述的附加指示，所述服务器给到所述收件人的所述代理的信息的发送提供高的优先级。
7.根据权利要求5所述的方法，其中一个附加的指示由来自所述发送者的消息提供给所述服务器，指出从所述服务器到所述收件人的所述代理的消息的发送应该由所述服务器提供高的优先级，和其中依照所述的附加指示，所述服务器给到所述收件人的所述代理的消息的发送提供高的优先级。
8.根据权利要求1所述的方法，其中一个附加的指示由来自所述发送者的消息提供给所述服务器，指出从所述服务器到所述收件人的所述代理的消息的发送应该由所述服务器记录，和其中依照所述的附加指示，所述服务器记录从所述服务器到所述收件人的所述代理的消息的发送。
9.根据权利要求5所述的方法，其中一个附加的指示由来自所述发送者的消息提供给所述服务器，指出从所述服务器到所述收件人的所述代理的消息的发送应该由所述服务器记录，和其中依照所述的附加指示，所述服务器记录从所述服务器到所述收件人的所述代理的消息的发送。
10.一种通过互联网从发送者传送消息到收件人的方法，这是通过从所述收件人置换的服务器，包括所述服务器上的多个步骤在所述服务器接收来自所述发送者的所述消息，在所述服务器接收来自所述发送者的所述消息和一个指示，该指示表示所述服务器通过一个特殊方式传送消息，该特殊方式不同于所述服务器通常传送消息时提供的方式，通过互联网，以从所述发送者到所述服务器指出的所述特殊方式、从所述服务器到所述收件人的一个代理传送所述消息，以及所述服务器的标识和互联网地址、和代表所述发送者身份的一个指示，所述服务器从所述代理接收握手，以及从所述服务器到所述收件人的所述代理的消息的传递记载，和通过互联网从所述服务器到所述发送者传送所述消息、所述消息的包括数字指纹的数字签名，以及握手和所述服务器接收的来自所述收件人的所述代理的消息的传递记载。
11.根据权利要求10所述的方法，包括步骤所述服务器接收来自所述发送者的所述消息、和一个附加的指示，该指示表示从所述服务器到所述收件人的所述代理传送所述消息时从所述服务器执行一个附加的功能，依照从所述发送者到所述服务器提供的所述的附加指示，在从所述服务器到所述收件人的所述代理传送所述消息时提供所述的附加功能。
12.根据权利要求11所述的方法，其中在所述服务器从所述收件人的所述代理接收所述握手，以及从所述服务器到所述收件人的所述代理的消息传送的传递记载后，所述服务器发送所述消息给所述发送者，其中，所述服务器在发送所述消息给所述发送者之后，所述服务器不保留所述消息。
13.根据权利要求11所述的方法，其中从所述发送者到所述服务器的所述附加指示规定所述消息的传送的记录，其中按照来自所述发送者的所述附加指示记录所述消息的传送。
14.根据权利要求11所述的方法，其中来自所述发送者的所述附加指示规定所述消息的存档，和其中按照来自所述发送者的所述附加指示存档所述消息。
15.根据权利要求11所述的方法，其中来自所述发送者的所述附加指示规定通过一个特殊路径把所述消息发送到所述收件人的所述代理，其中按照来自所述发送者的所述附加指示，从所述服务器通过所述特殊路径传递所述消息到所述收件人的所述代理。
16.根据权利要求11所述的方法，其中来自所述发送者的所述附加指示规定在从所述服务器到所述收件人的所述代理的消息传递中对所述消息进行特殊处理，和其中从所述服务器到所述收件人的所述代理传递所述消息时，所述消息被特殊处理。
17.根据权利要求11所述的方法，其中所述附加指示规定从所述服务器到所述收件人的所述代理的消息的发送有高的优先级，和其中按照来自所述发送者的所述附加指示，具有高优先级的所述消息从所述服务器发送到所述收件人的所述代理。
18.根据权利要求11所述的方法，其中所述服务器通过互联网给所述发送者发送所述消息、所述消息的数字签名、所述握手以及所述消息的传递记载后，除非所述发送者要求，否则所述服务器不保留所述消息的拷贝，只保留所述消息的数字签名、所述握手以及所述消息的传递记载的拷贝。
19.根据权利要求10所述的方法，其中除了所述消息之外，所述服务器保留来自所述收件人的所述代理、由所述服务器接收的信息的拷贝，并发送给所述发送者，和其中当所述发送者希望验证所述消息由所述服务器发送给所述收件人的所述代理时，所述服务器把除了所述消息之外的、由所述服务器发送给发送者的有关所述消息的信息和服务器保留的有关所述消息的信息进行匹配。
20.根据权利要求10所述的方法，其中当所述服务器发送消息给所述代理时，所述服务器要求来自所述收件人的所述代理的有关该消息的传递状态通知，和其中当所述服务器收到来自所述代理的消息的数字签名时，所述服务器就收到来自所述收件人的所述代理的传递状态通知。
21.在通过互联网把消息经由替代收件人的服务器发送给收件人的方法中，所述服务器上的步骤包括在所述服务器上接收来自发送者的消息，以编码形式生成构成消息摘要的散列，用特定加密码加密该散列，以生成所述消息的数字指纹，从所述发送者接收一个指示和来自发送者的消息，该指示指出服务器以不同于服务器正常处理消息的特殊方式处理该消息，和按照来自所述发送者的所述指示，在服务器上以特殊方式处理所述消息，给所述收件人传送消息和数字指纹。
22.根据权利要求21所述的方法，步骤为为所述消息的任何附件，以编码形式生成构成附件摘要的散列，用特定加密码加密来自附件的散列，以生成附件的数字指纹，和通过互联网把附件和该附件的数字签名发送给发送者，同时以同样的方式通过互联网从服务器向发送者发送消息和消息的数字指纹。
23.根据权利要求21所述的方法，其中当所述发送者没有伴随消息给所述服务器提供指示时，所述服务器以正常方式处理消息，和其中当所述发送者伴随消息给所述服务器提供指示时，所述服务器以特殊方式处理消息。
24.根据权利要求23所述的方法，其中当所述发送者没有伴随消息给所述服务器提供指示时，所述服务器在第一路径中处理消息，和其中当所述发送者伴随消息给所述服务器提供指示时，所述服务器在不同于第一路径的第二路径中处理消息。
25.根据权利要求23所述的方法，步骤为在服务器上存储消息的数字指纹、发送者姓名、服务器的身份及互联网地址和收件人的身份及互联网地址，和向发送者发送由发送者存储的消息、消息的数字指纹、发送者姓名、服务器的身份及互联网地址、收件人的身份及互联网地址。
26.根据权利要求22所述的消息，当发送者没有伴随消息给所述服务器提供指示时，所述服务器以正常方式处理消息，和其中当发送者伴随消息给所述服务器提供指示时，所述服务器以特殊方式处理消息，和其中当发送者没有伴随消息给所述服务器提供指示时，所述服务器在第一路径中处理消息，和其中当发送者伴随消息给所述服务器提供指示时，所述服务器在不同于第一路径的第二路径中处理消息，和其中在所述服务器上存储消息的数字指纹、发送者姓名、服务器的身份及互联网地址、收件人的身份及互联网地址，和向发送者发送由发送者存储的消息、消息的数字指纹、发送者姓名、服务器的身份及互联网地址、收件人的身份及互联网地址。
27.通过互联网把消息经由替代代理的服务器从发送者发送给收件人的代理的方法，步骤包括在服务器上提供来自发送者的消息，在服务器上提供消息的数字指纹、发送者身份、服务器的身份及互联网地址，以第一路径把消息、发送者的身份、服务器的身份及互联网地址传递给所述代理，在服务器上提供来自发送者的指示，指出来自发送者的消息应该由所述服务器通过不同于第一路径的第二路径传送给发送者，按照来自所述发送者的所述指示，通过第二路径把消息从服务器传送到收件人的代理，在所述收件人的代理上提供在从服务器发送到消息的代理的传送代理上的接收状态的指示和发送者的身份、服务器的身份及互联网地址，从所述收件人的代理向服务器发送代理的身份及互联网地址、在消息的代理上的接收状态、发送者的身份、服务器的身份及互联网地址。
28.据权利要求27所述的方法，其中所述消息的数字指纹包括消息的数字摘要和数字摘要的加密，和其中服务器向发送者发送所述消息和该消息的数字指纹、发送者的身份、服务器的身份及互联网地址、所述收件人的代理的身份及互联网地址、消息代理上的接收代理的状态。
29.据权利要求27所述的方法，其中所述发送者在服务器上规定在所述服务器执行的一个附加功能，和其中按照来自所述发送者的指示，所述服务器执行所述附加的功能。
30.据权利要求29所述的方法，其中所述附加指示规定从所述服务器到所述收件人的所述代理传递所述消息时，对所述消息进行特殊处理，和其中从所述服务器到所述收件人的所述代理传递所述消息时，所述消息被特殊处理。
31.据权利要求28所述的方法，其中所述发送者在服务器上规定在所述服务器执行的一个附加功能，和其中从所述服务器通过第二路径传递所述消息到所述收件人的所述代理时，由所述附加指示代表的附加功能规定被特殊处理的消息，和其中从所述服务器通过第二路径传递所述消息到所述收件人的所述代理时，所述消息被特殊处理。
32.通过互联网从发送者把消息经由替代收件人的代理的服务器发送给收件人的代理的方法，所述服务器上的步骤包括在服务器上提供消息的数字指纹、发送者身份、服务器的身份及互联网地址，通过第一路径把消息、发送者身份、服务器的身份及互联网地址传递给所述收件人的所述代理，接收来自发送者的指示，指出所述消息应该由所述服务器通过不同于第一路径的第二路径传送到所述收件人的所述代理，按照来自所述发送者的所述指示，通过不同于第一路径的第二路径给所述收件人的所述代理传送消息、发送者的身份、服务器的身份及互联网地址，从所述收件人的所述代理接收发送者的身份、服务器的身份及互联网地址、代理的身份及互联网地址、代理上的消息接收状态的指示，和向发送者发送服务器从有关所述消息的收件人的代理接收的消息和信息。
33.根据权利要求32所述的方法，其中所述服务器存储有关服务器传送给发送者的消息的信息，但不该存储该消息，和其中所述服务器通过把由该服务器存储的与所述消息有关的信息，与从服务器发送给发送者的、有关所述消息的信息进行比较来验证消息。
34.根据权利要求32所述的方法，其中从所述服务器到所述收件人的所述代理传递消息时，所述服务器从所述发送者接收附加的信息，该信息与所述服务器执行的附加功能有关，和其中从所述服务器传递消息到所述收件人的所述代理时，按照所述服务器从所述发送者接收的附加信息，所述服务器对所述消息执行附加的功能。
35.根据权利要求34所述的方法，其中所述服务器从所述发送者接收的指示构成来自所述发送者的消息的第一编码，和其中所述服务器从所述发送者接收的、由所述服务器执行的附加功能的附加信息，构成来自所述发送者的消息的第二编码，且被加到第一编码上。
36.根据权利要求33所述的方法，其中从所述服务器传递消息到所述收件人的所述代理时，所述服务器从所述发送者接收有关由所述服务器对消息执行的附加功能的附加信息，和其中从所述服务器传递消息到所述收件人的所述代理时，按照所述服务器从所述发送者接收的附加信息，所述服务器对消息执行附加的功能，和其中所述服务器从所述发送者接收的指示构成来自所述发送者的消息的第一编码，和其中所述服务器从所述发送者接收的、由所述服务器执行的附加功能的附加信息，构成来自所述发送者的消息的第二编码，且被加到第一编码上。
全文摘要
服务器从发送者收到消息，并把该消息通过互联网传递给收件人。该服务器通常以第一路径通过互联网传递该消息到该收件人。当发送者在消息的特定位置指出该消息已登记时，服务器以第二路径通过互联网传递该消息到该收件人。发送者也可以在消息中提供附加指示，使服务器以其通常不提供的其它特殊方式来处理该消息。在通过互联网从收据或收件人的代理得知该消息已成功收到后，服务器创建、并传递给发送者一个电子收据。该数据至少包括，最好是全部包括消息和任何附件、列出传递成功/失败的收据表、收件人的特定代理接收的收据时间，收件人其它代理接收消息的失败，以及随后的消息及其附件的数字签名。通过验证发送者收据上的数字签名与服务器上的数字收据相匹配，服务器不用保留该消息就可以验证收据是真实的，消息是准确的。
文档编号G06F13/00GK1636365SQ03804280
公开日2005年7月6日 申请日期2003年2月21日 优先权日2002年2月22日
发明者T·A·托姆科夫 申请人:Rpost 国际公司