Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUSRE43302 E1
Publication typeGrant
Application numberUS 11/807,953
Publication dateApr 3, 2012
Filing dateMay 29, 2007
Priority dateJul 24, 1997
Also published asCA2301147A1, CA2301147C, DE69836545D1, DE69836545T2, DE69841210D1, EP1010283A2, EP1010283A4, EP1010283B1, EP1750384A1, EP1750384B1, US6609196, US7380274, US8255683, US8607042, US20030196098, US20070005983, US20070214353, US20070245416, US20130198798, WO1999005814A2, WO1999005814A3
Publication number11807953, 807953, US RE43302 E1, US RE43302E1, US-E1-RE43302, USRE43302 E1, USRE43302E1
InventorsRobert D. Dickinson, III, Sathvik Krishnamurthy
Original AssigneeAxway, Inc.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
E-mail firewall with stored key encryption/decryption
US RE43302 E1
Abstract
An e-mail firewall (105) applies policies to e-mail messages (204) between a first site and a plurality of second sites in accordance with a plurality of administrator selectable policies (216). The firewall comprises a simple mail transfer protocol (SMTP) relay (202) for causing the e-mail messages (204) to be transmitted between the first site and selected ones of the second sites. A plurality of policy managers (216) enforce administrator selectable policies. The policies, such as encryption and decryption policies, comprise at least a first source/destination policy (218), at least a first content policy (202) and at least a first virus policy (224). The policies are characterized by a plurality of administrator selectable criteria (310), a plurality of administrator selectable exceptions (312) to the criteria and a plurality of administrator selectable actions (314, 316, 322) associated with the criteria and exceptions. The policy managers comprise an access manager (218) for restricting transmission of e-mail messages (204) between the first site and the second sites in accordance with the source/destination policy (218). The policy managers (216) further comprise a content manager (220) for restricting transmission of e-mail messages (204) between the first site and the second sites in accordance with the content policy (220), and a virus manager (224) for restriction transmission of e-mail messages (204) between the first site and the second sites in accordance with the virus policy (224).
Images(10)
Previous page
Next page
Claims(10)
What is claimed is:
1. A method for filtering e-mail messages transmitted from an external site to an internal site associated with a first policy, comprising:
i. intercepting a plurality of data packets associated with an e-mail message having a sender address associated with an external site;
ii. assembling said data packets to an application level message;
iii. detecting whether the application level message includes a digital signature attachment;
iv. applying at least one policy condition to said application level e-mail message, said policy condition applied by reference to said attached digital signature, said applying providing a policy application result;
v. applying at least a second policy condition to said application level e-mail message in response to a predetermined condition of the attached digital signature, the second policy condition selected by reference to an identity associated with the valid digital signature;
vi. detecting that the digital signature is a valid digital signature; and
vii. processing said application level e-mail message in accordance with said applying at least a second policy condition.
2. A method for filtering e-mail messages transmitted from an external site to an internal site associated with a first policy, comprising:
i. intercepting a plurality of data packets associated with an e-mail message having a sender address associated with an external site;
ii. assembling said data packets to an application level message;
iii. detecting whether the application level message includes a digital signature attachment;
iv. applying at least one policy condition to said application level e-mail message, said policy condition applied by reference to said attached digital signature, said applying providing a policy application result;
v. applying a second policy for detecting whether the attached signature is associated with a domain which is included in a stored list of trusted domains; and
vi. processing said application level e-mail message in accordance with said applying at least a second policy condition.
3. A method for filtering e-mail messages transmitted from an external site to an internal site associated with a first policy, comprising:
intercepting, at an SMTP relay implemented as programmed computer hardware separate and distinct from a packet inspection-type access firewall, a plurality of data packets associated with an e-mail message having a sender address associated with an external site;
assembling said data packets to an application level e-mail message;
detecting whether the application level e-mail message includes a digital signature attachment;
applying at least a first policy condition to said application level e-mail message, said first policy condition applied by reference to said attached digital signature, said applying providing a policy application result;
applying at least a second policy condition to said application level e-mail message in response to a predetermined condition of the attached digital signature, the second policy condition selected by reference to an identity associated with the valid digital signature;
detecting that the digital signature is a valid digital signature;
processing said application level e-mail message in accordance with said applying at least a second policy condition, and
responsive to the interception at the SMTP relay, building a list of sender policies corresponding to the sender address of the application level e-mail message and building a list of recipient policies corresponding to one or more recipient addresses of the application level e-mail message;
the applied first and second policy conditions being respectively selected from one of the lists of sender and recipient policies for the application level e-mail message,
wherein different types of the sender and recipient policies are applied to the application level e-mail message in a predetermined priority order in which access management policies are applied after decryption policies and before remaining content control policies, formal conversion policies and security policies, wherein the security policies include at least client security usage, preserve encryption and plain text access policies.
4. The method of claim 3, further comprising:
decrypting said application level e-mail message prior to said applying at least a second policy condition.
5. The method of claim 3, further comprising:
at the SMTP relay, filtering said application level e-mail message in accord with an administrator selectable set of access control-type, content-type, virus-type and security-type policy conditions,
wherein the access control-type, content-type, virus-type and security-type policy conditions are specified as a collection of administrator selectable criteria, exceptions to said criteria, and actions.
6. The method of claim 3,
wherein the processing includes encrypting the application level e-mail message and forwarding the encrypted application level e-mail message to a recipient thereof.
7. A method for filtering e-mail messages transmitted from an external site to an internal site associated with a first policy, comprising:
intercepting at an SMTP relay implemented as programmed computer hardware separate and distinct from a packet inspection-type access firewall, a plurality of data packets associated with an e-mail message having a sender address associated with an external site;
assembling said data packets to an application level e-mail message;
detecting whether the application level e-mail message includes a digital signature attachment;
applying at least a first policy condition to said application level e-mail message, said first policy condition applied by reference to said attached digital signature, said applying providing a policy application result;
applying at least a second policy condition for detecting whether the attached signature is associated with a domain which is included in a stored list of trusted domains;
processing said application level e-mail message in accordance with said applying at least a second policy condition; and
responsive to the interception at the SMTP relay, building a list of sender policies corresponding to the sender address of the application level e-mail message and building a list of recipient policies corresponding to one or more recipient addresses of the application level e-mail message;
the applied first and second policy conditions being respectively selected from one, of the lists of sender and recipient policies for the application level e-mail message,
wherein different types of the sender and recipient policies are applied to the application level e-mail message in a predetermined priority order in which access management policies are applied after decryption policies and before remaining content control policies, formal conversion policies and security policies, wherein the security policies include at least client security usage, preserve encryption and plain text access policies.
8. The method of claim 7, further comprising:
decrypting said application level e-mail message prior to applying at least a second policy condition.
9. The method of claim 7, further comprising:
at the SMTP relay, filtering said application level e-mail message in accord with an administrator selectable set of access control-type, content-type, virus-type and security-type policy conditions,
wherein the access control-type, content-type, virus-type and security-type policy conditions are specified as a collection of administrator selectable criteria, exceptions to said criteria, and actions.
10. The method of claim 7,
wherein the processing includes encrypting the application level e-mail message and forwarding the encrypted application level e-mail message to a recipient thereof.
Description
RELATED APPLICATION

This application is a continuation of U.S. application Ser. No. 09/180,377 filed Nov. 3, 1998, now U.S. Pat. No. 6,609,196, which was the National Stage of International Application PCT/US98/15552, filed Jul. 23, 1998, and which claims priority tothe benefit of U.S. Provisional Patent Application 60/053,668, filed on Jul. 24, 1997.

TECHNICAL FIELD

This application pertains generally to the field of computer security and more specifically to security for electronic mail systems.

BACKGROUND

The widespread use of electronic mail (e-mail) and groupware applications coupled with the growth and ubiquity of the Internet have opened new avenues for business level communications and electronic commerce. Organizations are increasingly relying on e-mail for the transfer of critical files such as purchase orders, sales forecasts, financial information and contracts both within the organization and increasingly with other organizations via the Internet. In this setting, these files are now tangible information assets that must be protected.

A number of conventional security measures exist to insure the confidentiality and integrity of modern data communications. For example, traditional firewalls prevent network access by unauthorized users. Secure sockets technology allows for data to be passed securely over the World Wide Web (WWW). E-mail, however, which is by far the most prominent application over the Internet, still remains problematic, from a security standpoint, for most organizations. Many traditional firewalls simply limit access to information protected by the firewall but do not contain the capability to limit transfer of information, into or out of an organization, by way of e-mail. This can lead to inadvertent or deliberate disclosure of confidential information from e-mail originating within an organization and introduction of viruses from e-mail entering an organization.

