专利名称：分发共同始发邮件的系统和方法
技术领域：
本发明一般涉及分发基于计算机的邮件或电子邮件的领域，尤其涉及允许由所有电子邮件始发者(originator)控制共同始发的(co-originated)电子邮件的系统和方法。
背景技术：
第一种电子邮件系统只使用某些文件传输协议，其中在作为文件发送的消息中，第一行包含接收者的地址。更详细说明的电子邮件系统已经由RFC(请求注解(Request For Comments))文件定义，RFC文件标准化了邮件传输协议，诸如简单邮件传输协议(SMTP)、RFC 2821和因特网消息格式(RFC822和RFC 2822)。而且，RFC还定义了更复杂的邮件内容支持，诸如MIME(多用途因特网邮件扩展(Multipurpose Internet Mail extensions))，MIME将多媒体扩展添加到现有的电子邮件系统MIME允许分发包括多媒体内容和因特网链路的邮件。
使用SMTP模型，操作终端用户计算机的邮件用户代理(mail user agent)允许终端用户编写消息的文本和创建包含终端用户名称(发送者名称)、接收者名称和其它邮件传递信息的首标。充当客户的邮件用户代理将邮件发送到本地邮件服务器，即将更多首标添加到从邮件用户代理接收的邮件上的邮件传输代理(MTA，Mail Transfer Agent)。MTA在TCP协议层上实现SMTP协议层，TCP是用于MTA之间的邮件传输的协议。由邮件用户代理发送的邮件在到达接收者的本地MTA之前，可能要经过数个MTA。MTA实现存储和转发机制，该机制包括存储所接收的邮件以及当发现TCP信道可用时转发该邮件。
基于此SMTP模型，已经在消息格式本身方面进行了改进，以提供越来越多的功能。在RFC 2822的消息格式中，描述了一种当一群人进行合作作业时所使用的可能性。利用SMTP，准备简单邮件的用户指示发送者名称(邮件首标的“from”字段)和接收者名称，该接收者名称可能是最后接收者名称(“to”字段)、副本中的人名(“.cc”字段)和“信件复写副本”(BlindCarbon Copy)中的人名(“.bcc”字段)。利用RFC 2822，描述了始发者字段。“from”字段允许在邮件中指示多于一个的始发者(或作者)，即使只有一个发送者准备该邮件并且因而负责准备其内容。接收者并不知道谁准备和发送了看上去如同由所有的共同始发者(co-originator)和真正的发送者一起发送的消息。然而，其他的共同始发者不能控制发送者代表他们写什么。这可能产生以下情况下的冲突情形当其他的共同始发者自动地接收到由真正的始发者即发送者所发送的邮件副本时，一旦他们接收并读取了该邮件，他们不能最终认同该邮件的内容。这在当一次会议之后将会议记录或共同决定的行动计划发送到目标组人员以便采取行动时是很常见的。
因此，需要提供一种系统和方法，用于允许一组共同始发者正式批准由他们中将成为邮件的最终发送者的那个人所准备的邮件，该批准发生在邮件被发送到接收者的分发列表之前。
发明内容
因此，本发明的一个目的是提供一种与诸如SMTP等邮件分发系统模型兼容的系统和方法，其中，邮件的一组共同始发者能够在他们当中之一代表所有的共同始发者发送该邮件之前批准它。
通过一种方法达到上述目的，该方法用于分发由一个始发者即发送者发送的共同始发邮件到至少一个接收者，所述邮件具有多于一个的始发者，即共同始发者，并且是从正在执行客户邮件应用程序的工作站发送的，该客户邮件应用程序与通过网络与其它邮件服务器通信的本地邮件服务器连接(interface)，所述方法包括下列步骤a-在本地邮件服务器接收共同始发邮件b-本地邮件服务器将该邮件发送到共同始发者，但不发送到发送者，并请求邮件确认c-如果本地邮件服务器从所有的共同始发者接收回邮件确认，则从本地邮件服务器将经过确认的邮件发送到至少一个接收者d-如果本地邮件服务器从第一共同始发者接收回邮件更新的请求，则本地邮件服务器从成为发送者的第一共同始发者收集更新的邮件，而更新的邮件成为将要确认的新邮件并且从本地邮件服务器重复步骤b-、c-和d-，直到一个邮件被所有的共同始发者所确认，并且被发送到至少一个接收者为止。
在附属的从属权利要求中规定了本发明的更多实施例，这些从属权利要求也实现了本发明的目的，诸如权利要求1所述的方法，其中步骤d-还包括下列步骤如果本地邮件服务器在还没有完成对来自第一共同始发者的更新邮件的收集步骤时，从一个第二共同始发者接收到邮件更新请求，则本地邮件服务器在完成对第一共同始发者的收集步骤之后，执行第二个收集步骤，以便从第二共同始发者获得二次更新的邮件；执行重复步骤，所述第二共同始发者成为发送者，而二次更新的邮件成为用于重复步骤的将要确认的新邮件。
如权利要求3所述的方法还通过进一步包括下列步骤，来实现本发明的目的如果本地邮件服务器在还没有完成对来自第一共同始发者的更新邮件的收集步骤时，从至少一个共同始发者中的第二个接收到对将要更新的邮件的邮件确认，则本地邮件服务器完成对第一个共同始发者的收集步骤，所述第一共同始发者成为重复步骤的发送者，而更新的邮件成为将要确认的新邮件。
如权利要求4所述的方法还通过进一步包括下列步骤，来实现本发明的目的如果本地邮件服务器在还没有完成对来自第一共同始发者的更新邮件的收集步骤时，从第一共同始发者接收到取消更新请求，则本地邮件服务器认为该第一个共同始发者已经确认该邮件，并执行步骤c。
如权利要求5所述的方法还通过在收集步骤中进一步包括下列步骤，来实现本发明的目的从本地邮件服务器将更新邮件的请求发送到已经发送回邮件更新请求的共同始发者；从所述一个共同始发者接收更新的邮件。
如权利要求6所述的方法还通过进一步包括下列步骤，来实现本发明的目的每次由本地邮件服务器接收到共同始发邮件时，本地邮件服务器在邮件表中建立条目，该条目标识邮件、初始的邮件发送者、邮件版本号和邮件的共同始发者列表，其中邮件版本号是最后的邮件版本号；
每次由本地邮件服务器从共同始发者接收到更新邮件时，本地邮件服务器将该表中的版本号递增，作为用于对应邮件的最后版本号；每次由本地邮件服务器从共同始发者接收到邮件确认或取消更新时，本地邮件服务器在该表中针对对应邮件、共同始发者以及版本号来存储邮件确认状态；每次在接收到更新的邮件之前接收到邮件更新请求时，本地邮件服务器在该表中针对对应邮件、共同始发者以及版本号来存储该更新请求的状态。
如权利要求7所述的方法还通过在由本地邮件服务器测试是否所有的共同始发者都发送回邮件确认的步骤中进一步包括下列步骤，来实现本发明的目的在该表中读取对应于该邮件的所有共同始发者的状态是否是邮件确认。
如权利要求8所述的方法还通过如下方式来实现本发明的目的其中，在从共同始发者接收到更新的邮件的每一个步骤后执行下列步骤如果邮件表中更新请求的状态针对该邮件而与第二个共同始发者相关联，则执行对第二个共同始发者的二次更新邮件的收集步骤。
如权利要求9所述的方法还通过如下方式来实现本发明的目的其中，本地邮件服务器的接收和发送步骤包括使用SMTP协议传送邮件的步骤；并且其中，除了到至少一个接收者的发送步骤以外，由本地邮件服务器执行的发送步骤包括用命令字段来填充邮件首标的可选字段(multi-author-protocol)的步骤，该命令字段是“邮件确认请求”或“更新邮件”；并且其中，由回答本地邮件服务器的共同始发者的本地邮件服务器执行的所有接收步骤包括读取具有如下命令字段的邮件首标的可选字段的步骤，该命令字段是“请求更新”、“邮件确认”、“发送更新”或“取消更新”。
如权利要求10所述的方法还通过如下方式来实现本发明的目的其中，在本地邮件服务器接收共同始发邮件的步骤还包括用命令字段从本地邮件服务器读取邮件首标的可选字段的初始步骤，该命令字段是“待发送邮件”或“发送强制”，并且，如果该命令字段是“发送强制”，则发送该共同始发邮件到至少一个接收者，而无需使该共同始发邮件由所有共同始发者进行确认。
还利用一种计算机程序产品来实现本发明的目的，该计算机程序产品包括当在计算机上执行所述程序时，用于执行根据权利要求1到10中任意一项所述的方法的步骤的编程代码指令。
还利用一种系统来实现本发明的目的，该系统包括适合于执行根据权利要求1到10中任意一项所述的方法的装置。
本发明的解决方案很容易实现为安装在其为发送者的共同始发者的本地邮件服务器中的代理(proxy)，以及包含发送者的共同始发者的邮件用户应用程序的修改。利用SMTP协议，本发明的邮件服务器将包括代理和本地MTA。修改该SMTP用户代理，以便支持用于与本发明的代理连接的命令协议。使用SMTP邮件的可选字段是优选的实施例。本领域的技术人员可以选择其它的实施方式，用于在本发明的邮件服务器和本发明的共同始发者用户代理之间传送命令。
图1说明现有技术的用于分发共同始发电子邮件的SMTP模型；图2说明根据优选实施例的基于SMTP模型的用于分发共同始发电子邮件的模型；图3是根据优选实施例的用于分发共同始发电子邮件的方法的一般流程图；图4说明根据优选实施例的当未请求邮件更新时用于分发共同始发电子邮件的数据流；图5说明根据优选实施例的当请求一个邮件更新时用于分发共同始发电子邮件的数据流；图6说明根据优选实施例的当请求两个邮件更新时用于分发共同始发电子邮件的数据流；图7说明根据优选实施例的当请求两个邮件更新并且放弃一个时用于分发共同始发电子邮件的数据流；图8说明根据优选实施例的由代理邮件服务器所使用的表；图9说明根据优选实施例的在用户代理和代理邮件服务器之间定义的协议的命令；图10A和10B示出了由代理邮件服务器执行的用于截取共同始发邮件并发送该邮件进行检查的方法的详细流程图；和图10C示出了在代理邮件服务器中执行的用于处理共同始发邮件的更新请求的方法的详细流程图。
具体实施例方式
图1说明了在RFC 2822中定义的用于分发共同始发电子邮件的现有技术的SMTP模型。在用户工作站中工作的用户代理(100)充当他们各自的邮件服务器(110、120、130)——即所谓的邮件传输代理(MTA)——的客户机。用户代理A1和A2与相同的MTA(110)连接。用户代理A3和A4与它们各自的MTA(120、130)连接。这些MTA负责管理接收者用户代理邮件地址，以便向/从与其本身(A1、A2)连接的本地用户代理、或者通过因特网(150)向/从远程MTA(120、130)来传送/接收邮件。远程MTA自身向/从与它们自身连接的本地用户代理(A3和A4)传送/接收邮件。用户代理发送邮件到其本地MTA，该邮件包括数据本身和接收者名称。为了将邮件传递到本地用户代理，MTA寻找接收者的对应地址，并且将邮件放入邮件存储库，即，作为该邮件接收者的用户代理的所谓邮箱(140)。发送者和接收者名称对应于它们各自的邮箱标识符。
从用户代理A1发送共同始发邮件，用户代理A1代表共同始发者编写消息，并将其发送给接收者，即用户代理A4。该邮件包含对应于用户代理A2和A3的共同始发者的列表。消息的接收者A4将在该消息的“sender(发送者)”字段中见到用户代理A1的邮箱标识符。消息的接收者A4将在该消息的“from(来自于)”字段中见到两个共同始发者用户代理A2和A3的邮箱标识符。
图2说明了根据优选实施例的基于SMTP模型的用于分发共同始发电子邮件的模型。发送者是用户代理A1，共同始发者是A2和A3。根据优选实施例，发送者用户代理A1并不直接与它的本地MTA(110)连接。发送者用户代理与代理邮件服务器(210)连接，代理邮件服务器(210)自身充当客户机，以便与从如图1所示的现有技术SMTP协议中所述的MTA接收邮件的MTA服务器连接。在图2中，发送者的MTA和代理邮件服务器(210)构成发送者的共同始发邮件服务器(240)。根据优选实施例，修改了发送者(用户代理A1)的用户代理(250)和共同始发者用户代理(250)(用户代理A2和A3)。MTA(110、120、130)是如图1所示的现有技术SMTP模型的标准MTA。接收者用户代理是如图1所示的现有技术SMTP模型的标准用户代理(100)。安装了代理邮件服务器(210)以便连接到MTA，用于分发由连接到该MTA的用户代理(A1)发送的共同始发电子邮件。
该修改的用户代理发送邮件到它自己的邮件服务器。所述邮件被代理邮件服务器截取，代理邮件服务器代替MTA在标准邮件端口上进行读取。如果它是共同始发的邮件，则代理邮件服务器将该邮件发送到除了由“Sender”字段指示的共同始发者(他/她自己)以外的“From”字段中所指示的共同始发者，以便进行检查。为了发送邮件，代理邮件服务器(PMS)对本地MTA使用SMTP协议。本地MTA将邮件路由到掌管远程共同始发者A3的远程MTA，并且将发给本地共同始发者A2的邮件发送到该代理邮件服务器。共同始发者被要求按照原样确认该邮件，或通过请求更新来回答该PMS。然后，PMS收集由已经请求更新的共同始发者所要求的更新，并且重新发送该邮件给其他的共同始发者来进行确认(acknowledgement)。为了控制操作的顺序，当PMS发送邮件来寻求确认时，该邮件被锁定，并且接收者具有在“我确认该邮件”或“我请求更新该邮件”之间进行选择的选项。
图4到图7的详细数据流中描述了不同的情况。在图10A、10B和10C中描述了用于从PMS分发共同始发邮件的方法的详细流程图。
图3是根据优选实施例的用于分发共同始发电子邮件的方法的一般流程图。在第一步骤(300)中，该PMS已经接收到了由发送者用户代理准备好并发送到该PMS的共同始发邮件。识别出存在共同始发者列表的PMS在发送该邮件到共同始发者之前，首先处理(310)该邮件。该PMS锁定该邮件，以便接收者只能读取它。该PMS还设置答复选项，这些答复选项可以是“我确认该邮件”或“我请求更新该邮件”。该PMS还将这个处理过的邮件发送给所有的共同始发者，而不发送给发送者(由“sender”字段标识)。该邮件由MTA使用标准SMTP协议发送到共同始发者。共同始发者的SMTP用户代理已经被修改过，以支持优选实施例的方法。当他们在他们的邮箱中从PMS接收到经由MTA使用SMTP照常发送的邮件时，他们等待共同始发者的决定邮件被共同始发者确认，或者，如果共同始发者不同意该共同始发邮件的内容，则共同始发者经由用户代理向该PMS发送更新邮件的请求。该PMS接收两种可能的邮件回答。如果所有的共同始发者已经确认该消息(对测试320回答“是”)，则不作进一步修改而将邮件发送到(350)由发送者在初始的共同始发邮件中指定的最终接收者，并且完成邮件分发(360)。对于请求邮件更新的每个共同始发者，该PMS收集该更新，并且将更新的邮件重新发送给其他的共同始发者进行确认，而不发送给已经请求更新邮件的共同始发者，这个共同始发者被人为地看作是发送者(340)。
所有的更新请求由PMS按顺序进行处理，以避免数个共同始发者同时更新相同的邮件。
对于由PMS实施的共同始发消息的处理，本领域技术人员已知许多可能的实施方式。用于实现PMS与初始发送者和共同始发者的修改的用户代理之间的命令交换的优选实施例，使用邮件首标的“Optional Field(可选字段)”。某些字段是强制性的字段，例如包含所发送的消息的标识符的“Message-Id(消息Id)”。另一个强制性字段是“in-reply-to(答复)”字段。该字段由第一消息的接收者用以回答发送者。该“in-reply-to”字段包含该答复所属的邮件的消息标识。其它的字段可以被创建为可选字段。在RFC 2822的第3.6.8段(因特网消息格式)中定义了可选字段。在优选实施例中创建了可选字段“Multi-author-protocol＝msg”，其中msg可以是在PMS与修改的用户代理之间交换的命令消息。这种消息可以是由请求共同始发者批准该共同始发邮件的PMS所发送的“REQUEST_ACK(请求确认)”，或是由请求修改邮件的共同始发者所发送的“REQUEST_UPDATE(请求更新)”，或由请求共同始发者修改邮件的PMS所发送的“MAIL_TO_UPDATE(待更新邮件)”。如果共同始发者按照发送原状批准了该邮件，则一个其他消息可能是“ACK(确认)”。在收集邮件更新的过程期间将交换其他的消息，如本文后面参照图9所描述的。在优选实施例中创建了另一个可选字段，该可选字段是message-version＝“Message-Version”version。该字段是由PMS更新的，当共同始发者更新初始邮件时，PMS使用它来使共同始发者之间邮件版本同步。本文后面参照图10B和10C来描述优选实施例的邮件更新同步机制。
可选择地，一个msg消息可以是“SEND_FORCE(强制发送)”。它可以由发送者用户代理设置，以便强制PMS不处理该共同始发邮件，而将其直接发送给接收者，无需为取得其他共同始发者的确认而对其进行处理。
要注意当PMS将带有“REQUEST_ACK”的邮件发送给共同始发者时，该邮件被锁定，这可以由共同始发者的修改代理执行，使得该邮件在只读模式下对共同始发者可用。然后，如果一个共同始发者请求更新该邮件，当PMS将“MAIL_TO_UPDATE”发送给共同始发者以请求他进行修改时，该邮件被解锁，这由共同始发者的修改的用户代理来执行，使得该邮件可用于读取和写入模式。
图4说明了根据优选实施例的当没有请求邮件更新时用于分发共同始发电子邮件的数据流。用户A1(401)将规定了几个共同始发者——他自己作为发送者、用户A2(402)和用户A3(403)——的邮件发送(410)给目的地用户B1(406)。该消息被发送到包括PMS和MTA的共同始发邮件服务器(404)。PMS截取该消息。根据发送者用户A1规定的发送选项，PMS可以有两种行为—如果该发送选项规定了“无需其他共同始发者确认”，根据优选实施例(见本文前面关于图3的描述末尾)，这被实施为msg＝“SEND_FORCE”，则PMS经由共同始发者邮件服务器(404)的MTA将邮件发送到MTA传递器(405)。该MTA传递器将该消息放入用户B1(406)的邮箱。
—如果该发送选项规定了默认选项值“来自其他共同始发者的确认”，则该消息被发送到除发送者以外的所有共同始发者。
在图4的示例中，适用后面的情况，因此消息被发送(411)到用户A2(402)和被发送到(412)用户A3(403)。该邮件是在被锁定用于只读的情况下发送的。当所有的确认被接收(413和414)时，该邮件被发送到在消息中规定的所有接收者(415和416)。这些接收者由名称为“To”、“Cc”或“Bcc”的目的地地址字段标识。
图5说明了根据优选实施例的当请求一个邮件更新时用于分发共同始发电子邮件的数据流。步骤210到512相当于前面情况的步骤(图4的410到412)，其中PMS发送将要由共同始发者确认的邮件。返回到图5中，当用户A3发送确认时(514)，用户A2请求更新邮件的令牌(token)(513)。当接收到该令牌时，邮件被解锁，接着用户A2修改邮件，并使用命令(它可以被实施为msg)“send_update_mail to B1(发送更新邮件到B1)”来将其发送到PMS(516)。此刻，该PMS要记录存在邮件的新版本以及该邮件新版本被用户A2暗示地确认。本文后面参照图8描述PMS记录信息的方式。由于存在邮件的新版本，该PMS要求用户A3(517)和发送者用户A1(518)对该新版本进行确认。该PMS从用户A3(519)和用户A1(520)接收确认。在接收到这两个确认后，并且已经从用户A2接收到作为来自用户A2的确认的“send_update_mail to B1”(516)，该PMS能够通过共同始发邮件服务器(404)的本地MTA以及通过(522)远程传递器MTA(405)，将消息发送到(521)接收者(406)。
图6说明了根据优选实施例分当请求两个邮件更新时用于分发共同始发电子邮件的数据流。步骤(610)到(613)相当于第二种情况的步骤(510)到(513)。用户A3请求更新邮件的令牌(614)。由于该更新令牌已经被用户A2保留，该PMS等待该更新令牌的释放。使用命令“send_update_mail(发送更新邮件)”(616)，将由用户A2请求的修改后的邮件重新发送到PMS，此刻，PMS增加邮件的版本，并记住该版本的邮件已经由用户A2暗示地确认(616)。由于存在待处理的由用户A3请求的请求更新(614)，将邮件发送给用户A3以便进行更新(617)。修改后，该邮件被返回到PMS，PMS再次将版本号递增。当该消息已经被修改并且没有其他的“REQUEST_UPDATE”消息待处理时，该PMS请求其他共同始发者用户A2(619)和用户A1(620)进行确认。当接收到所有的确认(621)、(622)和先前作为确认的”“send_update_mail”(618)之后，该消息被发送给接收者。
图7说明了根据优选实施例的当请求两个邮件更新而放弃一个时、用于分发共同始发电子邮件的数据流。步骤(710)到(715)与第二种情况的步骤(510)到(515)相似，但接收到将要更新的邮件后(715)，用户A2(402)通过发送“Cancel_update(取消更新)”(716)给PMS来决定放弃该更新。该消息充当邮件的当前版本的确认。当PMS从所有的共同始发者接收到确认时，该邮件被发送到接收者(717)。
图8说明根据优选实施例的由代理邮件服务器使用的表。该表由PMS使用，来记录每个共同始发者对不同版本邮件的确认状态。这些表允许PMS来同步共同始发者对邮件的不同版本的确认。所述表包括一个邮件表(810)，在该邮件表中，每一共同始发邮件组成一行，该邮件由PMS接收并且由它的mail_id标识。对于每一行，指针(在邮件表(810)的“确认表”字段中)与作为子表的确认表(820)相关，在该子表中，每一共同始发者拥有一行。
每次共同始发邮件被PMS接收或发送时，该PMS更新邮件表和确认表。当接收到共同始发邮件(800)时，由PMS填充邮件表行的Mail_Id字段。当邮件已经被发送给接收者时，该行以及附属的子表(820)被删除。根据优选实施例，该共同始发邮件(800)传送接收者的名称(远程用户)、“副本”(“CC”字段)中空的接收者名称、共同始发者用户1、用户2、用户3(“From(来自)”字段)、作为初始发送者的共同始发者(“Sender(发送者)”字段)、mail_Id(“1234”)以及在字段“Multi-author-protocol”中传送的命令“MAIL_TO_SEND(待发送邮件)”。当接收到第一共同始发邮件时，PMS在邮件表的最后版本字段中写入“版本1”。该版本号随后面交换的邮件而递增。每次PMS接收到更新时，则更新版本号和发送者，作为共同始发者的发送者已经更新了该邮件。新的版本将被发送给除了发送者以外的每个共同始发者以便进行确认。当PMS发送并且接收到确认或更新请求时，它针对该mail_Id利用如下内容来填充确认表(820)确认的最后版本级别或者共同始发者发送更新请求所针对的最后版本级别，以及来自共同始发者对于该版本的回答类型，即“版本已确认”的“ack(确认)”或者“请求更新该版本”的“Update req(更新请求)”。
对于如图8的邮件表(810)中定义的值，用户2是邮件第二版本的发送者。根据该确认表(820)，此版本已经被用户2确认，并需要发送给用户1和用户3进行确认。要注意即使用户3已经请求了用于更新邮件第一版本的令牌，该PMS仍将发送邮件的最后版本(第二版本)以便进行更新，因为用户3要求对第一版本的更新最终被用户2即第二版本的发送者提出。
图9说明了根据优选实施例的在修改的用户代理和代理邮件服务器之间定义的协议的命令。这些命令可以如前所述通过在消息首标中创建新的字段来实现。有诸如message-id等由RFC 2822消息格式定义的强制字段，但也有可能创建新的字段作为RFC 2822的“可选字段”。该新字段是“Multi-author-protocol＝msg”，其中msg可能是包含选项或在PMS和修改的用户代理之间交换的命令的消息。
在图9的表的“命令”列中列出了这些命令。当将共同始发邮件发送到共同始发邮件服务器时，由发送者(“源”列)的修改的用户代理发送“MAIL_TO_SEND”。该邮件将被发送给接收者(“目的地”列)，该接收者也可能是不同类型(“To”、“Cc”、“Bcc”)的接收者的分发列表。该标识字段(该表的最后一列)包括RFC 2822中的强制字段，即用于识别所发送邮件的message-id当发送者发送初始的共同始发邮件时，在消息首标中传送该消息。
REQUEST_ACK命令(图9的表的第二行第一列)由PMS(“源”列)在发送给除了发送者以外的共同始发者(“目的地”列)的邮件首标中使用，来请求邮件确认。在包含这种REQUEST_ACK命令的邮件首标中使用其他的标识字段，它们是(该表的“标识字段”列)message-id(强制的)和作为RFC 2822的“可选字段”而创建的新字段，如本文后面在图10A、10B和10C的流程图中所描述的，该“可选字段”是“message-version(消息版本)”字段，由PMS用来同步由共同始发者进行的邮件更新。
ACK命令(图9的表的第三行第一列)由共同始发者(“源”列)在发送给PMS(“目的地”列)的邮件首标中使用，来确认先前接收的邮件。在包含这种ACK命令的邮件首标中也使用标识字段，它们是(该表的“标识字段”列)in-reply-to字段(强制的)和version-id(版本id)字段(作为“可选字段”而创建的)。当第一消息的接收者答复发送者时，使用“in-reply-to”字段。该“in-reply-to”字段包含准备该答复所针对的消息的message-id。在此，发送了ACK到PMS的共同始发者还发送被确认的message-id。
REQUEST_UPDATE命令(图9的表的第四行第一列)由共同始发者(“源”列)在发送到PMS(“目的地”列)的邮件首标中使用，来请求更新先前接收的邮件。在包含这种REQUEST_ACK命令的邮件首标中也使用标识字段，它们是(该表的“标识字段”列)in-reply-to字段(强制的)和version-id字段(作为“可选字段”而创建的)。
MAIL_TO_UPDATE命令(图9的图表的第五行第一列)由PMS(“源”列)在发送给共同始发者(“目的地”列)的邮件首标中使用，来请求邮件的更新。在包含这种MAIL_TO_UPDATE命令的邮件首标中也使用其它的标识字段，它们是(该表的“标识字段”列)message-id字段(强制的)和version-id字段(作为“可选字段”而创建的)。
SEND_UPDATE(发送更新)命令(图9的图表的第六行第一列)由共同始发者(“源”列)在邮件首标中使用，以便将邮件的更新发送给PMS(“目的地”列)。在包含这种SEND_UPDATE命令的邮件首标中也使用其它的标识字段，它们是(该表的“标识字段”列)in-reply-to字段(强制的)和version-id字段(作为“可选字段”而创建的)。
CANCEL_UPDATE(取消更新)命令(图9的表的第六行第一列)由共同始发者(“源”列)在邮件首标中使用，以便通知PMS(“目的地”列)不再要求邮件的更新。在包含这种CANCEL_UPDATE命令的邮件首标中也使用其他的标识字段，它们是(该表的“标识字段”列)in-reply-to字段(强制的)和version-id字段(作为“可选字段”而创建的)。
要注意初始发送者发送共同始发的邮件，并且PMS向该邮件的“FROM”字段中列出的共同始发者发送所述邮件以便进行确认。当共同始发者发送更新时，PMS向除了提出更新的那个共同始发者以外的所有共同始发者发送更新的邮件以便进行确认。在该优选实施例中，该共同始发者被认为是新的发送者，而初始发送者被认为是共同始发者，并且因而被请求确认邮件的新版本。
SEND_FORCE(强制发送)命令(图9的表的第七行第一列)由初始共同始发邮件的发送者(FROM列)在邮件首标中使用，以便通知PMS(TO列)该邮件即使是共同始发的也不是必须经过其他共同始发者确认。在包含这种SEND_FORCE命令的邮件首标中也使用另一个标识字段，它是(该表的“标识字段”列)message-id字段(强制的)。接收具有包含这些信息的首标的共同始发邮件的PMS会将它发送给接收者。
图10A和10B示出了由代理邮件服务器执行的用于截取共同始发邮件并将它发送以便进行检查的方法的详细流程图。在第一步骤(1000)中，PMS是空闲的，并且共同始发邮件服务器准备接收邮件。在第二步骤中，PMS接收由本地发送者发送的共同始发邮件。在该优选实施例中，邮件首标将包含“MAIL-TO-SEND”命令和字段标识符，这些字段标识符是message id字段(图10A示例中的X)和version id字段(为1，因为它是初始邮件)。在随后的步骤(1020)中，PMS用关于由其Mailid(又称message-id)标识的接收邮件的信息来更新邮件表。该邮件版本是第一版本，“version 1”。由PMS在该共同始发邮件的处理期间发送的邮件总是在首标中包括Mail id和version id。PMS向在初始邮件中发现的除了发送者以外的共同始发者发送(1030)要求确认的邮件。因此，在随后的步骤(1040)中，共同始发邮件服务器和PMS等待来自共同始发者的确认。参照图10B描述了共同始发者进行确认的过程。PMS等待确认(1040)。
如果PMS接收到来自共同始发者(1070)的确认。该共同始发者在确认邮件的首标中指示了mail id和版本。如果版本不是(对测试1075回答“否”)当前版本(邮件表中与该mail id相关的字段“最后版本”)，则确认被忽略。如果由PMS接收的确认适用于当前版本(对测试1075回答“是”)，则PMS通过针对对应用户id用“确认”来更新(1080)确认表的“状态”字段来处理该确认，该对应用户id是已经发送确认的共同始发者的id。如果没有接收到所有的确认(对测试1085回答“否”)，则PMS等待下一个确认(1040)。如果已经从所有所询问的共同始发者接收到了确认(对测试1085回答“是”)，则PMS能够发送确认的邮件给接收者(1090)，并且完成共同始发邮件的分发(1095)。
如果PMS从共同始发者接收到(1055)更新请求，则PMS发送(1060)需要更新的邮件到该请求的共同始发者，并且等待(1065)来自该共同始发者的邮件更新。在图10C步骤中追踪该过程。
图10C示出了在代理邮件服务器中执行的用于处理共同始发邮件的更新请求的方法的详细流程图。在第一步骤(1065)，PMS等待来自共同始发者的邮件更新。如果共同始发者发送了邮件更新(1100)，则PMS通过将最后版本字段递增到Y+1以及针对发送了邮件更新的共同始发者(共同始发者N)更新对应的确认表中的“状态”字段，来更新(1105)邮件表。如果还有针对一个共同始发者的更新请求待处理(对测试1110回答“是”)，该共同始发者是由PMS通过读取确认表中的一个共同始发者(用户m)的“状态”字段而识别出的，则PMS发送更新请求(1115)给该共同始发者，而且伴随着最后版本Y+1。然后，PMS等待邮件更新(1065)。如果不再有待处理的更新请求(对测试1110回答“否”)，则PMS向除了最后更新了该邮件的共同始发者以外的所有共同始发者发送邮件的最后版本(版本Y+1)以便进行确认。
如果共同始发者发送“Cancel update”(1130)，则PMS通过把对应的共同始发者的状态字段从“更新请求”改变为“确认”，来更新(1135)该确认表。如果PMS在确认表中见到所有的共同始发者已经确认(对测试1140回答“是”)，则它发送(1145)邮件的最后版本给接收者，并且完成(1150)分发共同始发邮件的过程。
要注意在提交到PMS的邮件更新中，一个共同始发者可以改变初始的共同始发邮件中的接收者。这就是为什么在该优选实施例中，当PMS发送共同始发邮件的最后版本时，它将其发送给在该最后版本中指示的接收者。
如果当PMS正在等待(1065)更新时，它从共同始发者N接收到更新请求(1155)，则它通过在对应于该共同始发者(共同始发者N)的表行中的状态字段中添加“更新请求”来更新确认表，并等待更新(1065)。PMS不立即回答更新请求，因为它已经正在等待更新，而一旦它接收到它正在等待的更新，将在新邮件版本的基础上处理待处理的更新请求。
如果PMS从共同始发者N接收到“确认”(1165)，并且如果该确认适用于(对测试1170回答“是”)当前版本(邮件表中的“最后版本”)，则它通过在对应于该共同始发者(共同始发者N)的表行的状态字段中添加“确认”来更新确认表，并等待更新(1065)。如果接收(1165)的确认不适用于(对测试1170回答“否”)当前版本(邮件表中的“最后版本”)，则PMS等待下一个更新(1065)，因为所有的共同始发者必须都批准邮件版本的最后级别。
权利要求
1.一种用于分发由一个始发者即发送者发送给至少一个接收者的共同始发邮件的方法，所述邮件具有多于一个始发者即共同始发者，并且被从执行客户邮件应用程序的工作站上发送，所述客户邮件应用程序与通过网络与其他的邮件服务器通信的本地邮件服务器连接，所述方法包括下列步骤a-在本地邮件服务器接收(1010)共同始发邮件；b-本地邮件服务器发送(1030)该邮件到共同始发者，但不发送到发送者，并且要求邮件确认；c-如果本地邮件服务器从所有的共同始发者接收回(1085-是、1140-是)邮件确认，则从本地邮件服务器将确认的邮件发送给至少一个接收者；d-如果本地邮件服务器从第一共同始发者接收回(1055)邮件更新请求，则本地邮件服务器从成为发送者的第一共同始发者收集(1060、1100)更新的邮件，该更新的邮件成为将要确认的新邮件；并且，从本地邮件服务器重复步骤b-、c-和d-，直到一个邮件已经被所有的共同始发者确认并且被发送给至少一个接收者为止。
2.如权利要求1所述的方法，其中，步骤d-还包括下列步骤如果本地邮件服务器在还没有完成对来自第一共同始发者的更新邮件的收集步骤时，从一个第二共同始发者接收到(1155)邮件更新请求，则本地邮件服务器在完成对第一共同始发者的收集步骤后，执行第二个收集步骤，以便从第二共同始发者获得二次更新的邮件。执行重复步骤，所述第二共同始发者成为发送者，并且二次更新的邮件成为针对重复步骤将要确认的新邮件。
3.如权利要求2所述的方法，还包括下列步骤如果本地邮件服务器在还没有完成对来自第一共同始发者的更新邮件的收集步骤时，从至少一个共同始发者中的第二个接收到关于将要更新的邮件的邮件确认(1165)，则本地邮件服务器完成对第一共同始发者的收集步骤，所述第一共同始发者成为重复步骤的发送者，并且更新的邮件成为将要确认的新邮件。
4.如权利要2或3所述的方法，还包括下列步骤如果本地邮件服务器在还没有完成对来自第一共同始发者的更新邮件的收集步骤时，从第一始发者接收到(1130)取消更新请求，则本地邮件服务器将认为第一共同始发者已经确认该邮件并且执行步骤c。
5.如权利要求1到4中任意一项所述的方法，其中，收集步骤包括下列步骤从本地邮件服务器发送更新邮件的请求(1115)到已经发送回邮件更新请求的共同始发者；从第一共同始发者接收(1100)更新的邮件。
6.如权利要求1到5中任意一项所述的方法，其中，每次本地邮件服务器接收到共同始发邮件时，本地邮件服务器在邮件表(810、820)中建立条目，该条目标识该邮件、初始的邮件发送者、邮件版本号以及邮件的共同始发者列表，其中邮件版本号是最后的邮件版本号；每次由本地邮件服务器从共同始发者接收到更新的邮件时，本地邮件服务器将表中的版本号递增，作为对应邮件的最后版本号；每次由本地邮件服务器从共同始发者接收到邮件确认或取消更新时，本地邮件服务器针对对应邮件、共同始发者和版本号，在表中存储邮件确认的状态；每次在接收更新的邮件之前接收到邮件更新请求时，本地邮件服务器针对对应邮件、共同始发者和版本号，在表中存储该更新请求的状态。
7.如权利要求1到6中任意一项所述的方法，其中，由本地邮件服务器测试是否所有的共同始发者都已经发送回邮件确认的步骤还包括下列步骤在表中读取对应于该邮件的所有共同始发者的状态是否是邮件确认。
8.如权利要求1到7中任意一项所述的方法，其中，在从始发者接收更新邮件的每个步骤之后，执行下列步骤如果在邮件表中针对该邮件的更新请求的状态与第二共同始发者相关，则执行对来自第二共同始发者的二次更新邮件的收集步骤。
9.如权利要求1到8的任意一项所述的方法，其中，本地邮件服务器的接收和发送的步骤包含使用SMTP协议来传送邮件的步骤；并且其中，除了到至少一个接收者的发送步骤以外，由本地邮件服务器执行的发送步骤还包括用命令字段来填充邮件首标的可选字段(multi_author_protocol)的步骤，该命令字段是“请求邮件确认”或“更新邮件”；并且其中，由回答本地邮件服务器的共同始发者的本地邮件服务器执行的所有接收步骤包括读取具有如下命令字段的邮件首标的可选字段的步骤，该命令字段是“请求更新”、“邮件确认”、“发送更新”或“取消更新”。
10.如权利要求9所述的方法，其中，在本地邮件服务器接收共同始发邮件的步骤还包括从本地邮件服务器读取具有如下命令字段的邮件首标的可选字段的初始步骤，该命令字段是“待发送邮件”或“强制发送”，并且，如果该命令字段是“强制发送”，则在无需由所有共同始发者确认共同始发邮件的情况下，将该共同始发邮件发送给至少一个接收者。
11.一种计算机程序产品，包括当在计算机上执行所述程序时，用于执行根据权利要求1到10中任意一项的方法的步骤的编程代码指令。
12.一种系统，包括适合于执行根据权利要求1到10中任意一项的方法的装置。
全文摘要
一种用于分发由一个始发者发送给至少一个接收者的共同始发邮件的方法和系统，该邮件具有共同始发者并且是从执行客户邮件应用程序的工作站发送的，该客户邮件应用程序与通过网络与其他邮件服务器通信的本地邮件服务器连接，该方法包括在本地邮件服务器接收共同始发邮件；本地邮件服务器将该邮件发送到共同始发者并且要求邮件确认；如果本地邮件服务器从所有共同始发者接收到邮件确认，则发送确认的邮件到至少一个接收者；如果本地邮件服务器从第一共同始发者接收到邮件更新请求，则从第一共同始发者收集更新的邮件，即将要确认的新邮件；以及重复上述步骤直到一个邮件被所有的共同始发者确认并且被发送到至少一个接收者为止。
文档编号H04L29/06GK1708046SQ20051006520
公开日2005年12月14日 申请日期2005年4月14日 优先权日2004年6月11日
发明者杰勒德·马米格尔, 乔奎恩·皮肯, 弗雷德里克·鲍乔特 申请人:国际商业机器公司