分发电子邮件附件的方法和服务器

暂无

技术领域
本发明一般的涉及计算机网络中的信息传递。更具体的，本发 明涉及将MIME多用途网际邮件扩展和其它电子邮件的附件从邮件中 移出并将这些附件邮送至目标电子邮件收件人可以访问的地址的技 术。
背景技术
电子邮件已成为整个商业界乃至公众的通讯方法。在典型的企 业环境里，邮件服务器(例如UNIX SendMail)具有本地的传递代理， 将传入的电子邮件存储在本地文件系统(典型的在UNIX系统中 为.../bin/mail)，并通过POP、IMAP或命令行程序传递给终端用户。 这样的代理只提供登录电子邮件消息和将信息复制到用户机的邮件 输入输出子系统的功能。
典型的电子邮件消息常常包括大的二进制文件形式的附件，往 往是MIME格式，例如声音或电影剪辑。这些大的电子邮件附件经常 给邮件服务器上接收带来很多困难。因此，例如说，如果将电子邮 件发给大量的收件人，本地传递代理仅仅是在每个收件人的邮箱中 装入一份复制文件。这种方法消耗大量的存储空间，造成浪费并给 文件系统带来沉重的负担。
Kuzma中的美国专利NO.5781901试图解决这个问题。在这个专 利中，电子邮件附件不是传递给指定的收件人。而是希望传送电子 邮件的发件人将附件送到相关地址的万维网服务器。附件包括唯一 的网络地址。发件人要求来自收件人的选项，收件人应发件人的请 求，提供可配置的电子邮件网页。然后，发送一个消息和在发送给 接收人基于HTML的网页中的URL指针指向唯一的网络地址。收件人 可以在URL的导引下取回附件。
尽管Kuzma中描述的技术避免了传送和存储多个邮件附件，有 一些缺点。首先，必须有专用服务器以存储附件，而且这一服务器 必须位于与发送人相近的位置，以避免存储文件时不必要网络通信 量。另外，这项技术要求发件人必须首先通过浏览器浏览收件人的 一个主页或其它万维网站点，选择在收件人的主页中必须提供的“发 送邮件”选项。如果收件人没有提供这一服务，在kuzma中描述的 引用附件电子邮件系统不能实施。还有，为了利用Kuzma系统，发 件人必须有意选择利用这些功能。因此，这使技术不能以对发件人 透明的方式实现，这是其不足之处。
在现有技术上仍需要提供在现有的基于SMTP的客户服务器配置 基础上实现的接收，能避免存储多份电子邮件文件附件。本发明解 决这个问题。
发明内容
根据本发明的一个方面，提供一种分发电子邮件附件的方法， 包括步骤：
响应向一个或多个收件人发送电子邮件的要求，分析电子邮件 附件；
如果电子邮件包括附件，移动附件并将其存贮在特定的可访问 的地址；
在电子邮件中，用引用代替附件，生成修改的电子邮件；
将修改的电子邮件发送一个或多个收件人；和
响应修改的电子邮件提供的收件人使用引用要求，将附件提供 给收件人。
根据本发明的另一个方面，提供一种分发电子邮件附件的方法， 包括步骤：
响应向一个或多个收件人发送电子邮件的要求，分析电子邮件 附件；
如果电子邮件包括附件，判断附件是否满足给定的判据；
如果附件满足给定判据，移动附件并将其存贮在特定的可访问 的地址；
在电子邮件中，用引用代替附件，生成修改的电子邮件；和
将修改的电子邮件发送给一个或多收件人。
根据本发明的另一个方面，提供一种分发电子邮件附件的服务 器，包括
处理器；
具有特定可访问地址的存贮器；
电子邮件分发应用程序，包括：
响应向一个或多个收件人发送电子邮件的请求，分析电子邮件 附件的装置；
移动附件并存贮在给定可访问地址的装置；
用引用代替附件生成修改电子邮件的装置；
向一个或多个收件人发送修改的电子邮件的装置；和
响应收件人使用修改的电子邮件提供的引用的请求，将附件提 供给收件人的装置。
根据本发明的另一个方面，提供一种分发电子邮件附件的方法， 包括步骤：
响应向一个或多个收件人发送电子邮件的要求，分析电子邮件 附件；
如果电子邮件包括附件，移动附件；
压缩附件并将压缩了的附件存贮在特定的可访问的地址；
在电子邮件中，用链接代替附件，生成修改的电子邮件；和
将修改的电子邮件发送给一个或多收件人。
根据本发明的另一个方面，提供一种将电子邮件附件从发件人 传送给一个或多个收件人的方法，包括步骤：
在电子邮件服务器，响应有附件的电子邮件的接收，移动附件；
将附件存贮在给定的URL；和
将没有附件的电子邮件，连同识别URL的链接以及提示收件人 附件可以通过选择链接取回到的信息一起传送给一个或多个收件 人。
根据本发明，扫描电子邮件消息的MIME或其它形式的文件附件。 这样的附件选择性地从信息剥离出来，存储在可访问的地址。如果 必要，附件在存储前可以先压缩。附件的引用(例如链接)和地址 随后在原电子邮件被替换，之后转发给指定收件人。当收件人希望 获取附件时，他或她最好是从浏览器或其它着色引擎选择引用。附 件就解压(如果必要的话)，提供给收件人。
因此，当一份具有大文件附件的电子邮件传递给企业内(或外) 的多个收件人时，最好是在可访问的地址只保留一份附件的复制品， 当同样的附件发送给多个用户时，这项技术显著地减少了文件系统 的存储要求。
最好是，用管理员控制的策略来判定是否存储所给定的附件。 因此，举例来说，策略可能决定于具有文件附件的信息的收件人的 数量、文件附件的大小、文件附件的MIME格式、某些形式附件的特 定选择、附件主题引用中识别的关键词、附件主题或其它策略。如 果必要，策略可在每一用户或用户组基础上定制。
在一个优选的实施方案中，本发明的方法作为计算机程序，例 如作为一个网络邮件传递代理，在邮件服务器中执行。这一功能可 能是单独的传递代理，也可以添加到现有的服务器程序中。
前面简述了本发明多个相关目的和特点的一部分。这些目的仅 仅可以看作是本发明多个卓越特点和应用的部分解释。用不同的方 式应用公开的发明或修改将要描述的本发明，可以得到更多其它有 益的结果。因此，参考随后的优选实施方案的详细描述，可以得到 其它目的和更完整地理解本发明。
附图说明
为了更完整地理解本发明及其优越性，参考下面附图的详细描 述，其中：
图1是一个实现本发明的示意性基于SMTP的客户服务器系统；
图2是本发明的网络邮件传递代理程序的基本操作过程框图；
图3是发明的传递代理的基本操作的流程图；
图4是传递代理处理前的电子邮件示意图；
图5是图4的电邮件经过传递代理移动和存储邮件附件后的示 意图；
图6是本发明优选策略例程的流程图；
图7是一个有代表性的用户界面，通过它管理员可以根据本发 明定义存储策略；和
图8是当特定的收件人希望取回存储的附件时所实施的例程流 程图。
具体实施方式
已知的客户-服务器系统如图1所示。在该系统中，一套客户机 10a-10n连在企业环境内的网络防火墙12之后。每一个客户机具有 通过网络16用已知的方式连接到一套万维网服务器14a-14n能力。 网络16一般包括控制域名分辩，路由和其它控制功能的其它服务器。 网络16是因特网，内部网或任何其它已知网络。因此，每一个客户 机一般包括一套程序，使客户机用户能够得到已知的网络服务，包 括：一对一的信息传递(电子邮件)，一对多的信息传递(布告牌)， 文件传递和万维网浏览。因此，防火墙12外的客户机18的用户可 以和防火墙内的用户10通讯。一台典型客户机在包括简单邮件传输 协议(SMTP)电子邮件客户机18，诸如Lotus Notes，微软Outlook 等。电子邮件客户机10与邮件服务器以已知的方式协作。有代表性 的邮件服务器20是UNIX SendMail，它包括本地邮件传递代理，将 传入的电子邮件存储在本地文件系统22，并将其传送给终端用户(例 如通过POP、IMAP或命令行程序)。在因特网模型中，资源(例如 服务器)的网络路径是由所谓统一资源位置(URL)来识别的。
典型的邮件服务器20是一台IBM企业网络服务器，它包括基于 RISC的处理器22，AIXO操作系统24及邮件服务器程序26。正如前 面提到过的，邮件服务器程序是一个本地邮件传递代理。服务器20 可能包括应用编程接口(API)28提供扩展，使应用程序开发者通过 包括插件、服务小程序(servlet)等的软件程序能够扩展和/或用 户化核心功能。
有代表性的客户机是一台个人计算机，笔记本计算机，网络装 置或流行的计算装置(例如PDA或掌上电脑)，它们是基于X86-、 Powrpc-或RISC的。客户机包括诸如IBM、OS/2、微软Windows、 Windows CE or PalmOS的操作系统。正如前面提到过的，客户机包 括一套网络工具包括万维网浏览器，例如Netscape Navigator或微 软Internet Explor，具有Java虚拟机和支持应用插件和帮助应用 程序。客户机还包括电子邮件客户程序诸如Lotus Notes、微软 Outlook等，用来管理电子邮件通信。正如将看到的，利用本发明时 现有的电子邮件客户机，无须修改。
正如前面的简要介绍过的，本发明提供了一种新颖的网络邮件 传递代理，它移动和存储MIME型及其它附件，避免了邮给一组指定 用户的附件的多次存储。在示例的实施方案中，网络传递代理是一 套代替了传统的邮件服务器传递代理(例如UNIX/bin/mail)的单 独程序。在一个具体的实施方案中，发明的代理以在服务器上运行 的服务小程序实现。可供选择地，发明的传递代理可以作为现有邮 件服务器的附件，例如单独的插件执行。当然，可以使用任何方便 的执行方法。
图2解释了本发明的网络邮件传递代理的主要功能组件。代理 包括第一过程32，监视传入的电子邮件附件。第二过程34根据给定 策略分析文件附件，剥离满足给定判据的附件。因此，例如，一个 判据是具有给定的大小或给定的MIME形式。第二过程34也将控制 移动的文件附件存储在可访问的存储器35中的特定地址内。尽管并 否意味道着限制，存储器35可以是一个相关数据库支持存储的目录。 存储器35也可以是万维网服务器。代理30还包括第三过程36，将 对象引用，例如标识URL的链接、包括文件附件缩略图的图形链接 等替换入电子邮件，最好在删除的附件的位置。第三过程36也可以 插入指导用户取回存储的文件附件的信息。第四过程38，将修改的 包括URL信息的电子邮件传送给原收件人。第五过程40，响应URL 选择取回存储的文件附件并提供给收件人。这些过程可以是连续的， 也可以是不连续。最好支持在计算机也就是邮件服务器的随机存储 器中。
作为有代表性的实施方案，每一过程是一套指令集结合起来构 成计算机程序。这些程序，例如可以在Java中作为在处理器中运行 给定操作系统的可执行的服务小程序执行。可执行的程序也可以用 本机代码编写。如熟知的，Java服务小程序包括在Java虚拟机(JVM) 中可执行的类文件。它由服务小程序管理器管理。必要时，服务小 程序管理器产生新的服务线程，因此，产生新的服务小程序实例。 每一服务小程序一般包括3个基本例程：init()例程、destroy()例 程和service()例程。Init()例程提供初始化功能。这些功能使服务 小程序能够被服务小程序管理器及其它服务功能识别和管理。 Destroy()例程是不规则的操作，它选择性破坏服务小程序。Service() 例程提供服务小程序的基本操作功能。这一操作将在图3的流程图 中描述。
例程从步骤50开始，服务小程序管理器检查电子邮件的接收。 如果邮件已经收到，例程转移到52步产生一个服务小程序过程实例。 此后，在步骤54，实例执行测试判断电子邮件是否有文件附件。如 果没有，在步骤56服务小程序记录收到的电子邮件，并在步骤58 将电子邮件转发给指定收件人的电子邮件客户机。这是传统的电子 邮件处理过程。但是，如果电子邮件有附件，服务小程序就转移到 步骤60测试是否所有附件都处理了。如果是，例程返回。如果步骤 60的测试结果为“否”，服务小程序实例在步骤62处理下一附件。 在步骤64，执行测试判断附件是否满足具有判据的给定策略。正如 将看到的，策略由管理员定义以决定文件附件是否根据本发明存储。 如果步骤64测试的结果表明文件附件不满足给定的判据，控制返回 步骤60测试其余附件。但是如果步骤64的结果为“是”，服务小 程序实例将用下面的方式处理附件。
在步骤66，服务小程序实例从电子邮件剥离，或换句话说是移 去附件。在步骤68，服务小程序压缩附件。步骤68是可选的。在步 骤70，压缩的附件存储在文件空间内的特定的可访问地址内。例程 继续至步骤72。这样，例如，在步骤72服务小程序将移动的附件用 给定可访问位置的引用来替代。在优选的实施方案中，链接是电子 邮件收件人可访问的存储附件的本地文件系统超文本传输协议 (http)或文件传输协议(ftp)的引用。图4图示了具有附件的电 子邮件消息，以及图5图示了没有附件，在链接中包括替代的引用， 例如http：//servernamelocalachive.0434807.doc的电子邮件消 息。如图示，这个对象引用在消息(即：点击链接可以取回你的附 件)中识别，指导目标收件人获取删除的附件。可供选择的对象引 用可能仅是链接，包括附件缩略图的图形链接或其它方便的文本、 图形或其它对象引用。
之后服务小程序例程继续，在步骤74将修改的电子邮件(即删 除了附件的电子邮件)提供给指定的收件人。这样，在步骤74，修 改的电子邮件被记录并复制到指定收件人的客户机邮件输入输出子 系统。之后，控制返回步骤60。当给定的电子邮件消息的所有附件 都以这种方式处理后，主程序循环结束。在步骤76，服务小程序实 例关闭。
图6是一流程图，图示了管理策略应用于判断文件附件是否满 足给定的存储判据。这是图3的流程图中的步骤64。根据本发明， 要测试一条或多条不同的判据。例程从步骤80开始测试是否为指定 收件人(或一组收件人，因为指定收件人是符合要求的成员)定义 了特定策略。如果是，例程在步骤82继续取回用户指定的(或用户 小组指定的)策略。例程在步骤84继续。如果步骤80的测试结果 为“否”也会进行这一步骤。在步骤84，例程测试是否策略定义的 所有判据都被测试了。如果是，例程返回。如果不是，例程在步骤86 继续处理下一条判据。在步骤88进行测试判断文件附件是否满足判 据。这样，给定的判据可以是附件有一定的大小、有一定的MIME格 式等。如果步骤88的测试结果为“是”，正如前面已经定义的，例 程继续，从信息剥离附件。这是步骤90。但是，如果文件附件不满 足给定判据，例程返回四步骤84去获取策略中的下一判据。过程结 束。
图7图示3一个简化的用户界面，根据本发明管理员可以用它 来生成电子邮件文件附件存储策略。这个界面仅仅是图示。它包括 一些选择的判断特定文件附件是否被删除的控制。这样，例如说， 一条判据是文件附件比给定的容量大。通过检测单选按钮91和在栏 94中输入文件大小来选择这一控制。另一条判据是与信息相关的附 件传送给比给定数量更多的收件人。通过检测单选按钮95和在栏97 输入收件人数目来选择这项控制。还有另一条判据是信息附件中具 有主题中的给定关键词。通过检测收单选按钮99和在栏101中输入 关键词来选择这项控制。还有一条判据是消息附件有给定的MIME格 式(例如X-图象/gif)。通过选择单选按钮103和从列表105中选 择MIME格式来选择这一控制。图7中的用户界面还包括面板107， 以识别用户指定的或用户组指定的选择判据。这样，例如说，发给 某用户或用户类型的附件可以被指定存储，而不用考虑附件的特点。
本领域的一名普通技术人员会懂得一套判据可以通过选择性的 组合(例如用布尔操作或一组操作)，提供更好的存储处理控制。 这样，例如，管理员可以决定，只有文件附件大于给定大小(例如1Mb) 以及收件人数量大于给定值(例如10个用户)时才可以存储。另一 个例子，管理员可以决定，只有具有给定大小以及发送给特定范围 的用户的附件才可以存储。给定的判据还可以是附件有特定的发送 优先权。当然，实际的策略为适合特定的系统环境是大不相同的。
图8图示了目标收件人取回存储的附件的优选例程。例程从步 骤100开始，当电子邮件收件人的电子邮件客户机打开时提供电子 邮件。在步骤102，执行测试判断用户是否希望取回以前删除的存储 文件附件。正如前面提到过的，指导用户如何取回附件的信息可以 与文件空间中附件的访问地址一起装入电子邮件。如果步骤102的 检测结果为“否”，例程循环。但是，如果用户选择了引用，例如 激活链接，在步骤104例程继续取回文件附件。在步骤106执行测 试判断文件附件是否是以压缩方式存储的。如果是，例程在步骤108采 用特定的解压例程去获取原附件。在步骤110，如果步骤106的检测 结果为“否”也会执行这一步骤，将文件附件提供给目标收件人， 目标收件人用本地资源打开附件。过程结束。
尽管本发明的上述解释是在控制一套邮件服务器电子邮件客户 机的环境中进行的，但这并不是本发明的限制。本发明的功能可以 象在典型系统中一样，在任何网络中实施以及不限制在防火墙后使 用。
本领域的普通技术人员都会懂得本发明在现有技术基础上提供 了很多优点。当一份具有附件的电子邮件要传送给多个用户时，本 发明技术只要求复制一份附件。对大型电子邮件附件而言，这一功 能显著减少了存储的要求。而且，本发明技术为传送的文件附件提 供了易于取回的有效方法。还有，如果文件附件被频繁修改，这种 修改可以传送到相同的唯一网络地址。使用包括在原修改电子邮件 中的相同的URL，用户可以得到附件的新版本。当用户选择了URL(它 可能与旧电子邮件中的URL一样)，就可以得到附件的新版本。
在另一种变化中，可以希望附件存储在中央存储器并限制特定 用户访问。在这种情况下，部分(或可能是全部)文件附件从传入 的邮件中移去，有选择地授权部分收件人取回(例如，通过访问控 制列表)发给他们的附件。
正如上面提到过的，附件存储前是可以压缩的。如果是这样， 在提供给指定收件人前使用权应解压例程解压压缩的附件。本领域 的普通技术人员会懂得特殊的压缩和解压例程最好是互补的。本发 明没有要求规定任何特殊形式的压缩或解压例程。
如上面所提到过的，上面描述的功能最好是在处理器中可执行 的软件中实施，即作为一套代码模块中的指令集(程序码)驻留在 计算机随机存储器。计算机发出要求以前，这套指令可以存储在其 它计算机存储器中，例如，硬盘驱动器或可移动存储器诸如光盘(最 终用于CD ROM)或软盘(最终用于软盘驱动器)或通过因特网或其 它计算机网络下载。
另外，尽管通过软件的重新配置或选择性地执行通用计算机， 上面描述的各种方法可以方便地实施基本目标，但本领域的普通技 术人员也可以认识到这一方法可以在硬件、固化件或其它为执行要 求方法步骤所构造的专用设备中实施。
还有，这里用到的万维网“客户机”可以广义的解释为一种任 何计算机或其部件直接或间接连接的、或以任何已知的或最近发展 起来的方式可连接到计算网络如因特网的装置。术语万维网“服务 器”也可以广义的解释为一种装置：计算机、计算器平台、计算机 或计算机平台的附件，或任何它们的组件。当然，“客户机”可以 广义的解释为要求或获取文件的装置，“服务器”就是下载文件的 机构。
已知描述了我们的发明，我们所声明的新的和通过中请专利希 望得到保护的内容，将在随后的权利要求中陈述。