One solution to protecting confidentiality of e-mail messages is by encrypting such messages. Further security is available by way of digital signatures, which provide for authentication of e-mail messages. Encryption and authentication are both supported in the S/MIME (Secure/Multipurpose Internet Mail Extensions) messaging protocol defined in documents generated by the Internet Engineering Task Force (IETF) entitled “S/MIME Message Specification” (1997) and “S/MIME Certificate Handling” (1997). Individual users can encrypt/decrypt and authenticate e-mail messages using commercially available software. However, the use of software to perform such tasks is not always simple and therefore can detract from the inherent ease of use of e-mail as a means of communication. Moreover, an organization wishing to use such software must rely on individual users to encrypt all necessary messages without means of any centralized control. In addition, many conventional firewalls contain no capability to control the content or format of certain messages that enter or exit an organization. For example, many conventional firewalls contain no capability to ensure that e-mail meeting certain criteria such as content or source and/or destination address or domains, is encrypted. In addition, many conventional firewalls contain no capability to control unwanted messages entering an organization such as unsolicited e-mail advertising.

There is accordingly a need for an e-mail firewall that provides improved centralized control over e-mail messages exiting and entering an organization.

SUMMARY OF THE INVENTION

In a principal aspect, the present invention provides an e-mail firewall (105) for screening e-mail messages (204) originating in, or entering into a computer network (101, 103). Embodiments employing the principles of the present invention advantageously take the form of an e-mail control system (105) that controls e-mail messages (204) transmitted from and received by a computing site. The e-mail control system (105) includes a message encryptor (526) which encrypts, in accordance with at least a first stored encryption key (528), a first designated type of message (204) transmitted from the computing site. A message decryptor (552) decrypts, in accordance with at least a second stored encryption key (528), a second designated type of message (204) received by the computing site. A filter (216) monitors messages (204), after decryption by the decryptor (552) and before encryption by the encryptor (526), in accordance with changeable filter information (216).

A significant advantage of such embodiments is increased centralized control of e-mail policies by an organization. All e-mail messages entering into or originating within an organization can be encrypted or decrypted and filtered in accordance with policies imposed by the organization. Individual users of desktop computers within the organization therefore need not be concerned with ensuring that they comply with e-mail policies of the organization. E-mail messages can be monitored for certain content, or for certain sources or destinations.

Advantageously, embodiments employing the principles of the present invention operate transparently to individual users within an organization. For example such individual users need not be concerned with complying with encryption policies of the organization. E-mail messages containing certain content, or originating from, or being transmitted to specified addresses or domains, can be automatically encrypted and/or filtered. For example, if an organization (e.g. Company A) which frequently exchanges e-mail with another organization (e.g. Company B) determines that all e-mail to Company B should be encrypted for security purposes, then an e-mail firewall in Company A, as described above, can be configured to recognize the domain name of Company B and to store an encryption key. Thereafter, all e-mail messages from Company A to Company B will be encrypted by the above described e-mail firewall without requiring any additional action by individual users. If Company B has installed an e-mail firewall employing the above described principles then that email firewall can be configured to decrypt messages from Company A. Individual recipients in Company B of e-mail from Company A therefore need not take any additional action to decrypt e-mail from Company A. All e-mail messages from Company A to Company B can therefore be securely exchanged with no intervention from users at Company A or Company B. Of course, the e-mail firewall of Company B can be configured to allow similar transmission of e-mail messages from Company B to Company A.

In addition, other policies can be enforced with respect to transmission of messages between Company A and B. For example, inadvertent (or even deliberate) disclosure of certain information between Companies A and B can be reduced by configuring the above described filter of the e-mail firewall in question with rules to recognize and prevent transmission of e-mail messages containing certain terms or phrases. The e-mail firewall may also be configured with exceptions to such rules. For example, e-mail from or to certain users may be exempted from such rules. Also, actions taken by the e-mail firewall after a message is prevented from being transmitted are changeable. For example, the message in question may be returned to the sender with an explanatory message. Alternatively, or in addition, the message may be stored for viewing by an administrator, or the messages may be deleted. Multiple encryption keys, each associated with one or more domains or individual addresses, may be stored in e-mail firewalls employing the aforesaid principles to allow secure communications with multiple domains and/or individual users.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 of the drawings is a block diagram showing a plurality of e-mail networks which are coupled by way of the Internet and which employ an e-mail firewall employing the principles of the present invention.

FIG. 2 of the drawings is a block diagram of a preferred embodiment of an e-mail firewall.

FIGS. 3 and 4 are block diagrams illustrating further details of operation of the e-mail firewall of FIG. 2.

FIGS. 5(a), 5(b) and 5(c) are block diagrams illustrating alternative secure e-mail communication mechanisms.

FIGS. 6(a) and 6(b) are flowcharts illustrating operation of a preferred embodiment of an e-mail firewall.

FIG. 7 is a block diagram showing further details of a portion of FIGS. 6(a) and 6(b).

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In FIG. 1 of the drawings, e-mail networks 101 and 102 are coupled to e-mail network 103 by way of a Wide Area Network (WAN) 104 such as the Internet. Disposed between the internet 104 and e-mail network 101 and 103 are an access firewall 106 and an e-mail firewall 105. E-mail network 102 is coupled to Internet 104 only by access firewall 106.1. E-mail networks 101, 102, and 103 may each take a conventional form. For example, e-mail networks 101-103 may take the form of a Local Area Network (LAN) or a plurality of LANs which support one or more conventional e-mail messaging protocols. Access firewalls 106 may also take a conventional form. Access firewalls 106 operate to limit access to files stored within a computer network, such as e-mail networks 101-103, from remotely located machines. E-mail firewalls 105 (individually shown as 105.1 and 105.2) advantageously take a form as described in further detail herein to control transmission of electronic mail messages between an internal site and one or more external sites. An internal site for e-mail firewall 105.2, by way of example, may take the form of e-mail network 103. External sites for e-mail firewall 105.2 are any sites not contained in e-mail network 103. For example, external sites for e-mail firewall 105.2 are any sites in e-mail networks 101 and 102 as well as any other sites coupled to Internet 104. E-mail firewall 105 is preferably positioned on the “safe-side” of the access firewall 106. FIG. 1 should be understood as showing, by way of an example, the principles of the embodiments described herein. The access firewalls 106 are shown only for purposes of explanation and are not required for operation of embodiments employing the principles of the present invention.

Preferably the e-mail firewall 105 takes the form of a program executing on a conventional general purpose computer. In an exemplary embodiment, the computer executes the Windows NT or Windows 2000 operating systems available from Microsoft Corp., of Redmond, Wash. In other embodiments, the computer executes a Unix operating system such as Solaris from Sun Microsystems, of Mountain View, Calif. Although e-mail firewall 105 is shown in FIG. 1 as operating on e-mail messages between an internal site and an external site, the e-mail firewall 105 may also be used to exchange messages between two internal sites for computer networks with SMTP compliant messaging backbones.

FIG. 2 of the drawings illustrates in block diagram form the major functional components of e-mail firewalls 105.1 and 105.2. In FIG. 2, a Simple Mail Transfer Protocol (SMTP) relay module 202 performs the functions of a conventional SMTP relay host. An example of an Internet relay host is a UNIX Send mail program. The SMTP relay module 202 transmits and receives e-mail messages such as shown at 204 to and from an internal site 210 and external sites 212. E-mail message 204 takes the form of a conventional e-mail message which contains a plurality of user specified information fields, such as source field 205 specifying an e-mail address for the source of the message 204, a destination field 206 specifying one or more destination e-mail addresses for the message 204, a subject field 207 specifying a subject for the message 204, a body field 208 specifying the body of the message 204 containing textual and/or graphics data, and an optional attachment field 209, specifying one or more files to be transmitted with the message 204. Other user specified fields include, but are not limited to, priority of the message, identity of the sending agent, and the date and time of the message.

E-mail message 204 may be encoded in accordance with one of a plurality of encoding formats as explained in further detail below. SMTP relay module 202 preferably takes a conventional form of a software module which receives and transmits e-mail messages in accordance with the Simple Mail Transfer Protocol as specified by ‘Internet RFC 821.’ The SMTP protocol is not critical to the invention. In other embodiments, the SMTP relay module is replaced with a module that receives and/or transmits messages in other formats such as the File Transfer Protocol (FTP), the Hyper-Text Transfer Protocol (HTTP), the Network News Transfer Protocol (NNTP), or the Internet Relay Chart (IRC).

In one embodiment, the SMTP relay module 202 is configured to use the Domain Name System (DNS) to determine routing to message recipients or alternatively is configured to relay messages to at least one administrator specified SMTP host. If DNS is selected, at least one SMTP host is specified to allow for default message forwarding even if DNS service is not available. The routing option can be overridden on a per-domain basis. The SMTP relay module 202 advantageously allows inbound and outbound SMTP connections to be limited from or to specific hosts and allows connections to or from specific SMTP hosts to be denied. Preferably, the SMTP relay module 202 transmits messages that include text messages and binary data e-mail messages, as is known in the art. The following illustration refers to a generic routing server, which facilitates some of the functionality provided by the SMTP relay module 202 to transmit e-mail messages in accordance with the invention.

