Disclosure of Invention
According to one aspect of the present invention, there is provided a method of distributing email attachments, comprising the steps of:
analyzing email attachments in response to a request to send an email to one or more recipients;
if the e-mail includes an attachment, moving the attachment and storing it at a particular accessible address;
in the e-mail, replacing the attachment with the reference to generate a modified e-mail;
sending the modified email to one or more recipients; and
the attachment is provided to the recipient in response to the recipient usage quote provided by the modified email.
According to another aspect of the present invention, there is provided a method of distributing email attachments, comprising the steps of:
analyzing email attachments in response to a request to send an email to one or more recipients;
if the e-mail comprises the attachment, judging whether the attachment meets the given criterion;
if the accessory meets the given criteria, moving the accessory and storing it at a particular accessible address;
in the e-mail, replacing the attachment with the reference to generate a modified e-mail; and
the modified email is sent to one or more recipients.
According to another aspect of the invention, there is provided a server for distributing e-mail attachments, comprising
A processor;
a memory having a particular accessible address;
an email distribution application comprising:
means for analyzing an email attachment in response to a request to send an email to one or more recipients;
means for moving the accessory and storing it at a given accessible address;
means for generating a modified email with the reference in place of the attachment;
means for sending the modified email to one or more recipients; and
the attachment is provided to the recipient's device in response to a request by the recipient to use the reference provided by the modified email.
According to another aspect of the present invention, there is provided a method of distributing email attachments, comprising the steps of:
analyzing email attachments in response to a request to send an email to one or more recipients;
if the e-mail includes an attachment, moving the attachment;
compressing the attachment and storing the compressed attachment at a particular accessible address;
in the E-mail, replacing the attachment with the link to generate a modified E-mail; and
the modified email is sent to one or more recipients.
According to another aspect of the present invention, there is provided a method of transmitting an email attachment from a sender to one or more recipients, comprising the steps of:
at an email server, in response to receipt of an email with an attachment, moving the attachment;
storing the attachment at a given URL; and
an e-mail without an attachment is delivered to one or more recipients, along with a link identifying the URL and information prompting the recipient that the attachment can be retrieved by selecting the link.
According to the present invention, an e-mail message is scanned for MIME or other forms of file attachments. Such attachments are selectively stripped from the information and stored at an accessible address. If necessary, the attachment may be compressed prior to storage. The reference (e.g., link) and address of the attachment are then replaced in the original email before being forwarded to the intended recipient. When the recipient wishes to obtain an attachment, he or she preferably selects a reference from a browser or other rendering engine. The attachment decompresses (if necessary) and is provided to the recipient.
Thus, when an email with a large file attachment is delivered to multiple recipients within (or outside) an enterprise, it is desirable to keep only one copy of the attachment at an accessible address, and this technique significantly reduces the storage requirements of the file system when the same attachment is sent to multiple users.
Preferably, an administrator-controlled policy is used to determine whether to store a given attachment. Thus, for example, the policy may be dependent on the number of recipients having information for the file attachment, the size of the file attachment, the MIME format of the file attachment, the particular choice of certain forms of attachment, keywords identified in the attachment topic reference, the attachment topic, or other policies. Policies may be customized on a per-user or user group basis, if necessary.
In a preferred embodiment, the method of the invention is implemented in a mail server as a computer program, for example as a network mail transfer agent. This functionality may be a separate transfer agent or may be added to an existing server program.
The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects are to be construed as merely illustrative of some of the many advantageous features and applications of the present invention. Still other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a more complete understanding of the present invention may be had by reference to the following detailed description of the preferred embodiments.
Detailed Description
A known client-server system is shown in fig. 1. In this system, a suite of clients 10a-10n are connected behind a network firewall 12 within an enterprise environment. Each client has the capability to connect to a set of web servers 14a-14n via network 16 in a known manner. Network 16 typically includes other servers that control domain name resolution, routing, and other control functions. The network 16 is the internet, an intranet, or any other known network. Thus, each client typically includes a suite of programs that enable a client user to obtain known network services, including: one-to-one messaging (email), one-to-many messaging (bulletin board), file delivery, and web browsing. Thus, a user of client 18 outside firewall 12 may communicate with user 10 inside the firewall. One exemplary client includes a Simple Mail Transfer Protocol (SMTP) email client 18, such as Lotus Notes, microsoft Outlook, etc. The email client 10 cooperates with the mail server in a known manner. A representative mail server 20 is UNIX SendMail, which includes a local mail delivery agent that stores incoming e-mail at a local file system 22 and delivers it to end users (e.g., via POP, IMAP, or command line programs). In the internet model, the network path of a resource (e.g., a server) is identified by a so-called Uniform Resource Location (URL).
The exemplary mail server 20 is an IBM enterprise network server that includes a RISC-based processor 22, an AIXO operating system 24 and a mail server program 26. As mentioned previously, the mail server program is a local mail transfer agent. The server 20 may include an Application Programming Interface (API)28 to provide extensions to enable application developers to extend and/or customize core functionality via software programs including plug-ins, servlets (servlets), and the like.
A representative client is a personal computer, notebook computer, network appliance or popular computing device (e.g., PDA or palmtop) that is X86-, Powrpc-or RISC-based. The client machine includes an operating system such as IBM, OS/2, Microsoft Windows, Windows CE or PalmOS. As previously mentioned, the client machine comprises a set of web tools including a web browser, such as Netscape Navigator or Microsoft Internet Explor, with a Java virtual machine and supporting application plug-ins and help applications. The client also includes an email client program, such as Lotus Notes, Microsoft Outlook, etc., for managing email communications. As will be seen, existing email clients do not need to be modified when utilizing the present invention.
As briefly described above, the present invention provides a novel network mail delivery agent that moves and stores MIME types and other attachments, avoiding multiple storage of attachments mailed to a group of designated users. In the illustrated embodiment, the network delivery agent is a separate program that replaces a conventional mail server delivery agent (e.g., UNIX/bin/mail). In a specific embodiment, the inventive proxy is implemented as a servlet running on a server. Alternatively, the inventive delivery agent may be implemented as an attachment to an existing mail server, such as a separate plug-in. Of course, any convenient implementation may be used.
Fig. 2 illustrates the main functional components of the network mail transfer agent of the present invention. The agent includes a first process 32 that monitors incoming e-mail attachments. The second process 34 parses the file attachment according to a given policy, stripping attachments that meet a given criterion. Thus, for example, one criterion is to have a given size or a given MIME form. The second process 34 also stores the file attachment that controls the move in a specific address in the accessible memory 35. Although not meant to be limiting, the memory 35 may be a directory of relational database support stores. The storage 35 may also be a web server. The proxy 30 also includes a third process 36 for replacing an object reference, such as a link identifying a URL, a graphical link including a thumbnail of a file attachment, etc., into the email, preferably at the location of the deleted attachment. The third process 36 may also insert information that directs the user to retrieve stored file attachments. The fourth process 38 delivers the modified email including the URL information to the original recipient. A fifth process 40 retrieves and provides the stored file attachment to the recipient in response to the URL selection. These processes may be continuous or discontinuous. Preferably in the random access memory of the computer, i.e. the mail server.
As a representative embodiment, each process is a set of instruction sets that are grouped together to form a computer program. These programs may be executed, for example, in Java as an executable servlet that runs a given operating system in a processor. The executable program may also be written in native code. As is well known, a Java servlet includes class files executable in a Java Virtual Machine (JVM). It is managed by the servlet manager. If necessary, the servlet manager spawns a new service thread, and therefore, spawns a new servlet instance. Each servlet typically includes 3 basic routines: an init () routine, a destroy () routine, and a service () routine. The Init () routine provides an initialization function. These functions enable the servlets to be identified and managed by the servlet manager and other serving functions. The Destroy () routine is an irregular operation that selectively destroys servlets. The Service () routine provides the basic operational functionality of the servlet. This operation will be described in the flowchart of fig. 3.
The routine begins at step 50 with the servlet manager checking for receipt of an email. If mail has been received, the routine moves to step 52 to generate a servlet process instance. Thereafter, the instance performs a test to determine if the e-mail has a file attachment at step 54. If not, the servlet logs the received email at step 56 and forwards the email to the email client of the intended recipient at step 58. This is a conventional email handling process. However, if the e-mail has attachments, the servlet moves to step 60 to test whether all attachments are processed. If so, the routine returns. If the test of step 60 is "no," the servlet instance processes the next attachment at step 62. At step 64, a test is performed to determine whether the accessory satisfies a given policy having criteria. As will be seen, policies are defined by an administrator to decide whether file attachments are stored in accordance with the present invention. If the results of the test at step 64 indicate that the file attachment does not meet the given criteria, control returns to step 60 to test the remaining attachments. If, however, the result of step 64 is "yes," the servlet instance will process the attachment in the following manner.
At step 66, the servlet instance peels, or otherwise removes, the attachment from the email. At step 68, the servlet compresses the attachment. Step 68 is optional. At step 70, the compressed attachment is stored in a specific accessible address within the file space. The routine continues to step 72. Thus, for example, the servlet replaces the moved attachment with a reference to the given accessible location at step 72. In a preferred embodiment, the link is a reference to the local file system hypertext transfer protocol (http) or file transfer protocol (ftp) of a stored attachment accessible to the email recipient. Fig. 4 illustrates an email message with an attachment and fig. 5 illustrates no attachment, including an alternative reference in the link, such as http: // servernamecalaclear.0434807. doc. As illustrated, this object reference is identified in the message (i.e., clicking on the link can retrieve your attachment) and directs the targeted recipient to obtain the deleted attachment. The object references that are available for selection may be links only, including graphical links that attach thumbnails or other convenient text, graphics, or other object references.
The servlet routine then continues by providing the modified email (i.e., the email with the attachment deleted) to the designated recipient at step 74. Thus, at step 74, the modified email is recorded and copied to the client email input output subsystem of the intended recipient. Thereafter, control returns to step 60. When all attachments to a given email message have been processed in this manner, the main program loop ends. At step 76, the servlet instance is closed.
FIG. 6 is a flow diagram illustrating the application of management policies to determine whether a file attachment satisfies given storage criteria. This is step 64 in the flowchart of fig. 3. According to the invention, one or more different criteria are tested. The routine begins with step 80 to test whether a particular policy has been defined for the intended recipient (or a group of recipients because the intended recipient is a satisfactory member). If so, the routine continues to retrieve the user-specified (or group-of-users-specified) policy in step 82. The routine continues at step 84. This step is also performed if the test of step 80 is "no". In step 84, the routine tests whether all criteria defined by the policy have been tested. If so, the routine returns. If not, the routine continues to process the next criterion at step 86. A test is made at step 88 to determine if the file attachment meets the criteria. Thus, the given criteria may be that the attachment has a certain size, has a certain MIME format, etc. If the test of step 88 results in "yes," the routine continues to strip the attachment from the information, as has been previously defined. This is step 90. If, however, the file attachment does not meet the given criteria, the routine returns to the four steps 84 to obtain the next criteria in the policy. The process ends.
Fig. 7 illustrates 3 a simplified user interface that an administrator may use to generate an email file attachment storage policy in accordance with the present invention. This interface is merely illustrative. It includes some optional controls to determine whether a particular file attachment has been deleted. Thus, for example, one criterion is that a file attachment is larger than a given capacity. This control is selected by detecting the radio button 91 and entering the file size in the field 94. Another criterion is that attachments associated with the message are delivered to more recipients than a given number. This control is selected by detecting the radio button 95 and entering the number of recipients in field 97. Yet another criterion is that there are given keywords in the topic in the information attachment. This control is selected by detecting the radio button 99 and entering a keyword in the field 101. Yet another criterion is that the message attachment has a given MIME format (e.g. X-picture/gif). This control is selected by selecting radio button 103 and selecting the MIME format from list 105. The user interface in fig. 7 also includes a panel 107 to identify user-specified or user group-specified selection criteria. Thus, for example, attachments issued to a user or type of user may be designated for storage regardless of the characteristics of the attachment.
One of ordinary skill in the art will appreciate that a set of criteria may provide better control of the storage process by selective combinations (e.g., with boolean operations or a set of operations). Thus, for example, an administrator may decide that file attachments may be stored only if they are larger than a given size (e.g., 1Mb) and the number of recipients is larger than a given value (e.g., 10 users). As another example, an administrator may decide that only attachments of a given size and sent to a particular range of users may be stored. The given criterion may also be that the accessory has a particular sending priority. Of course, the actual strategy is quite different to suit a particular system environment.
FIG. 8 illustrates a preferred routine for the target recipient to retrieve a stored attachment. The routine begins at step 100 when an email client of an email recipient is opened to provide an email. At step 102, a test is performed to determine if the user wishes to retrieve a previously deleted stored file attachment. As mentioned previously, information instructing the user how to retrieve the attachment may be emailed along with the access address of the attachment in the file space. If the test of step 102 is "no," the routine loops. However, if the user selects a reference, such as an activation link, the routine continues to retrieve the file attachment at step 104. A test is performed at step 106 to determine if the file attachment is stored in a compressed manner. If so, the routine, in step 108, employs a special decompression routine to obtain the original attachment. This step is also performed if the test of step 106 is "no" in step 110, and the file attachment is provided to the intended recipient, who opens the attachment with local resources. The process ends.
Although the above explanation of the present invention is made in the context of controlling a set of mail server email clients, this is not a limitation of the present invention. The functionality of the present invention can be implemented in any network as in a typical system and is not limited to use behind a firewall.
Those skilled in the art will appreciate that the present invention provides many advantages over the prior art. When a copy of an email with an attachment is to be delivered to multiple users, the present technique requires only a copy of the attachment. For large email attachments, this functionality significantly reduces storage requirements. Moreover, the present technology provides an efficient method for easy retrieval of transferred file attachments. Also, if file attachments are frequently modified, such modifications may be communicated to the same unique network address. Using the same URL included in the original modified email, the user can get a new version of the attachment. When the user selects a URL (which may be the same as the URL in the old email), a new version of the attachment is available.
In another variation, it may be desirable for the accessory to be stored in a central memory and restrict access to particular users. In this case, part (or possibly all) of the file attachments are removed from the incoming mail, and part of the recipients are selectively authorized to retrieve (e.g., via an access control list) attachments sent to them.
As mentioned above, the attachment may be compressible prior to storage. If so, the compressed attachment is decompressed using the right decompression routine before being provided to the intended recipient. Those of ordinary skill in the art will appreciate that the particular compression and decompression routines are preferably complementary. The present invention does not require the specification of any particular form of compression or decompression routine.
As mentioned above, the functions described above are preferably implemented in software executable on a processor, i.e., as a set of instructions (program code) residing in a computer random access memory as a set of code modules. Until required by the computer, the set of instructions may be stored in another computer memory, for example, in a hard disk drive, or in a removable memory such as an optical disk (for eventual use in a CD ROM) or floppy disk (for eventual use in a floppy disk drive), or downloaded via the Internet or other computer network.
In addition, although the various methods described above are conveniently implemented in software, the basic object is achieved by a general purpose computer selectively or by software reconfiguration, one of ordinary skill in the art would also recognize that such methods may be carried out in hardware, firmware, or other specialized apparatus constructed to perform the required method steps.
Also, the world Wide Web "client", as used herein, is to be broadly interpreted as a means by which any computer or component thereof can be connected, directly or indirectly, or in any known or recently developed manner, to a computing network, such as the Internet. The term "server" can also be broadly interpreted as a means: a computer, a computer platform, an attachment to a computer or computer platform, or any component thereof. Of course, "client" can be broadly interpreted as a device that requests or obtains a file, and "server" is the mechanism that downloads the file.
Having thus described our invention, what is claimed as new and desired to be protected by letters patent is set forth in the appended claims.