FIG. 3 illustrates the manner in which messages received by the SMTP relay module 202 from internal site 210 and external site 212 are processed by policy engine 214. Policy engine 214 accepts messages from SMTP relay module 202 and determines which policies are applicable to a message by building a list 302 of sender policies for the sender (source) 204 of the message, and building a list 302, 306, and 308 of recipient policies for each recipient. The policy engine 214 then calls the policy managers 216 to apply each policy. The different types of policies have a predetermined priority in which they are applied. For example, decryption policies are applied before other policies, to allow the policies that operate on the body 208 of the message to be able to access the contents contained therein. In an alternative embodiment, the order in which the policies are applied is selectable by a system administrator. Access manager policies get applied after decryption policies and then the other policy managers are called repeatedly in the order implied by the policies to be applied to the message. The policy engine 214 then receives results from policy managers 216 and transmits messages to SMTP relay module 202 in accordance with the received results. The results received by the policy engine 214 comprise actions such as disposition, annotation, and notification described in further detail herein. The result of processing of a message 204 by policy engine 214 can result in generation of a plurality of additional messages, for example, for notification to the sender or recipient, or to the system administrator. In a preferred embodiment, the policy engine 214 is implemented as a program executed by a digital computer.

Policy managers 216 operate to enforce policies entered by an administrator of e-mail firewall 105. Policy managers 216 preferably comprise a plurality of modules for enforcing administrator configured policies, directed to specific aspects of e-mail messages. For example, in e-mail firewall 105, policy manager 216 implements a plurality of manager modules including an access manager 218, a content manager 220, a format manager 222, a virus manager 224, and a security manager 226. Policy managers 216 are preferably developed by inputs entered by an administrator by way of configuration module 230. Configuration module 230 also operates, in response to information entered by an administrator, to configure SMTP relay 202 and policy engine 214. The policy managers shown in FIG. 2 and described herein are merely illustrative of an exemplary embodiment. Other types of policy managers are contemplated as being within the principals described herein. As may further be appreciated, the policy managers 216 operate to enforce policies on all portions of the message in a recursive manner. Thus, when a massage contains another message as an attachment, or when an attachment includes several files, e.g., ZIP. File, the various modules operate on such included content regardless of how far within deep message the content is extracted from. Thus, when an e-mail has another e-mail attached which has an archive attached to it, the policy managers 216 operate on the received e-mail, the attached e-mail, extract all files from the archive, and operate on each of the extracted files.

Access manager 218 provides enforcement of access control policies such as destinations to which e-mail is prohibited from being sent, or sources from which e-mail cannot be received. In one embodiment, the access manager 218 refers to a directory, such as a LDAP directory, when reviewing message destinations and sources. Access manager 218 can also filter messages that exceed a maximum message size determined by an administrator, or which contain specific words in the subject field 207 of the message. Access manager 218 can also filter a message by the priority of the message specified by the user. For example, high priority messages can be passed through immediately, while low priority messages are stored in a queue (explained in further detail in connection with FIG. 7). Access manager 218 can also filter messages by the date and/or time of transmission of the message. For example, messages transmitted between certain hours of the day or on certain days, such as weekends or holidays may be retained or further filtered by, for example, content manager 220.

Content manager 220 supports the enforcement of content control policies. The content manager 220 examines the message's content to determine if a content policy is applicable to the message. Preferably content manager 214 supports filtering by one or more of the following criteria: (a) specific words, or word patterns, in the body 208; (b) specific words in the subject 207; (c) attachment 209 (all or by name/type such as video or sound); (d) specific words, or word patterns, in the attachment 209. In one embodiment, the number of filter criteria matches is tracked to provide a match total for the message. The match total is then compared to a threshold to determine whether a dependent criteria is satisfied. For non-plain text attachments, such as PDF files and spreadsheets, text is extracted by employing well known content extraction software such as filter programs widely available as open source software. Filtering by attachment type also includes prompting a signature verification process for certain type attachments, such as executables. Content control policies, and other appropriate policies, can also be specified to require certain material, such as for example, certain notices or disclaimers. Other content policies block messages that include executables, including interpreted executables such as JavaScript. This blocking can extend to attachments that include embedded code or macros. In some embodiments, the prohibited embedded code is removed from the attachment while the message is allowed to pass to the recipient. This blocking is one form of preventing virus programs from infecting a recipient computer. A second form is enforcement provided by virus manager 224.

Virus manager 224 supports the enforcement of virus control policies by detecting virus infected e-mail attachments. Virus manager 224 preferably detects viruses contained in a plurality of compressed file formats including PKZip, PKLite, ARJ, LZExe, LHA, and MSCompress. Virus manager 224, by way of example, may use a commercially available virus scanning engine. Virus manager 224 also preferably applies policies on “clean messages,” that is, messages that have been scanned for a virus and found to be free of any viruses. In this embodiment, a “clean stamp” annotation is added to such messages, indicating that no viruses were detected.

Format manager 222 provides conversion of an e-mail message from a first format to a second format. In a preferred embodiment, format manager 222 converts messages from conventional UUENCODE format to MIME format. Preferably format manager 222 converts messages prior to message processing by other policy managers.

Security manager 226 preferably enforces a plurality of e-mail encryption policies. Preferably, security manager 226 enforces a client security usage policy, a preserve encryption policy, a plain text access policy, and default action policies. Security manager 226 also applies on behalf of users proxy encryption and signature policies, as discussed in further detail in connection with FIG. 5(b).

Other actions associated with the policy managers 216 include prompting for secure delivery and archiving the message. In one embodiment, secure routing is implemented by forwarding the message to the destination over a predefined transmission route such as that provided by Transport Level Security (TLS) routing. In another embodiment, secure routing is by a redirection of the message to a secure message delivery service such as IME service from Tumbleweed Communication of Redwood City, Calif.

In one embodiment, client security usage policies specify that certain users, under certain conditions, should perform encryption or signature, or both, at the desktop. Additional criteria can be set to indicate when this policy should be enforced. For example, an e-mail from a company's CEO to the company's legal counsel by the domain or full e-mail address can be specified to require either encryption, signature, or both, to enforce attorney-client privilege and to preserve encryption policies. Moreover, client security usage policies can be used to specify that messages, which are already in encrypted form and perhaps meet some other criteria, should be preserved. Thus, such messages are not processed, modified, or encrypted by the e-mail firewall 105. Furthermore, the security policy may also select varying encryption methods as a result of applying policy to transmitted e-mail. Plain text access policies require that the e-mail firewall 105 is designated as a recipient on certain types of specified messages. The e-mail firewall 105 is designated as a recipient on encrypted messages in order to apply access, content, virus, and other policies on the message. Plain text access policies can also be used to send a signed notification to the sender of a message as a way of providing the sender with the e-mail firewall's 105 public key. Default action policies indicate the action to be taken on messages, which are not encrypted and will not be encrypted by the e-mail firewall 105, and which might meet some other criteria. The default action policy type is used to ensure that certain messages get encrypted somewhere, whether at the desktop or by the e-mail firewall 105.

Policies are preferably entered by an authorized administrator by way of configuration module 230 which preferably takes the form of a program executing on a stored program computer. Policies can advantageously be applied to users, either individually or by e-mail domains or other groupings. FIG. 4 shows an example of how policies are applied. Users can be organized in a hierarchical directory-type structure to facilitate grouping of users and/or domains. If a policy is applied to a given directory then sub-directories corresponding to the given directory inherit such policies. For example, in FIG. 4, policy 1 applies to sub-directory 404 and thus applies to all sub-directories, domains and users, such as sub-directory 412, user 408, and domain 410, corresponding to sub-directory 404, unless that policy is explicitly overridden by another policy applied to a particular sub-directory or to an intervening sub-directory. For example, policy 3 will override policy 1, for users shown at 408, where there are conflicts between policy 1 and policy 3, and will supplement policy 1, where there are no conflicts. Exception 1 will override policies 1 and 3 for the particular exception specified in exception 1. As further shown in FIG. 4, policy 1 applies to users 414, 416, and 418, and is overridden by policy 2 for users 414, 416, and 418 in the event of conflicts, and is supplemented where there are no conflicts. This advantageously allows policies to be easily applied to groups of users. The exact manner in which the policies are stored is not critical, and a variety of means and formats of storage may be employed.

E-mail messages 204 received and/or transmitted by SMTP relay 202 are preferably encoded in accordance with the S/MIME (Secure/Multipurpose Internet Mail Extension) protocol, as specified by the Internet Engineering Task Force in documents entitled “S/MIME Message Specification” (1997) and “S/MIME Certificate Handling” (1997). Advantageously, the S/MIME protocol builds security on top of the industry standard MIME protocol according to Public Key Cryptography Standards (PKCS) specified by RSA Data Security, Inc. S/MIME advantageously offers security services for authentication using digital certificates, and privacy, using encryption. Digital certificates are preferably implemented in accordance with the X.509 format as specified in “Information Technology—Open Systems Interconnection—The Directory: Authentication Framework,” also known as “ITU-T Recommendation X.509” (June 1997). Encryption is preferably performed by one of the following symmetric encryption algorithms: DES, Triple-DES, RC2, and other algorithms introduced by revisions of the S/MIME standard. The S/MIME protocol is well known and widely used and provides encryption and digital signatures and is therefore preferable as a communications protocol. The precise details by which the protocol operates is not critical. Moreover, it should be understood that other secure messaging protocols such as PGP (Pretty Good Privacy) or Open PGP, as specified by the ITF working group, may also be used.

Access manager 218 is the first policy manager to process e-mail message 204. Access manager 218 operates only on message header information which is not encrypted. Thus, access manager 218 may operate on an e-mail message 204 prior to decryption by S/MIME engine 215. The term “message header information” generally refers to portions of message excluding the body 208 (and commonly referred to as message text), and attachments 209. Thus, the header information includes the source, destination, and subject fields (205, 206, 207). Optional header fields include date/time stamp, priority, and sending agent. The remainder of the modules operate on the message 204 after processing by S/MIME engine 215. As previously noted, format manager 222 preferably operates on messages prior to operation by other managers such as virus manager 224, security manager 226, and content manager 220.

The S/MIME protocol allows two sites which support the S/MIME protocol to exchange secure e-mail messages 204. A type of virtual private network (VPN), as shown in FIG. 5(a), can be achieved if both the transmitting and receiving site perform S/MIME functions. The resulting VPN, termed herein an “object level e-mail VPN,” provides encryption/signature and/or decryption/verification of messages between transmitting and receiving site(s). In the object level e-mail VPN shown in FIG. 5(a), each object (message) is encrypted individually and sent over a standard (SMTP) transport medium, where each object (message) is decrypted at the other end. Advantageously, the object level e-mail VPN does not require a secure real-time connection as required by conventional VPNs. As shown in FIG. 5(a), mail servers 105.1 and 105.2 perform functions described herein for e-mail firewall 105, and as a result, achieve an object level e-mail VPN between them. E-mail that is encrypted and transmitted between servers 105.1 and 105.2 is protected from disclosure to third parties, despite the fact that e-mail transmitted via the Internet 104 may pass through numerous unsecured servers before reaching its destination. Accordingly, one may appreciate that it is not required for the intermediate e-mail relay servers between servers 105.1 and 105.2 to support encryption or decryption of messages.

In one embodiment, in such an exchange, e-mail firewalls 105.1 and 105.2 provide key pair and public key certificate generation and provide automated or manual public key certificate exchange with the other S/MIME server. In addition, e-mail firewalls 105.1 and 105.2 allow: identification of the other S/MIME server through directory domain records, association of directory domain records with server certificates and selection of encryption/signature algorithms and key lengths. The directory domain records, and the directory user records referred to below, are as described in FIG. 4.

Exchange of S/MIME encoded messages may also be performed between the e-mail firewalls 105.1, 105.2 and an S/MIME client coupled in a server that does not perform S/MIME functions. FIG. 5(b) illustrates an exchange between e-mail firewall 105 and a S/MIME client coupled to a non-S/MIME server 506. In FIG. 5(b), server 105.1 encrypts and decrypts messages on behalf of client 502.2 and generally provides the functions described above for e-mail firewalls 105.1 and 105.2. Specifically, in such an exchange, e-mail firewall 105.1 provides key pair and public key certificate generation and provides automated or manual public key certificate exchange with the client 508.1. In addition, e-mail firewall 105.1 allows: identification of the client 508.1 through directory user records, association of directory user records with user certificates and selection of encryption/signature algorithms and key lengths. Client 508.1 provides encryption/decryption services to allow messages to be transmitted securely through server 506 by supporting encryption/decryption services. A specific type of object level VPN, referred to herein as “proxy security,” is achieved in FIG. 5(b) between the server 105.1 and the client 508.1. In proxy security, at least one client is involved in performing encryption/decryption, such as client 508.1 in FIG. 5(b). This is in contrast to the arrangement of FIG. 5(a), where the encryption/decryption services performed by servers 105.1 and 105.2 is transparent to the clients 502.1 and 502.2.

In FIG. 5(a), communications between servers 105.1 and 105.2 are secure, but communications between clients 502.1 and 502.2 and their respective servers 105.1 and 105.2 are not necessarily secure. In many such installations, security is not necessary because the client 502.1 and the server 105.1 typically communicate over a common LAN, which is protected from the Internet by a standard firewall. However, if such security is desired, the clients 508.1 and 508.2 can also be equipped with encryption/decryption services to perform proxy security, as is shown in FIG. 5(c). The servers 105.1 and 105.2 perform the same function described above in connection with FIG. 5(a) and therefore achieve an object level VPN. In addition, the clients 508.2 and 508.1 allow secure communications with the corresponding servers 105.1 and 105.2. It should be noted that the encryption/decryption performed by servers 105.1 and 105.2 can be independent of the encryption performed by the corresponding clients 508.2 and 508.1. For example, a message by client 508.2 to client 508.1 may be encrypted when transmitted to server 105.1, decrypted by server 105.1 and subjected to appropriate actions by the policy managers. The message may then be encrypted for transmission to server 105.2, decrypted by server 105.2, and subjected to appropriate actions by the policy managers, and encrypted for transmission to client 508.1 which decrypts the message. Alternatively, a message by client 508.2 to client 508.1 may be encrypted by client 508.2, be subjected to appropriate actions to non-encrypted portions, such as the destination field, and then the entire message, including the portions not encrypted by client 508.2, can be encrypted again by server 105.1 for transmission to server 105.2, which decrypts the encryption by server 105.1, and transmits the message to client 508.1 for decryption of the encryption performed by client 508.2. Several combinations of the foregoing two scenarios are possible. In another embodiment, the client to server connection is protected by means other than object level security such by using a Secure Socket Layer (SSL) connection while the connection between servers is by an object level VPN in accordance with the invention.

Each e-mail message 204 processed by e-mail firewall 105 is processed in accordance with the steps shown in FIGS. 6(a) and 6(b). FIG. 6(a) is a flowchart showing operation of the e-mail firewall 105 in response to a received message. FIG. 6(b) is a flowchart showing operation of the e-mail firewall 105 prior to transmitting a message. The messages processed by e-mail firewall 105 may be received from an internal site for transmission to an internal site, or may be received from an internal site for transmission to an external site, or may be received from an external site for transmission to an internal site. Any single message may include internal and external destinations 206. The steps shown in FIGS. 6(a) and 6(b) are preferably performed by generation of sender and recipient policies shown in FIG. 3. For multiple destinations, the steps shown in FIG. 6(b) may therefore be performed differently and have different results for different destinations.

Turning to FIG. 6(a), at 602, the e-mail firewall 105 determines if decryption of portions of the message 204 is required. If so, then at 604, decryption is performed in accordance with stored private keys 628. Storing private keys is well known in the art of public key cryptography. After decryption, or if no decryption is required, the e-mail firewall 105 applies policy managers 216, which can perform four types of actions (shown at 610, 612, 614, 616, and 620) on e-mail message 204 for each policy. Criteria actions 610 present filtering criteria selected by the administrator. Exception actions 612 determine which criteria 610 are excluded. Multiple criteria 610 can be selected which effectively results in a logical AND operation of the criteria. Multiple exceptions 612 can be selected which effectively results in a logical OR operation of the exceptions; that is, any one of the exception conditions being true will result in a policy not being triggered. In another embodiment, a generic Boolean expression is used in lieu of the criteria and exception combination. Annotation actions 614 cause generation of attachment to message 602 or insertion of text into the body 208 of the message. The manner by which annotations are made is based on a policy entered by the administrator. Notification actions 616 cause the sending of one or more e-mail notifications when a given policy is triggered. Notifications can be sent to sender, recipient, administrator, or any e-mail address that is defined by the administrator. In addition, notification actions 616 allow specification of whether the original message 204 should accompany the notification. Disposition action 620 determines whether the message should continue to the destination(s) (specified by field 620) or whether one of a plurality of alternative actions 622 such as deferral, quarantine, return to sender, or dropping of the message are required.

Referring now back to FIG. 6(b), the illustrated steps are performed for each destination specified for a message 204. The steps shown in FIG. 6(b) are also performed for messages generated by step 622. First, policy managers 216 perform actions 610, 612, 614 and 616, for each destination specified in the message 204. Disposition action 623, operates similarly to disposition action 620 by determining whether the message should continue to the destination(s) or whether one of a plurality of alternative actions 622 such as deferral, quarantine, return to sender, or dropping of the message, are required. At step 624, a determination is made if encryption or signature is required. If encryption is required, then at step 626 encryption is performed in accordance with stored keys 628. If a signature is required, a signature is added at step 629. Notice that some implementation may instead choose to sign before encrypting. The message is then transmitted to the specified destination at step 630. Messages that are processed by block 622 are also checked at step 624 before transmission. For example, messages that are deferred, quarantined, or returned to the sender, may need to be encrypted or include a signature.

FIG. 7 is a block diagram showing further details of alternative actions 622. Messages received from disposition step 620 are stored in one of the four queues 702, which include quarantine queue 704, retry queue 706, dead letter queue 708, and defer queue 709 depending upon the specified disposition of the message. Quarantine queue 704 stores messages for subsequent retrieval and review by a system administrator or other authorized person. Retry queue 706 stores messages for which delivery has failed. Transmission of messages in the retry queue 706 is subsequently re-attempted. Dead letter queue 708 stores messages which continue to be undeliverable after several retries and which cannot be returned to the sender. Messages in the dead letter queue 708 may be acted upon by a system administrator. Defer queue 709 stores messages to be delivered automatically at a later time, for example an off-peak-time such as a weekend or night time. Configuration module 230 provides a plurality of actions 710-714 which may be performed on the messages in queue 702. The messages can be viewed 710 by the administrator, returned to the sender 711, deleted 712, sent to the specified destination(s) 713 and/or saved 714.

It is to be understood that the specific mechanisms and techniques which have been described are merely illustrative of one application of the principals of the invention. Numerous modifications may be made to the methods and apparatus described without departing from the true spirit and scope of the invention.

Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5278984Dec 19, 1990Jan 11, 1994Bull Hn Information Systems Inc.Method for managing requests by specifying time intervals for transmitting a minimum number of messages for specific destinations and priority levels
US5283856Oct 4, 1991Feb 1, 1994Beyond, Inc.Event-driven rule-based messaging system
US5331543Jan 15, 1991Jul 19, 1994Hitachi, Ltd.Business monitoring system and method
US5369707Jan 27, 1993Nov 29, 1994Tecsec IncorporatedSecure network method and apparatus
US5377354Jun 8, 1993Dec 27, 1994Digital Equipment CorporationMethod and system for sorting and prioritizing electronic mail messages
US5406557Feb 1, 1993Apr 11, 1995National Semiconductor CorporationInterenterprise electronic mail hub
US5414833 *Oct 27, 1993May 9, 1995International Business Machines CorporationNetwork security system and method using a parallel finite state machine adaptive active monitor and responder
US5416842 *Jun 10, 1994May 16, 1995Sun Microsystems, Inc.Method and apparatus for key-management scheme for use with internet protocols at site firewalls
US5530758Jun 3, 1994Jun 25, 1996Motorola, Inc.Operational methods for a secure node in a computer network
US5555346Jan 29, 1993Sep 10, 1996Beyond CorporatedEvent-driven rule-based messaging system
US5577202Aug 24, 1992Nov 19, 1996Trw Inc.Message handling system for automated gateway between first and second handling systems wherein first envelope is added to a second envelope respectively without changing text
US5606668Dec 15, 1993Feb 25, 1997Checkpoint Software Technologies Ltd.System for securing inbound and outbound data packet flow in a computer network
US5619648Nov 30, 1994Apr 8, 1997Lucent Technologies Inc.For locating expertise in a messaging system in a computer system
US5623600Sep 26, 1995Apr 22, 1997Trend Micro, IncorporatedVirus detection and removal apparatus for computer networks
US5627764Jun 9, 1993May 6, 1997Banyan Systems, Inc.Automatic electronic messaging system with feedback and work flow administration
US5632011May 22, 1995May 20, 1997Sterling Commerce, Inc.Electronic mail management system for operation on a host computer system
US5634005Jun 4, 1996May 27, 1997Kabushiki Kaisha ToshibaSystem for automatically sending mail message by storing rule according to the language specification of the message including processing condition and processing content
US5740231Sep 16, 1994Apr 14, 1998Octel Communications CorporationNetwork-based multimedia communications and directory system and method of operation
US5748738Sep 15, 1995May 5, 1998Document Authentication Systems, Inc.System and method for electronic transmission, storage and retrieval of authenticated documents
US5748884Jun 13, 1996May 5, 1998Mci CorporationAutonotification system for notifying recipients of detected events in a network environment
US5778174Dec 10, 1996Jul 7, 1998U S West, Inc.Method and system for providing secured access to a server connected to a private computer network
US5796948Nov 12, 1996Aug 18, 1998Cohen; Elliot D.Offensive message interceptor for computers
US5802253Feb 26, 1996Sep 1, 1998Banyan Systems IncorporatedEvent-driven rule-based messaging system
US5826023Jun 3, 1996Oct 20, 1998International Business Machines CorporationCommunications tunneling
US5828893Aug 21, 1995Oct 27, 1998Motorola, Inc.System and method of communicating between trusted and untrusted computer systems
US5832208Sep 5, 1996Nov 3, 1998Cheyenne Software International Sales Corp.For use in a computer network
US5835594Feb 9, 1996Nov 10, 1998Intel CorporationMethods and apparatus for preventing unauthorized write access to a protected non-volatile storage
US5835726Jun 17, 1996Nov 10, 1998Check Point Software Technologies Ltd.System for securing the flow of and selectively modifying packets in a computer network
US5848415Dec 18, 1996Dec 8, 1998Unisys CorporationIn a computer network
US5864683Oct 12, 1994Jan 26, 1999Secure Computing CorporartionSystem for providing secure internetwork by connecting type enforcing secure computers to external network for limiting access to data based on user and process access rights
US5889943Mar 29, 1996Mar 30, 1999Trend Micro IncorporatedApparatus and method for electronic mail virus detection and elimination
US5905777Sep 27, 1996May 18, 1999At&T Corp.In a communications system
US5909493Oct 16, 1996Jun 1, 1999Ricoh Company, Ltd.Method and system for diagnosis and control of machines using connectionless modes of communication
US5915024Jun 17, 1997Jun 22, 1999Kabushiki Kaisha ToshibaElectronic signature addition method, electronic signature verification method, and system and computer program product using these methods
US5978484 *Apr 25, 1996Nov 2, 1999Microsoft CorporationSystem and method for safety distributing executable objects
US5983350Sep 18, 1996Nov 9, 1999Secure Computing CorporationSecure firewall supporting different levels of authentication based on address or encryption status
US6072942Sep 18, 1996Jun 6, 2000Secure Computing CorporationSystem and method of electronic mail filtering using interconnected nodes
US6073142Jun 23, 1997Jun 6, 2000Park City GroupAutomated post office based rule analysis of e-mail messages and other data objects for controlled distribution in network environments
US6092101Jun 16, 1997Jul 18, 2000Digital Equipment CorporationMethod for filtering mail messages for a plurality of client computers connected to a mail service system
US6154840May 1, 1998Nov 28, 2000Northern Telecom LimitedSystem and method for transferring encrypted sections of documents across a computer network
US6161181 *Mar 6, 1998Dec 12, 2000Deloitte & Touche Usa LlpSecure electronic transactions using a trusted intermediary
US6182118Oct 27, 1997Jan 30, 2001Cranberry Properties LlcSystem and method for distributing electronic messages in accordance with rules
US6237096May 4, 1998May 22, 2001Eoriginal Inc.System and method for electronic transmission storage and retrieval of authenticated documents
US6324648Dec 23, 1999Nov 27, 2001Gte Service CorporationSecure gateway having user identification and password authentication
US6336186Sep 16, 1998Jan 1, 2002Networks Associates Technology, Inc.Cryptographic system and methodology for creating and managing crypto policy on certificate servers
US6385655Oct 2, 1997May 7, 2002Tumbleweed Communications Corp.Method and apparatus for delivering documents over an electronic network
US6393568Oct 23, 1997May 21, 2002Entrust Technologies LimitedEncryption and decryption system and method with content analysis provision
US6424718Jun 11, 1997Jul 23, 2002International Business Machines CorporationData communications system using public key cryptography in a web environment
US6584563Feb 24, 1997Jun 24, 2003Fujitsu LimitedUser support system for cryptographic communication in network systems
US6609196Jul 23, 1998Aug 19, 2003Tumbleweed Communications Corp.E-mail firewall with stored key encryption/decryption
US6651166Apr 9, 1998Nov 18, 2003Tumbleweed Software Corp.Sender driven certification enrollment system
US6853988Sep 20, 2000Feb 8, 2005Security First CorporationCryptographic server with provisions for interoperability between cryptographic systems
US7096497Mar 30, 2001Aug 22, 2006Intel CorporationFile checking using remote signing authority via a network
US7117358May 22, 2002Oct 3, 2006Tumbleweed Communications Corp.Method and system for filtering communication
US7127741Jun 22, 2001Oct 24, 2006Tumbleweed Communications Corp.Method and system for e-mail message transmission
US20010039615Apr 15, 1997Nov 8, 2001At &T Corp.Methods and apparatus for providing a broker application server
US20030051142May 16, 2001Mar 13, 2003Hidalgo Lluis MoraFirewalls for providing security in HTTP networks and applications
US20030167402 *Aug 16, 2002Sep 4, 2003Stolfo Salvatore J.System and methods for detecting malicious email transmission
US20030196098Apr 21, 2003Oct 16, 2003Tumbleweed Communications Corp.E-mail firewall with stored key encryption/decryption
EP0420779A2Aug 29, 1990Apr 3, 1991International Business Machines CorporationUser selectable electronic mail management method
EP0680187A2Mar 2, 1995Nov 2, 1995International Business Machines CorporationSecurity device for data communications networks
EP2318486A1Jul 7, 2009May 11, 2011Ulive Enterprises LtdClathrates for gas storage
JP2000515332A Title not available
JP2001505371A Title not available
JPH03117940A Title not available
JPH05207029A Title not available
JPH06276221A Title not available
JPH07107082A Title not available
JPH08204701A Title not available
JPH08251156A Title not available
JPH08263404A Title not available
JPH09252294A Title not available
JPH10504168A Title not available
WO1996035994A1May 8, 1996Nov 14, 1996Compuserve IncRules based electronic message management system
WO1997000471A2Jun 16, 1996Jan 3, 1997Check Point Software Tech LtdA system for securing the flow of and selectively modifying packets in a computer network
WO1997024825A2Dec 20, 1996Jul 10, 1997Martin BrabandMethod and microcomputer system for the automatic, secure and direct transmission of data
WO1999005814A2Jul 23, 1998Feb 4, 1999Worldtalk CorpE-mail firewall with stored key encryption/decryption
Non-Patent Citations
Reference
1"Enterprise solutions Announces RSA Mail", Jan. 12, 1994, pp. 1-2.
2"GlobalKey Chooses RSA Technology to Secure First Real-Time Communications Environment", Jun. 10, 1996, pp. 1-3.
3Antivirus "InterScan E-Mail Virus Wall(TM)", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
4Antivirus "InterScan Virus Wall(TM) The Internet Anti-Virus Security Suite", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
5Antivirus "InterScan E-Mail Virus Wall™", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
6Antivirus "InterScan Virus Wall™ The Internet Anti-Virus Security Suite", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
7Antivirus.com "ScanMail(TM) for Microsoft Exchange Server", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
8Antivirus.com "ScanMail™ for Microsoft Exchange Server", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
9Antivirus.Com: Press Releases "Press Releases", May 14, 1997, pp. 1-2.
10Author unknown, 3rd party search of internet archive (2 pages) and printouts (31 pages), apparently representing content archived from http://www.nha.com circa Nov. 12, 1996. Printouts include pages apparently descriptive of a MIMEsweeper (documents apparently received from 3rd Party and apparently printed Jun. 8, 2004), 33 pages.
11Avolio, F., and Ranum, M. "A Network Perimeter with Secure External Access", Trusted Information Systems, Inc., Symposium on Network and Distributed System Security, Feb. 2-4, 1994, pp. 109-119.
12 *Bruce Schneier: Applied Cryptography 2nd Edition, John Wiley & Sons Pub., Oct. 1995 pp. 31-33 and 185-187.
13Business Wire "Internet Security gets Less Costly and Easier to Manage: Integralis Announces MIMEsweeper Compatible with Check Point FireWall-1 on Single NT Server; E-mail virus detection and content management can reside on Firewall server, saving money and support costs", Sep. 16, 1996, pp. 1-3.
14Canter, S. "internet E-Mail encryption", Apr. 8, 1997, PC Magazine, 5 pages.
15Carreon, J., "Product Overview", InfoWorld , Jul. 29, 1996, p. 74.
16Cate, Vincent, "Email-Firewalls"/Instant Corporate PGP, May 21, 1994, pp. 1-2.
17Cate, Vincent, "Email-Firewalls"/Instant Corporate PGP, May 21, 1994.
18Check Point "FireWall-1 Access Control", pp. 1-5, publication date unknown, received from third party on Feb. 26, 2009.
19Check Point "FireWall-1 Content Security", pp. 1-4, publication date unknown, received from third party on Feb. 26, 2009.
20Check Point "FireWall-1 Supported Applications", pp. 1-5, publication date unknown, received from third party on Feb. 26, 2009.
21Check Point "What's in the News?", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
22Check Point FireWall-1™ White Paper, Version 3.0, Jan. 1997, pp. 1-47.
23Check Point Home Page "Table of Contents", pp. 1-6, publication date unknown, received from third party on Feb. 26, 2009.
24Check Point Software "Check Point FireWall-1 Release 3.0", 1 page, publication date unknown, received from third party on Feb. 26, 2009.
25Check Point Software "Check Point FireWall-1 Version 3.0 Highlights", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
26Check Point Software "Check Point FireWall-1-Introduction", Mar. 1997, pp. 1-2.
27Check Point Software "Check Point FireWall-1—Introduction", Mar. 1997, pp. 1-2.
28Check Point Software Product Information "understanding Check Point Products", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
29Check Point Software Technologies Ltd. "Leading Content Security Vendors Announce Support for Check Point FireWall-1 3.0", Oct. 7, 1996, pp. 1-3.
30Check Point Software Technologies, Ltd. "Check Point Enables Secure Business Over the Internet with FireWall-1 2.0", Sep. 18, 1995, pp. 1-3.
31Check Point Software Technologies, Ltd. "Check Point FireWall-1 3.0 Awarded Best of Show at NetWorld+Interop Paris", Oct. 14, 1996, pp. 1-2.
32Check Point Software Technologies, Ltd. "Check Point FireWall-1(TM) White Paper", Version 3.0, Jun. 1997, pp. 1-34.
33Check Point Software Technologies, Ltd. "Check Point Software Delivers Breakthrough Security Advancements with FireWall-1 3.0", Oct. 7, 1996, pp. 1-4.
34Check Point Software Technologies, Ltd. "Check Point Software Technologies Ltd. Awarded Patent for Stateful Inspection Technology", Mar. 17, 1997, 1 page.
35Check Point Software Technologies, Ltd. "Check Point Software Unveils FireWall-1 Version 2.1", Jun. 17, 1996, pp. 1-3.
36Check Point Software Technologies, Ltd. "Integralis Announces OPSEC-complaint MIMEsweeper for FireWall-1 ", Apr. 28, 1997, pp. 1-2.
37Check Point Software Technologies, Ltd. "Internet Security gets Less Costly and Easier to Manage", Sep. 16, 1996, pp. 1-2.
38Check Point Software Technologies, Ltd. "Check Point FireWall-1™ White Paper", Version 3.0, Jun. 1997, pp. 1-34.
39CheckPoint-FireWall-1 "FireWall-1 version 2.1", 7 pages, publication date unknown, received from third party on Feb. 26, 2009.
40CheckPoint—FireWall-1 "FireWall-1 version 2.1", 7 pages, publication date unknown, received from third party on Feb. 26, 2009.
41Cheswick, W.R. and Bellovin, S.M., Firewalls and Internet Security-Repelling the Wily Hacker, (Addison Wesley 1st ed.), 1994.
42ConnectSoft Inc. "ConnectSoft Ships S/MIME Compliant Email Connection 3.1", Oct. 4, 1996, 1 page.
43ConnectSoft Inc. "S/MIME Arrives! ConnectSoft E-Mail Connection 3.0 Ships", May 14, 1996, pp. 1-2.
44Content Security White Paper "A Discussion of content based threats from the Internet and other internal and public networks", pp. 1-17, publication date unknown, received from third party on Feb. 26, 2009.
45Costales, B. with Allman, E., "sendmail Second Edition", 1997, 1993 O'Reilly & Associates, Inc., Table of Contents & Chapter 20 only, 31 pages.
46Costales, Bryan and Allman, Eric, "Building, Installing, and Administering Sendmail," Sendmail, 3rd Edition, O'Reilly & Associates (2002), Appendix D, pp. 1161-1172 (received from 3rd party).
47Costales, Bryan and Allman, Eric, "Help for UNIX System Administrators," Sendmail, 2nd Edition, O'Reilly & Associates (1997), Ch. 20, pp. 285-302 (received from 3rd party).
48Crocker, D, "Standard for the Format of ARPA Internet Text Messages", Dept. of Electrical Engineering, University of Delaware, Newark, Aug. 13, 1982; pp. 1-99.
49Deming "S/MIME Keys", 1 page, publication date unknown, received from third party on Feb. 26, 2009.
50Deming Acquisition "Worldtalk Acquires Deming Software Internet Mail Security Software Developer", Nov. 11, 1996, 1 page.
51Deming Screen Shots "Secure Messenger Screen Shots", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
52Deming Software "Deming Internet Security", Nov. 1996, 1 page.
53Deming Software "Deming Software Announces Secure E-mail Solution for QUALCOMM's Eudora Pro 3.0 at EMA '96", Apr. 30, 1996, pp. 1-2.
54Deming Software "Message Security Plug-in For Eudora Pro(TM) 3.0 Available Online From Deming Software", Oct. 15, 1996, pp. 1-2.
55Deming Software "Press Box- Press Release", 1996, 1 page.
56Deming Software "Secure Messenger(TM)", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
57Deming Software "Message Security Plug-in For Eudora Pro™ 3.0 Available Online From Deming Software", Oct. 15, 1996, pp. 1-2.
58Deming Software "Press Box— Press Release", 1996, 1 page.
59Deming Software "Secure Messenger™", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
60Deming Software Inc. "Deming Software Licenses Technology firm RSA Data Security for Secure E-mail Product and Developers' Toolkit", Apr. 2, 1996, pp. 1-2.
61Deming Software, Inc. Deming Software Announces Secure E-mail Solution for Microsoft Exchange at Networld+Interop, Apr. 2, 1996, pp. 1-2.
62Deming Software-Press Release "Deming Software Licenses Technology from RSA Data Security for Secure E-mail Product and Developers' Toolkit", Apr. 2, 1996, 2 pages.
63Department of the Army, U.S. Army Corps of Engineers; Emergency Employment of Army and Other Resources; Emergency Operations Center Standard Operating Procedures (HQUSACE-EOCSPO); Jul. 12, 1994.
64Dunlap, C., "Worldtalk to deliver E-Mail Firewall", Computer Reseller News, Jun. 16, 1997, 1 page.
65Dusse, S. and Matthews, T. "S/MIME: Anatomy of a Secure E-mail Standard", RSA Data Security, Inc., pp. 1-4, publication date unknown, received from third party on Feb. 26, 2009.
66Emergency Employment of Army and Other Resources—Emergency Operations Center Standard Operating Procedures (HQUSACE-EOCSO), OM 500-1-5, Appendix C, 1994.
67Exclusive ProLiant 5000, Oct. 20-Nov. 12, 1996; 1 page.
68Exclusive: Shogun SMP server, Sep. 6-19, 1995 (obtained from National Research Council Canada facsimile dated Oct. 15, 2008) 4 pages.
69Fontana, J., "WorldTalk Secures E-Mail Servers", CommunicationsWeek, Jun. 30, 1997, pp. 1-2.
70Gaines, B. "Supporting Collaboration through Multimedia Digital Document Archives", Version 1.0, Nov. 1994, pp. 1-53.
71Gale Group Computer Evaluation "Four anti-virus products get the bugs out", Oct. 6, 1997, pp. 1-7.
72Gale Group Computer Product Announcement "Anti-virus-Intel meets virus challenge, lowers total cost of PC networks", Nov. 18, 2006; 2 pages.
73GlobalKey Inc. "GlobalKey Secure E-Mail Plus", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
74GlobalKey Inc. "GlobalKey's Suite of Products and Services", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
75Integralis Announces MIMEsweeper Compatible with Check Point FireWall-1 on Single NT Server, Kirlkland, WA Sep. 16, 1996.
76Integralis Asia Pacific, "Total Email Content Management Countering Email Borne Threats," White Paper MIMIsweeper, Jan. 1996, pp. 1-12.
77Integralis Ltd. "Administrator's Guide Version 3.1", 1997, pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
78Integralis Technology Ltd. "For FireWall-1 Administrator's Guide Version 1.0", Revision 1.0, 1997, pp. 1-3.
79Integralis UK "Security Solutions Index", 1 page, publication date unknown, received from third party on Feb. 26, 2009.
80Integralis White Paper MIMEsweeper Total Email Content Management Counting Email borne threats, Jan. 1996, pp. 1-12.
81Key Recovery Alliance "Business Requirement for Key Recovery Draft 2.1", Sep. 4, 1997, pp. 1-16.
82Kohno, Masaru; Takano, Kazuo; Yoshida, Kazuki and Ogata, Tsutomu, Deterioration Forecast of Sealed Lead-Acid Batteries by Discharge of Short Time, Shingaku Sogo Taikai B-477, 1996.
83Levien, Ralph, Protecting Internet E-Mail From Prying Eyes, Data Communications, May 1996, pp. 117-126.
84Machlis, S., Computerworld "Check Point makes firewall security's Grand Central", Apr. 21, 1997, 1 page.
85Matunaga, Yasuhiko and Sebayashi, Katsuhiro, Adaptive Route Filtering for the Stable Internet Routing, NTT Multimedia Networks Laboratories, Tokyo, Technical Report of IEICE SSE 97-5 (Apr. 1997).
86McNamara, P. "Worldtalk tool to thwart e-mail threats", Network World, Jun. 23, 1997, p. 47.
87Messmer, E. "Check Point adds fuel to firewall", Network World, Oct. 28, 1996, p. 37.
88Messmer, E. "Intranets & the 'Firewall 'checks' out ODBC data", Network World, Nov. 25, 1996, p. 33.
89Messmer, E. "Intranets & the 'Firewall ‘checks’ out ODBC data", Network World, Nov. 25, 1996, p. 33.
90MIMEsweeper "5 Content security-Table of Contents", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
91MIMEsweeper "6 Management-Table of Contents", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
92MIMEsweeper "Configuring MAILsweeper for SMTP", pp. 1-4, publication date unknown, received from third party on Feb. 26, 2009.
93MIMEsweeper "Evaluating Email Anti-Virus Solutions", pp. 1-4, publication date unknown, received from third party on Feb. 26, 2009.
94MIMEsweeper "MAILsweeper Table of Contents", pp. 1-6, publication date unknown, received from third party on Feb. 26, 2009.
95MIMEsweeper "MIMEsweeper Downloads", 1 page, publication date unknown, received from third party on Feb. 26, 2009.
96MIMEsweeper "MIMEsweeper Frequently Asked Technical Questions", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
97MIMEsweeper "MIMEsweeper Review Business Computer World-How can you protect against viruses?", Dec. 1996, pp. 1-2.
98MIMEsweeper "MIMEsweeper Review PC User-Combat e-mail viruses and spies", Oct. 1996, pp. 1-2.
99MIMEsweeper "MIMEsweeper Review Secure Computing-MIMEsweeper-Secure Computing's Editor's Choice", Sep. 1996, pp. 1-2.
100MIMEsweeper "MIMEsweeper Table of Contents", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
101MIMEsweeper "5 Content security—Table of Contents", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
102MIMEsweeper "6 Management—Table of Contents", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
103MIMEsweeper "Email Content Management and Control", pp. 1-4, publication date unknown, received from third party on Feb. 26, 2009.
104MIMEsweeper "MIMEsweeper Review Business Computer World—How can you protect against viruses?", Dec. 1996, pp. 1-2.
105MIMEsweeper "MIMEsweeper Review PC User—Combat e-mail viruses and spies", Oct. 1996, pp. 1-2.
106MIMEsweeper "MIMEsweeper Review Secure Computing—MIMEsweeper—Secure Computing's Editor's Choice", Sep. 1996, pp. 1-2.
107MIMEsweeper 2.0 Press Release "Integralis releases MIMEsweeper Version 2.0 with SMTP mail security support", Jan. 15, 1996, pp. 1-2.
108MIMEsweeper, Total Email Content Management Countering Email Borne Threats, White Paper Jan. 1996.
109National Software Testing Laboratories "NSTL Final Report for Trend Micro Incorporated Comparison Testing of Anti-Virus Products", Jun. 1997, pp. 1-13.
110Net PC, Feb. 1997, pp. 158-163.
111Network Associates Product—Security "PGP Enterprise Security Suite", pp. 1-11, publication date unknown, received from third party on Feb. 26, 2009.
112New Products-MIMEsweeper 2.3-2, "Combat e-mail viruses and spies", Oct. 30-Nov. 12, 1996; 1 page.
113NH&A anti-virus, security & network management "Who we are", pp. 1-5, publication date unknown, received from third party on Feb. 26, 2009.
114NHA "Frequently Asked Questions", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
115NHA "Lexical Analysis in MIMEsweeper", pp. 1-4, publication date unknown, received from third party on Feb. 26, 2009.
116NHA "MIMEsweeper 'Online' SPD", pp. 1-9, publication date unknown, received from third party on Feb. 26, 2009.
117NHA "MIMEsweeper ‘Online’ SPD", pp. 1-9, publication date unknown, received from third party on Feb. 26, 2009.
118Nikkei Open Systems, No. 52, Jul. 1997, pp. 316-346.
119Notice of Opposition filed in EP 1750384 on Jun. 25, 2010, 255 pages.
120OpenSoft "OpenSoft Certificate Server Massively Scalable Certificate Distribution System for the Internet", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
121OpenSoft "OpenSoft ExpressMail (tm) Server High Performance Internet Messaging Server", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
122OpenSoft "OpenSoft ExpressMail 32-bit client", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
123OpenSoft "OpenSoft ExpressMail User Manual Client User's Guide Table of Contents", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
124OpenSoft "OpenSoft ExpressMail User Manual Running ExpressMail Server", pp. 1-4, publication date unknown, received from third party on Feb. 26, 2009.
125OpenSoft "OpenSoft ExpressMail User Manual Server Administrator's Guide Table of Contents", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
126OpenSoft "OpenSoft ExpressMail User Manual Setting Up ExpressMail Server", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
127OpenSoft Corporation "Now you can safely order online!", Dec. 31, 1996, pp. 1-2.
128OpenSoft Corporation "OpenSoft and VeriSign Announce Strategic Partnership to Provide Customers With S/MIME Solution", Apr. 22, 1996, pp. 1-2.
129OpenSoft ExpressMail User Manual "Server Configuration", pp. 1-14, publication date unknown, received from third party on Feb. 26, 2009.
130Pollock, Stephen, A Rule-Based Message Filtering System, ACM Transactions on Office Information Systems, vol. 6, No. 3, Jul. 1988, pp. 232-254.
131Press Release "OpenSoft and VeriSign Announce Strategic Partnership to Provide Customers with S/MIME Solution", Apr. 22, 1996, pp. 1-2.
132Press Release, Integralis announces version 2.3 of MIMEsweeper with new email security features, Jun. 13, 1996 (document apparently received from 3rd Party and apparently printed Jun. 8, 2004), 2 pages.
133Press Release, Integralis releases MIMEsweeper Version 2.0 with SMTP mail security support, Jan. 15, 1996 (document apparently received from 3rd Party and apparently printed Jun. 8, 2004), 2 pages.
134Rodriguez, K., Deming Software "Secure Mail Spec Gets Boost-Secure MIME will soon see broad industry support", Apr. 8, 1996, pp. 1-2.
135Rodriguez, K., Deming Software "Secure Mail Spec Gets Boost—Secure MIME will soon see broad industry support", Apr. 8, 1996, pp. 1-2.
136RSA "Ciphertext, the RSA Newsletter", vol. 3, No. 1, Fall 1995, pp. 1-8.
137RSA "S/MIME Central General Information", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
138RSA Data Security Inc. "Develop industry-standard secure, interoperable electronic mail applications", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
139RSA Encryption Inc. "Data Security, Inc. Pressbox", Nov. 1996, pp. 1-7.
140S. Kent, Privacy Enhancement for Internet Electronic Mail: Part II: Certificate-Based Key Management, Network Working Group, Request for Comments 1422, Feb. 1993, pp. 1-33.
141S/MIME Arrives! ConnectSoft E-Mail Connection 3.0 Ships, May 14, 1996, pp. 1-2.
142Schaff, W. "Commercial Firewalls-A Burning Commodity", InformationWeek ,Dec. 9, 1996, p. 120.
143Schaff, W. "Commercial Firewalls—A Burning Commodity", InformationWeek ,Dec. 9, 1996, p. 120.
144Serenelli, Bob and Leisher, Tim, Securing Electronic Mail Systems, MILCOM 92, 677-680, 1992.
145Smith, Randal, E., A Secure Email Gateway, Computer Service Applications 10th Annual Conference, 202-211, 1994.
146Smith, Richard E., Constructing a High Assurance Mail Guard, Secure Computing Reprint Series, 1994.
147Smith, Richard E., Constructing a High Assurance Mail Guard, Secure Computing, San Jose, California, 1994.
148Supplemental European Search Report for App. No. 989390978.6 dated Jun. 30, 2005.
149Technical FAQ "Technical Note—How can MAILsweeper inform multiple addresses?", 1 page, publication date unknown, received from third party on Feb. 26, 2009.
150Technical FAQ's "Updates and Patches", 3 pages, publication date unknown, received from third party on Feb. 26, 2009.
151Tong, Fangwei; and Yoshihiko, Akaiwa, Residual Timing Error Dependence on Weighting Parameters for Autonomous Timing Synchronization Methods; Kyushu Institute of Technology, Shingaku Sogo Taikai, B-477, 1995.
152Trend Micro "ScanMail for Lotus Notes-Keeps viruses out of your Lotus Notes environment", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
153Trend Micro "ScanMail for Lotus Notes—Keeps viruses out of your Lotus Notes environment", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
154Trend Micro Inc. "ScanMail & the Epidemiology of E-mail Virus Outbreaks", Mar. 30, 1996, pp. 1-4.
155Trend Micro Inc. "ScanMail for cc:Mail, a client-side virus protection software that detects and cleans viruses attached to e-mail messages Product Specification", pp. 1-4, publication date unknown, received from third party on Feb. 26, 2009.
156Trend Micro Inc. "Trend Micro Sues Integralis for Gateway Anti-VirusPatent Infringement", Jul. 8, 1997, pp. 1-2.
157Trend Micro Incorporated "Viruses and E-mail", Jun. 1996, pp. 1-22.
158Trend Micro Press Release "Trend Micro Announces Virus Protection for Microsoft Exchange Server", Nov. 6, 1996, pp. 1-2.
159Trend Micro, Inc. "Anti-Virus for the Enterprise, Corporate Overview-Company profile", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
160Trend Micro, Inc. "Antivirus, About Trend-Analyst", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
161Trend Micro, Inc. "Antivirus.com-Press Releases", May 14, 1997, pp. 1-2.
162Trend Micro, Inc. "Anti-Virus for the Enterprise, Corporate Overview—Company profile", pp. 1-2, publication date unknown, received from third party on Feb. 26, 2009.
163Trend Micro, Inc. "Antivirus, About Trend—Analyst", pp. 1-3, publication date unknown, received from third party on Feb. 26, 2009.
164Trend Micro, Inc. "Antivirus.com—Press Releases", May 14, 1997, pp. 1-2.
165WebShield "Secuire Internet Gateway Virus Protection", pp. 1-5, publication date unknown, received from third party on Feb. 26, 2009.
166WebShield "Secure Internet Gateway Virus Protection", pp. 1-5, publication date unknown, received from third party on Feb. 26, 2009.
167Windows NT vs X, Interface, May 1994, pp. 203-212.
168Wingfield, N., "Checkpoint Software touts FireWall-1 for VPNs", InfoWorld, Sep. 25, 1995, p. 71.
169Worldtalk Press Release "Worldtalk to Acquire Deming Software", Nov. 12, 1996, pp. 1-3.
Classifications
U.S. Classification726/14, 713/152, 713/156, 713/154, 726/11
International ClassificationG06F21/00, H04L9/00, H04L12/58, G06F13/00, G06F9/00, H04L12/22, G06F1/00, H04L29/06, H04L9/14
Cooperative ClassificationH04L12/583, H04L51/12, H04L63/0227, H04L12/585, H04L63/0428, H04L63/0263, H04L9/30, H04L51/063, H04L63/0464, H04L12/587, H04L63/0245, H04L2209/76
European ClassificationH04L12/58F, H04L9/30, H04L63/02B2, H04L63/02B, H04L63/04B, H04L51/12
Legal Events
DateCodeEventDescription
Aug 7, 2012CCCertificate of correction
Jan 6, 2009ASAssignment
Free format text: MERGER;ASSIGNOR:TUMBLEWEED COMMUNICATIONS CORP.;REEL/FRAME:022062/0244
Owner name: AXWAY INC., ARIZONA
Effective date: 20081230
May 29, 2007ASAssignment
Owner name: TUMBLEWEED COMMUNICATIONS CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WORLDTALK CORPORATION;REEL/FRAME:019426/0086
Effective date: 20000526
Owner name: WORLDTALK CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DICKINSON, ROBERT D. III;KRISHNAMURTHY, SATHVIK;SIGNING DATES FROM 19981016 TO 19981021;REEL/FRAME:019425/0817