GB2317793A - System and method of electronic mail filtering - Google Patents

Abstract

A modular system and method for filtering electronic mail messages is described. A message is received and processed through a one or more filter flows. Each filter flow includes one or more self-contained nodes which can be interconnected in whatever order is required to enforce a given security policy. The available nodes include filters, modifiers or terminals. Node independence provides a policy-neutral environment for constructing filter flows, and components are easily rearranged to change policy. A filter flow may be as simple as forwarding the mail to the intended recipient, or may perform one or more checks where it decides whether to forward, reject, ram (or some combination thereof) the message. Certain node types are also able to append information on to a mail message, while others are able to modify certain parts of a mail message. Certain node types are able to generate audit or log messages in concert with processing a mail message. A graphical user interface creates and maintains the filter flows, Figs. 8A, 8B, (not shown).

Description

1 2317793 SYSTEM AND METHOD OF ELECTRONIC MAIL FILTERING A portion of the

disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosure, as it appears in the Patent and Trademark Office patent flies or records, but otherwise reserves all copyright rights whatsoever.

Background of the Invention

Field of the Invengon

The present invention relates to computer security, and more particularly, to an apparatus and method for managing electronic mail message processing.

Backupund Information Electronic mall is becoming a more integral means of communication for everything from students exchanging messages with each other and their teachers to highly sensitive business and governmental communications. Communication technology has expanded to where anyone with a personal computer, mu ='al software and a modem can connect to the Internet and send mail to any other computex, whether it is across the street or around the world. Bemuse anyone can send mail to anyone else, many sites have begun establishing security policies which specify how mail sent to and received from exlernal locations should be handled. These sites use mail messsaging systems to analyze incoming and outgoing messages and determine whether information concerning the message should be recorded or reviewed, or whether the message should be allowed to be delivered at all.

Evcry customer has different needs. Commercial security policy different for different business types and installations, and different from ' government and educational institution needs. To date, however, conventional systems have implicit assumptions about the security to be enforced built in, based on the rules of the security policy to be enforced. Thus, where a site is big 2 enough to have departments with different needs, or where one filter is being developed for a number of clients, either a separate system must twe. developed and installed for each siteldepartment, or the system must be written to enforce the lowest common denominator of the rules specified by each siteldepartment.

In addition, systems constructed to date often require an independent computer system located such that all mail passing between external and internal locations passes through the filter system. Such systelns typically are limited to looking for a specified set of keywords, malcing processing decisions based on whether the keyword is present or missing, depending on the rule.

Finally, conventional systems provided to date are only capable of a yes/no decision, providing only one option at each decision point. The message (or response to the message) must go down only one path forwarded to the destination, returned to the source, or rerouted to a different destination.

What is needed is functionality supporting multiple addresses for a single message. It is therefore difficult to implement a policy ot for example, forwarding questionable messages on to their original destination but also forwarding a copy to an internal auditor or logging system. Conventional systems cannot support this ement.

What is needed is a way of structuring an electronic mail messaging system that is flexible enough to implement a variety of security policies but which is also simple for a network administrator to configure. Such a system would preferably provide multiple routing paths form each decision point.

Summary of the Invention llie present invention is a system and method for filtering electron ic mail messages. A message is received and processed through a one or more filter flows. Each filter flow includes one or more self-contained nodes which can be combined in whatever order is required to enforce a given security policy. Node independence provides a policy-neutral environment fbr connmcting filter flows. A filter flow may be as simple as forwarding the mail to the intended recipieni or may perfonn one or more checks where it decides whether to forward, reject, return (or 3 some combination thereof) the message. Certain node types are also able to append information on to a mail message, while others are able to modify certain parts of a mail message. Certain node types are able to generate audit or log messages in concert with processing a mail message.

The result is a generalized, modular system for building mail filter flows. The filter system of the present invention is policy neutral - any one flow enforcing a particular security policy is constructed where necessary. The same components can be rearranged to enfbrce a different policy without reprogamming any of the individual modules.

According to one aspect of the present invention, electronic mail messages are filtered by receiving a message, analyzing whether it meets the filter criteria and forwarding the message to the filter if it meets the filter criteria. The message is delivered if it does not meet the criteria.

According to another aspect of the present invention, the filter analyzes. the electronic mail message, and based on its characteristics either delivers or rejects the message. In addition, the filter may generate an audit message in conjunction with the results of the analysis.

According to another aspect of the present invention, an electronic mall filter includes an analysis module for analyzing the mail message using one or more individual filter nodes and an output module for generating a plurality of output messages based on the analysis of the analysis module. ]be available filter nodes include a filter, a modifier, or a terminal. The mail filter may also include a graphical user interface for creating and maintaining the electronic mail filter.

Brief Description of the Drawings

Figure 1 shows one example of a flow configuratiOIL Figure 2 is a block diagram showing one embodiment of a mail filter incorporated into a mail framework Figure 3 shows the main components of a mail filter node according to one embodiment of the present invention.

Figure 4 is a graphical representation of an extensible data object tree.

4 Figure 5 shows a simple example of a terminal Output module.

Figure 6 shows an example of a filter module.

Figure 7 shows an example of how components may be wired together to create a filter flow in the mail framework of the present invention.

Figure 8A is a representation of the mail filter map maintenance window presented by the user interface.

Figure 8B is a representation of option windows presented by the user interface.

Figure 9 presents an example of the specification ofa filter flow using the flow language.

Figure 10 is a graphic representation of sample flow rules.

Fig= 11 illustrates a filter map where there is a separate auditor for each filter.

Figure 12 illustrates a filter map where two different filters use the same auditor.

Figure 13 shows an embodiment wherein rcjections from multiple filters are sent to the same auditor via a single terminal.

Figure 14 shows an instance where rejects are passed forward and audits go to a shared auditor.

20. Figure 15 shows an embodiment of a filter flow where separate auditors are used and rejects are passed forward.

Figure 16 illustrates a map example using the same auditor and passing rejects forward.

Figure 17 shows a filter map combining the ideas presented in Figures 11-16.

Figure 18 shows an example a conventional method of at a rejection reason to messages.

Figure 19 shows an example an expanded method of attaching a rejection reason to messages according to one embodiment of the present invention.

Detailed Description of the Preferred Embodiments

In the following Detailed Description of the Preferred Embodiments, reference is made to the accompanying Drawings which form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. It is to be understood that other ernbodiments may be utilized and structural changes may be made without departing from the scope of the present invention.

There are two aspects of mail filtering. First is what to filter, the second how to filter it. The first question is answered by one embodiment of the present invention in the "mail filter policy" file. This simply lists "burb" pairs which should be filtered. A burb refers to one protocol stack in an environment providing network separation by keeping separate protocol stacks or regions for each side of the system. A more detailed description of burbs is given in "System and Method for Achieving Network Separation"by Gooderum et al.

(PCT Published Application No. WO 97129413, published on August 14, 1997), the description of which is hereby incorporated by reference. Under network separation, a plurality of burbs or regions is defined. Each burb includes a protocol stack. Each of the plurality of network interfaces is assigned to one of the plurality of burbs and more than one network interface can be assigned to a particular burb. Processes are bound to specific burbs when they try to access that burb's protocol stack and communication between processes assigned to different burbs is restricted. Routing to a given stack may be limited to being done at the very top or bottom of the dataflow so that a given pack^ piece of data, control message, etc. is bound to a particular stack at creation.

lle mail filter policy file is used by a mail delivery agent to determine whether to pass mail on to the next burb or to drop it into a queue.

Listed burb, pairs are filtered and unlisted pairs are relayed to the destination burb. This file is read by the a mail queuing program for =h delivery, so it is kept deliberately minimal to reduce overhead. The filter policy is described in greater detail below.

6 The second question, how to filter mail messages, is relevant to the programs which run the mail queues. These are long running daemons, so it is not a problem if they have some additional startup overhead. Filter configuration is also discussed in greater detail below.

The flow configuration is in a file and comprises a simple listing of burb pairs and a map name. This is configurable by the mail administrator and the system administrator under the operational kernel. This file must exist at ation time and be added if a system is upgraded. Initially no flows will be listed, but may be added at any time by the adminr. If the file is missing, the mail queue program will not deliver mail and will return an error to the sendmail application that invoked it. The convention for keeping read- only skeleton files around should be adhered to for this file. An example of a flow configuration is shown in Figure 1, where each filter flow line 10 maps a burb pair to a map name 12.

is In one embodiment, the filter parent daemon is a tiny program that creates a pidllock file and then executes filter queue runner programs. Whenever one of the top level configuration files is altered, this process should be signaled. It will then signal or restart its children as appropriateA program responsible for queuing mail will be a run by sendmail with source and destination burb parameters on the command line. The queuing agent will be a gate executable. Its effective domain (nique) will permit it to write the file into the queue directory. By being a gate, it will be able to check the real domain, which will be that of the parent sendmail process. It will check that the source burb parameter matches the sendmail source burb. If they disagree, then there is a configuration effor or sendmail has been subverted. In either case the queue agent will audit and exit. If there are no startup problems, the queue agent will receive the message via SMTP over stdin/stdout. SMTP support will be the minimal necessary to receive the message from a properly configured sendmail process on the local system.

A long-running daemon is responsible for processing the mail for a given flow. The daemon is controlled by the filter parent. It does not read the 7 policy file, but rather just looks at its command line for the burbs to use (for sender and recipient), the map file to use, and the queue directory in which to function. In one embodiment, the command line is formatted in the following manner.

lusrAibexerJmfit_queue_runner <src-burb>,cdest-burb> <queue-dir> <mapfile> [-d high"rlawn Filter configuration needs to be as flexible as possible so as to allow future growth. This is good, however, because filter configuration can become one of those features with many facets that are visual and easy for nontechnical people to understand. Filter administration starts with a configuration file which identifies filter components, how they are chained together, and where the configuration information for each instance is located. Components include terminal output modules, data modifiers and filtering modules.

The electronic mail system, or "mail framework", is a collection of independent objects or "nodes" which can be arranged into one or more filter flows (or filters) to describe/enforce any security policy. Figure 2 is a block diagram showing one embodiment of such a filter 220 incorporated into mail framework 200. Filter 220 can be expressed as an interconnected series of nodes. In one embodiment, there are three general node types: a fitter, a modifier, and a terminal. The node types are. described in greater detail below. Each node in filter 220 comprises three components: initialization, message processing, and node clem-up. According to one embodiment, shown in Figure 3, each node is composed of three basic sections 310, 320, 330 which all exist within the same process. Each section provides a distinct set of functions. Initialization module 3 10 provides the initialization functions, including loading a configuration file which contains any configurable settings for the node. Examples of various configuration files are presented later in the discussion of each node type. Message analysis module 320 provides the operational fimctions of the node- llese functions may include receiving the message, applying the filtering algorithm to the message, and preparing and transmitting the results of the node's processing. Clean-up module 330 comprises Rmctions 8 which clean up and shut down the node when it ceases processing. These functions ensure that the system within which the node is executing is left in a good state. This provides a well-defined boundary between any two nodes, ensuring maximum security.

Mail framework 200 is intended to support the development of a mix-and-match set of filters which can be chained together according to the whim of the administrator. At the same time, the data structures must be flexible and expressive so that sophisticated filters may be constructed. In one embodiment, the implementation is further constrained, using C rather than a more expressive language like C++ or Sather, in order to achieve greater processing speed. The extensible data structure (edo) shown in Figure 4 is an attempt to create such a data structure. The edo essentially creates a shallow class hierarchy with a common base class and simple up/down casting.

An edo is a standardized simple data structure with certain guaranteed features which can be expanded upon for application-specific uses.

A base set of edos are always available and are suitable for simple text or byte data filters. More sophisticated filters may be constructed to use specialized edos with extra application-specific information.

The type cdo-t is, conceptually, an abstract base class. It provides the cornyn on interface to all of the edo data structures. Figure 4 shows the conceptual class hierarchy. The first field of the edo base 410, embodying the cdot type, is an enumerated integer value indicating the data type. All edos must have the same three fields at the start of the structure. This group of fields may be partially iriterprcted as a bit mask. Bit one is compatible with edo-bytes, and is set if it is a "byte buckeC. The bit mask intexpretation is not entirely consistent with respect to casting, due to the limitations of trying to do this in the C progranuning language. The second field of the edo base is a state field which is filled in by the filtering functions. lle state field indicates whether the edo has been rejected by a previous filter. Other bits indicate if the edo was deemed suspicious or if it was edited by a filter. Neither the suspicious or edited states are exclusive of the bucket being considered 'okay' or 'rejected'. A bit mask can 9 be used to pull out the pieces considered important for filter or modifier node prowssing. Filter and modifier nodes may ignore the state field or skip processing rejected data nodes, depending on their purpose. The third Beld of any edo node is a pointer to a "copy constructor". This is a function that can duplicate the node, given a pointer to itself. The forth field is a pointer to a "destructoil' function which can delete the node and free up all dynamically allocated memory. Convenience macros are provided for calling these member functions. As an example, for a given edo V, these would be invoked as:

copy_edo (e); 10 and delete-edo (e); lle bytes edo 420 section is a simple 'bucket of byte? suitable for many filtering operations. It is a dynamically allocated array of bytes which may be searched and added to by filter or modifier nodes. This is where the actual message is located. A filtcr or modifier node which alters the data is permitted to use standard system calls (such as 'rcaIloco') to resizc bytes edo array 420 if needed.

lle data edo 430 section is a metadata section which allows annotation and additional data to be added to the original message. It is a byte bucket with a collection of edos which may he searched and added to by filter or modifier nodes. Data edo 430 is derived from a bytes edo 420, and contains the annotations appended by the filtcr or modifier nodes. Such annotations may include information which carries parsed data (which, for example, identifies the message sender or recipient), or perhaps the rejection reason if the message failed a filter. Filter or modifier nodes knowledgeable of the various types of optional data (which are also represented as edos) may draw on this knowledge for additional wntext. Simpler filters can ignore the collection and may even process an data edo section 430 as a bytes edo section 420, which is effectively its base class.

71e network edo 450 is a data EDO with some additional context describing the data which is being dperated on by the filter or modffier nodc. It includes the source and destination address of the data. Both, one, or neither of the addresses may be an address of the machine on which the mail framework resides, depending on where the client and server processes are located. This information is obtained from the socket which was the sourm of the data (getpeernameo, getsockname()). Indexes for other physical and logical portions are also included with the address. Use of the extra information in network edo 450 may provide for better filtering.. but not all data sources will be associated with a network. In addition, electronic mail filtering may be also done on files rather than on network connections.

The collection EDO 440 is derived from the base EDO 410, to which it adds pointers to three additional functions. These functions provide a simple random access data structure for storing edo pointers and indexing them by keyword. One fimction will add an (edo, keyword) pair (tuple) to the collection. Keywords must be unique within a collection. The second function will find an edo in the collection based on the keyword, and the third function will remove an edo from the collection, based an the keyword. An edo collection is used as a field in the data and network edo types 430, 450. The anticipated use of the edo collection 440 is as a means for carrying a set of annotations along with the data portion of a message. For example, one filter might parse out the headers from an electronic mail message. Other filters could then look up the headers in the annotation and could grade the headers without being smart enough to parse them frorn the rest of the message. This supports using filter sequences for a stream processing-based programming paradigm.

The binary filter expects the entire content of the message to be contained within the Bytes 410 section of tile EDO 400. The actual binary filter is called once for each EDO Bytes section 410. The entire contents of the Bytes' section 410 is treated as a single message by the binary filter. This approach cannot guarantee that any specific e-mail message will be caught, but will, however, catch the widest variety of violators with a single algorithm. This generalized approach improves over conventional systems in other aspects as well. Since the binary filter approach is not format-specific it is much rnore 11 difficult to break. Format-specific systems follow the rules of the format and thus it is much easier to avoid detection by imitating the format. In addition, file formats not previously encountered are still likely to be detected in a binary filter system.

The programming interface also identifies the range of node behaviors. In one embodiment, it is the programming interface which enforces the one input, oneltwo output rule followed by every filter node. This rule is strictly enforced in order to maintain the rigor of the system. Such an approach does not however, limit the functionality of the system appreciably. If.a more complex decision tree is required to enforce a particular rule, the tree can be constructed by chaining a series of modules. This is preferable over building complex nodes for two reasons. One is because the individual nodes retain their independence and remain policy-neutral. The other is because the flow is easier to maintain and modify in the case of future policy changes. It is the programming interface which also supports the feature that any one output can be directed to one or more inputs. The programming interface is implemeuted in the C++ prograrmning language, but the filter nodes can be impleniented in C.

The edo data structure described above enables the flexibility in the filter nodes which would otherwise be unavailable in a procedure written in C.

All of the nodes allow additional interactions with applications external to the mail system for other than mail processing flmctions. For example, a filter node may read initialization data from an external file, or write a message to a log or audit file. The inputloutput limitations imposed by the programming interface apply only to the direct interactions between filter nodes.

Mail Filter nodes are made operational in one of three ways. In one embodiment, the nodes are all compiled into a single library. In this embodiment when an node is called the subroutine in the library is executed.

This is the best-performing form. However, it creates some security issues because all of the nodes are in the same library. To better secure die mail filter system the nodes can each be compiled individually. This form loses some perforniance speed, because each filter node module is brought into memory 12 when it is called, rather than having all of them in memory after the system is initialize. However, separation is maximized, providing the best protection against being able to attack one module via a less- protected module. lle third embodiment is a compromise between the two previously described. In this embodiment a shell for each filter node is compiled into a common library, but instead of the library subroutine executing the filter module code, it calls an external program. This gives back some of the speed lost when the modules are completely independent, without completely sacrificing the concept of isolating the modules.

The mail filter framework of the present invention does not completely handle mail in different formats, The same programming interface code can be used for the structure underlying filter flows for different formats. In another embodiment, a common mail filter system may be used as a preprocessing step to enable common processing. In this embodiment the filter flow(s) are used to identify which part of the message to use, andlor to direct the message to the proper application for further processing. This limitation is acceptable. because it is desirable to stay with a configurable signal which can be universally used. If the signal is made aware of a specific protocol (for example, SMTP, X.400, etc.), the mail filter system is implicitly unable to process other protocols.

Filtering modules accept one input and generate two outputs. One output is the input edo, possibly with modifications. This output is directed to the next module based on the edo's filter-filter resultflield. A filtering module is visualized as having two outputs, one for PASSed edos and one for REJECTed edos, each of which may be separately routed to other components. Figure 5 shows an example of a terminal output module 500 and Figure 6 shows an example of a filtering module 600. A filter node accepts the input as representing a complete entity. Filter components may be combined to form a compound object, which may then be used as a filter module or a terminal output module.

13 The configuration file is meant to be very flexible and extensible. The queue runner programs should be able to accommodate this. It is desirable, but not required to make this flexibility available to the user. Fi".e 7 shows an example of how components may be wired together to create a filter flow in the mail ftarnework of the present invention. The graphical user interface (GUI) should take inspiration from programs like LabViewl, Khoros, IRIS' Explorer', AVS' and the like. Examples of these products are available on the Internet at the following URLs:

Khoros screen shot: http: IN. khoros. unm. edulkhorosiscreen. jpg general information on Khoros: http:llwww.khoros.unm. edulkhorosJkhoros21home.html AVS screen shot http: /.avs.comfproductsirerTLsense2. gif general information on AVS: http: IN. avs. comf is Another embodiment of the present invention comprises a graphic interface for constractir and maintaining mail flows within the mail framework. Figure 8A is a representation of one embodiment of the flow edithig screen 800. The flow editing screen includes a pick list of the node types (connector 80 1, terminal 802, modifier 803, and filter 804) available to include in the filter floM and a window or "canvas" 805 for graphically constructing each filter flow. The administrator selects one or more filter nodes 802-804 and locates them on canvas 805 in the order in which messages are to be processed. The nodes are then connected using the connector icon 801 to show the channels 841, 843, 845. 847, 849 for the input and output(s) for each node. An additional menu window 25, shown in Figure 8B, provides, for example, a window for defining and maintaining individual nodes 860 and filter maps 862. Each node is given a urdque name, and its characteristics (such as how it pro"ssed each input message) are defined or modified using these menus and windows 80 1.

References in the description of the mail framework of the present invention imply assumptions about how the information will be displayed and manipulated. These are not to be interpreted as requirements, but rather as a 14 reflection of one embodiment of how mall framework is implemented and of the associated interfaces.

A filter flow is build up in a simple language. It consists of simple object types, configurations of those types, aggregate objects and objects that form associations between other objects. In the actual implementation this is all represented in a configuration file, but at this point it will be described at a more abstract level.

Some of the objects (or their identifiers) described here will be directly visible and manipulated by the administrator through the GUL Other objectswhich are less directly visible are manipulated via a graphical metaphor and are created and destroyed on the fly by the GUI, as needed, to organize the objects. The visual program that is built up out of these objects may be referred to as a map, All visible objects in a GUI map editor are "drains ". Drain objects, and their identifiers, are created dynamically (except confi gured terminals, which can be used as-is) when the user selects a configured object and drags it onto the canvas. As the system expands, there will be more kinds of filters, modifiers and terminals, but the underlying logical structure should not change. The GUI is designed such that it can be expanded to support configuring instances of new primitives, but will it will support programming the new primitives into a new map without any changes.

Figure 9 presents an example of the specification of a filter flow using the flow language. The specification includes such information as the available node types 910, 920, 930. In practice a filter flow specillcation is written with syntax consistent with the configuration file formats used by the system upon which the mail structure is operating. Table 1. below, shows the sample flow rules graphically presented in Figure 10.

is Table 1: Sample Flow Rules node statement

L user-termlnal-id K useLterrninai-id j drairijilter (user-filter-id, 1KI, ILD 1 useLterminaUid H drair_fiher (userfifter-id. [q. [J]) G drain-list (H) F user-terrninal-id E user terminaLid 0 us&-terrrdnaljd c use_terminaijd drain-fitter (use_fifter ld. [C], IC,GJ) A drain---filter (use_fiiteLid, [B1, [D.EF]) When trying to convert a graph into a symbolic represcritation, it is simplest to label all of the nodes and then work from the leaves up towards the root For cxample, to convert Figure 7 we would first label the figure, as in Figure 10. Note that nodc 0 1030 is really superfluous, and could be eliminated if one wanted to minimize the nodes. It is however, valid, and perhaps useful. to build the map up through layers. A message comes into node A 10 10 which is a filter, If the message passes the filter it is forwarded on to node B 10 15, which is also a filter. If the message fails node A 1010, an audit is forwarded to terminals D 1025, E 1040, and F 1045. If the message passes node B 10 15 it is forwarded an to node C 1020, which is a terminal in this example. If the message fails filter B 10 15, however, it is still forwarded to node C 1020. In addition, an audit is also forwarded to node G 1030, which in one embodiment is simply a terminal. In another embodiment node G 1030 is actually another filter flow.

The audit received by node G 1030 comes into node H 1032, which is a filter. If the information comprising the audit passes the filter then information is forward to terminal node 1103 1, otherwise an audit is forwarded to filter node J 1033. If the audit information passes that filter 1033, information is forwarded to terminal 16 node K 1034. Otherwise, an audit is forwarded to terminal node L 1035. As this example shows, the various nodes can be combined to form filter flows of any level of complexity. The above examples are offered for illustration and are not intended to be exclusive or limiting.

For a given message, each terminal in a map will only be activated once. This principle governs when audit messages are combined into a composite rejection message and when multiple notifications get sent to the same destination. Failures and rejection reasons do not carry forward through filters. Figure 11 illustrates a filter map where there is a separate auditor for each filter. For the map shown in Figure 11 rejections from the key word search filter 1110 will be sent to Auditor A 1140. Messages that pass the key word search filter 1110 will go to the binary filter 1120. Rejections from the binary filter 1120 will be senito Auditor B 1150. Messages that pass the binary filter 1120 will be delivered 1130.

Figure 12 illustrates a filter map where two different flit= use the same auditor. For the map in Figure 12 rejections from the key word search filter 1110 will be sent to Auditor A 1140. 1. Messages that pass the key word search filter 1110 will go to the binary filter 1120. Rejections frorn the binary filter 1120 will also be sent to Auditor A 1140.2. Messages that pass the binary filter 112 0 will be delivered 113 0. Note that auditor A nodes 1140.1 and 1140.2 are individual terminals which direct rejections to the same destination. Figure 13 shows an embodiment wherein rejections frorn multiple filters 1110, 1120 are sent to the same auditor via a single terminal 1140. For the map in Figure 13 rejections from the key word search filter 1110 will be sent to Auditor A 1140.

Messages that pass the key word search filter 1110 will go to the binary filter 1120. Rejections from the binary filter 1120 will also be sent to Auditor A 1140.

Messages that pass the binary filter 1120 will he delivered 1130. This effectively yields the same results as the map shown in Figure 12. It should be noted that in order to yield cxactly the swne results a message passing through filter 1120 would have to carry with it the rejection message generated by filter 1110.

17 Figure 14 shows an instance where rejects are passed forward and audits go to a shared auditor. According to the map in Figure 14 rejections from the key word search 1110 and binary 1120 filters will be sent to Auditor A 1140.

All messages will go to the binary filter 1120. regardless of whether they pass or fail the key word search filter 1110. If a rnessage fails the key ward search filter 1110 and the binary filter 1120, then a single notification will be sent and it will include the rejection reasons from both filters. All messages will be delivered in this example,

In the example filter flow shown in Figure 15, where separate auditors are used and rejects are passed forward, rejections from the key word search filter 1110 will be sent to Auditor A 1140. Rejections from the binary filter 1120 will be sent to Auditor B 1150. If a message fes the key word search filter 1110 and the binary filter 1120, two notifications will be sent- The one sent to Auditor B 1150 will only include the binary filter's 1120 rejection reason.

The one sent to Auditor A 1140 will only include the key word search filter's 1110 rejection reason. A message must pass the binary filter 1120 to be delivered, but delivery does not depend on whether or not it passed the key word filter 1110.

Figure 16 illustrates a map example using duplicate auditors and passing rejects forward. For the map in 16 rejections from the key word search filter 1110 will be sent to Auditor A 1140.1. Rejections from the binary filter 1120 will also be sent to Auditor A 1140.2. If a message fails the keyword search filter 1110 and the binary filter 1120, two separate notifications will be sent, each containing a single rejection reason. This is because there are separate terminals for sending the notifications to Auditor A. A message must pass the binary filter 1120 to be delivered, but delivery does not depend on whether or not it passed the key word filter 1110.

The filter map shown in Figure 17 is just a combination of the ideas presented above. Auditor A 1140 will only receive notifications for messages that fail the key word search filter 1110. Auditor B 1150 will receive notifications for messages that fail the key word search filter 1110, the binary is filter 1120, or both. If a message fails both, Auditor B 1150 will receive a single notification that includes both rejection reasons. Auditor C 1710 will only receive notifications for messages that fail - the biruay search filter 1120. Even if a message fails both, the notification that is sent to Auditor C 17 10 will only include the binary filter's rejection reason. All messages will be delivered under this example.

Filter configuration is actually expressed by a simple language which is represented in the configuration file syntax of the system upon which the mail framework is executing, Appendix I contains an example of one embodiment of such a filter configuration file. lle configuration is broken into three parts. The first part is the filter policy file described earlier. The second part is the filter configuration file which lists all of the parts which are used to assemble the filter policy diagrams (called maps). The configured parts and the file rules are described below. Finally, the third part is the map files. There is one map file per configured flow, as explained in more detail below.

First, a brief description of the primitives employed in one embodiment of the present invention. The terminal modules list in the Terminal[ 1 entry are primitive objects that are listed so as to minimize the ainount of knowledge that,is hard-coded in the programming interface. Following is an example of filter configuration rules.

Fitter Configuration Rules begin-rules conf infb ( path token conCterrninal (terminal conf infoo contjid conf_modifier ( modifier conPinfoo conf id coni-filter ( filter conf infoo -conUd endjules Terminall Modifiel Fitted There may be only one Terminal[ 1 entry in the configuration file. The modifier objects are listed in Modifier[ 1. These are primitive objects and are listed so as 19 to minimize the amount of knowledge that is hard-coded into the programming interface. There may be only one Modifier[ 1 entry in the configurdtion file. The third primitive is a filter. A filter list is a list of all of the types of filters that the system knows about. Putting the filter list in the configuration file lets the filter programming interface have as little hard-coded information as possible. As with the previously described primitives, there may be only one Filter[ 1 entry in the configuration file.

Configuration information for terminals, modifiers and filters are all specified in the same way using the "conf info" rule. This rule includes a path to a configuration file and a token. For simple items, the token alone may 'be sufficient- For others, the file may include everydfin and the token may not be used. If multiple items share a configuration file, then the file may be specified by the path and the token may indicate a specific entry in the file. If a token or path field is unused it must be set to the string "none". This means that "none" cannot be used as a valid value for either of these fields.

A configured terminal is given with the "conf terminal" rule. This associates an identifier with the terminal type and this set of configuration information. For many terminals there will be no configurables, so they may be preconfigured and the user will not be able to configure additional ones. The Terminal field must contain a valid field from the Terminal[ 1 list. A configured modifier is given with the "conf-modifie?' rule. This associates an identifier with the modifier type and this set of configuration information. The Modifier field must contain a valid field from the Modifier[] list. A configured filter is given with the "configure filte?' rule. This associates an identifier with the filter " and this set of configuration infbnnation. The Filter field must contain a valid field from the Filter[ 1 list.

The'AraW' objects are associations between a configured object and links to other drain objects. These objects define the links in the flow diagrams. A configured te is also regarded as a drain object since it is complete in isolation due to the lack of outputs. For complex objects, the output fields are lists of drain id'..R. Configured objects have i&s that the user has entered and uses to identify the objcct. Drains have identifiers also, but, except for configured terminals, these identifiers serve a purely internal purpose and may be chosen in whatever manner suits the administration tools.

A drain list is a list of valid drain identifiers. This is simply an organizational object. A drain modifier is an association of a configured modifier with a list of output drains. This association is given a drain identifier so that it can be linked to the output of an upstream node A drain filter is an association of a configured filter with a drain identifier (did). This association is given a drain identifier so that the drain filter can also be linked to the output of an upstream node. Finally, for any flow there must be a single entry for that sourceldestination burb pair. This entry contains the burb names and a single drain identifier. By default (and probably in the skeleton file) all of the standard flows should be configured to usc the deliver drain object For each flow there is a configuration file that describes the flow.

If a flow is in the policy file but there is no map, then mail will queue but not be processed. The map consists of associations of the configured filter objects shown in Figure 19. In one embodiment map files are stored in a map subdirectory and are each individually named. For example, a map file may be named "lcws_only.conf'. In this case, the map name is "kwsonly". Following are examples of a flow configuration file and a map configuration file.

Flow Configuration File begin - rules # This associates the identifier of a configured terminal in filter.conf with a drain identfier (did).

drain - terminal ( conLid did) # This associates the identifier of a configured modifier in filter.cont mfith a draln # identifier (did). Output from the modifier will be sent to the objects listed by their did's in the pas!R_drainso list drain - modifier(conf id pass-dmira[l did) # This associates the identifier of a configured modifier in filter.conf with a drain identifier (did). Messages that pass the filter will be sent to the objects listed by their did's in the pass-drains[ 1 list Messages that the filter rejects will be sent to the objects listed by their did's in 40 the 21 reject-drains[ 1 list.

drain - filter ( conf id pass-drains[] reject-drains[ 1 did) This lists the drain identifier for the starting point for this map file. There may be # only one flow() entry In the file.

flow (did) end_jrules # This is a list of all of the drain identifiers (did's) that are valid in this file.

There may be only one drain-lisq 1 entry in the file.

drain-lisq 1 Map Configuration File begin_rules drain-terrrdnal ( conUid did drain-modifier ( cont:id pass-drains[] did) drain _ fitter ( conf id pass_drainal 1 rejec_drains[ 1 did flow (did) end-rules This is a list of all of the drain identifiers (did's) that are valid in this file.

# There may be only one drain-lisq 1 entry in the file.

drain-list [ 12 3 4 5 1 --- PassJFail --- DELIVER MAIL Pass --- KEYWORD FILTER - 1 --- Fail ------- DELIVER MAIL > SIZE FILTER Pass Fail --BINARY FILTER --- 1 Fail ------- AUDIT MSG # This is the starting drain id, the size filter. flow (1) drain filter (size pass drains121 reject-drains[41 1 draijfllter ( keyword p-ass dmins13] rejectdrains[3 51 2 draijterminal (Meliver Maiir 3) drain - filter( binary pass-drains[2] reject-drains[51 4 d rain---terminal ("Audit Messagd' 5 so Filter flow modules should be as simple as possible. New or less technical users should be able to use the filters in a simple fashion and not be overwhelmed by too may options or too much sophistication. When thcre is a 22 complicated capability in the system, it may be appropriate to provide a simpler version which is easier to use. For example, the key word search filter is based on regular expressions, but regular expressions are too intimidating to the uninitiated and more complex than what many need. So, the key word search only makes a subset of the functionality visible: tokens with optional wildcards at the beginning and end. For those who want to work with full regular expressions, that functionality can be provided in a logically, if not physically, separate filter which the less technical users can totally ignore.

Whenever possible, filters should have a per-message threshold rather than having a boolean all-or-nothing rejection criteria. For a key word or regular text filter this might be a given number of matches. For something like a binary filter this might be a certain sensitivity. Obviously, filters such as POP signature verification will have a strict boolean behavior.

If a filter rejects a message, it must attach two Idnds of audit messages to the edo. These should be attached in order of smallest to largest because, if memory is depleted in processing, the smaller message can be used in place of the large, while the reverse is not always true. Examples of these messages include the following.

1. A brief audit message.

This a short, descriptive message which should describe the failure as well as possible, but be concise enough to be included in an audit record.

In one embodiment the brief audit inessage is preferably less 9= 160 bytes.

2. A detailed audit message.

This is a detailed message that tries to explain specifically why the message was rejected. For ex=ple, a key word filter would list the words that matched entries in the word lisL 3. A generic audit message.

In one embodiment this is a message that is the same for all rejections. In another embodiment this message is configurable, so that the site can include information about the site security policy and how to contact the responsible administrators for assistance with the violation. In a further embodiment a generic reason module is created which can be used in con unction with any filter.

j 23 A variety of filter types are configurable in the mail structure of the prcsent invention. One type is a key word search filter, which in its simplest form scans the message for a match on any of the words included in a predefined list. Another type of filter is a binary filter, which is intended to catch mail which is not 'normal' text or includes nontext attachments- This is a nebulous pattern-recognition task. Things that should be caught include WME attachments, utiencoded files, btoa encoded files, binhex encoded Illes, as well as raw binary, encrypted mail and shar files. Normal electronic mail written in natural human language such as English should pass.

A third type of filter is a size filter. It is desirable to have a filter that rejects messages based on the message size. The threshold (T) would be configurable and specified in bytes. The message would he rejected if the message size M was greater than or equal to the size threshold:

M > T (1) In one embodiment the threshold is somewhat finzy, Whcre the fuzziness feature is implemented it will be a configurable value (F) in bytes. Given a random value (R) uniformly distributed between zero and one. the threshold function would be:

MkT+ F 2 (R (2) 2 If the overhead of filtering is deemed to be excessive, a filter could be constructed which applies filters to randomly selected messages. The frequency of filtering could be selected as a tradeoff between throughput and completeness of coverage. This would simply have a single configurable value which would be the percentage of messages that would be filtered. Those sIdlled inthe art will recognize there are a wide variety of filter techniques which may he incorporated without exceeding the scope and spirit of the present invention.

24 Modifiers are map objects that take a single input mid yield a single output. Modifiers arc used for actions that do not select the routing of the message, such as adding attachments or some sort of uniform modification of the message. An example of the first would be adding a generic rejection reason. 5 An example of the second would be sanitizing the message headers.

For one implementation of a key word search filter the intent mas to have a confisurable "generic " rejection reason that would be the same for all messages that violated the filter. There are three problems with this approach. First, the rejection reason will always be added, even if it is never used, which is undesirable overhead, especially if filters are being chained. Second, from an engineering perspective, all filters will need to have the code to support this capability built into thern. Third, from the user perspective this approach provides no simple way to have a single gencric rejection reason shared by multiple filters.

is As a result, filters constructed as part of the mail framework of the present invention will not attach generic rejeffion reasons to messages. Instead, a simple one-in, one-out data modifier will be created which attaches a generic rejection reason to all messages that flow through. Functionality equivalent to the prior design is illustrated in Figure 18. An alternative use is illustrated in Figure 19.

The configuration information for the generic rejection reason modifier 1830 is simply the text of the rejection reason. The text is kept in a simple ASCII file which will be attached verbatim to the message. Since no other information is wnfigurable, the system configuration file format is not used. The filter.conf file!s conf info entries will include the path to the file, but the token field is not used. For example:

Modifter[GeneficRejectReason] drairLlist ( didl M2 1 conf modifier ( GenericRejectReason conf-info(letclfilterigenedc reasordpolicy.text didl) genedc-reject-1 conf-mod"ifier(GencricRejectReason cont_info(leteAlterigeneric-reasordcall-admin.text did2)gertedi_rejecL2) Note that utility fimctions should probably be added to the filter library to support opening and reading text files with the same file locking sernantics used by the configuration library so that deadlock and race conditions will be avoided- Another function which may be provided through a modifier is to sanitize the message headers. Sanitizing thq message headers means to remove information from the headers that potentially discloses information about the internal network which is riot required by the mail delivery system to deliver the mail. Initially, this involve removing the Received-by lines on out-bound mail. Many other modifiers are also possible, such as ones that apply digital. signatures or encrypt messages based on the destination address. The examples given in the discussion of the modifiers' functionality are offered for illustration and not intended to be exclusive or limiting.

Terminal objects e'drains") are generally simple and may not be dynamically configurable. The discussion following details various types of terminals and their configuration information. Most identifiers and token narnes can be adjusted to suit the needs of the user interface. The examples are offered as illustrations and are not intended to be exclusive or limiting in any way- One type is the 'deliver to recipient' terminal. This action is to deliver the message on to the sendcrs intended recipients. This terminal is normally placed at the end of a filter chain as the action for messages that pass all of the filters. It may be used on failed messages as well, if the site policy favors rapid delivery over highly accurate prevention. There are no configurable options for this tenninal. A single entry will be preconfigured in the configuration file filter.cont 26 Term inal[Deliverl conf terminal ( Deliver conUnfb (none none) "Deliver Mail' The "return to sender" terminal returns the message to the sender- The rejected message can include the detailed rejection reason, the generic rejection reason, or the brief rejection reason. If the filter is configured to return the generic reason, but one has not been attached, it will use the brief rejection reason instead. The only configurable option is the type of rejection messageThis information will be included in the token field of the configuration information. These entries will not have separate configuration files. In the embodiment where there are only three possible configurations, all three should be preconfigured in the default installation.

Terminal[RetumToSenderl is conLterminal ( ReturnToSender conf-info ( none brief) "Return w/brief') conf terminal ( ReturnToSender conf_info ( none generic) "Return w/genefe confterminal ( ReturnToSender confinfo (none detailed) "Retum w/detailso The "mail to reviewer" terminal encapsulates the message and sends it on to an auditor. The message must be encapsulated as either a N1IME attachment or simply an indented block of text. In one embodiment, this choice is configurable, In an alternate embodiment, the choice is not cortfigurable, and is preconfigured to support a single delineation (such as an indented text block). It is important that the message he encapsulated in some mannerso that common program mailer attacks are ineffectual when the message is sent to the reviewer. Otherwise, one could construct a filter that detects the attack and forwards it on to attack the auditor. This is a convenient method to get information to the auditor, but mail forwarded in this fashion cannot be properly forwarded on by the reviewer. If sending is dependent upon the reviewer, then the reviewer will need to use a manual review tool. The configurable options of this terminal are the e-mail address of the recipient of the message. the burb name of where the electronic mail address is, the choice of rejection message to include (if any) and 27 whether or not to include the message orjust the rejection message. A single configuration file will exist to contain the configuration information for all terminals of this type. The information in config. info will be the path to the configuration file and the terminal identifier. For example..

Terrninal[MailToReviewerl conf terminal (MailToReviewer conf info (letrJfilterlrnailaudit.conf Charlie) MharliC) conf-terminal ( MailToReviewer conf info ( letctfiiter/mailaudit.conf Linus "Linus" conf terminal( MaiFToReviewer conf info ( letcffilterimailaudit.conf Lucy "Lucyo One example of the contents of the corresponding mail audit configuration file (mailaudit.conf) is illustrated in the following example.

Mail Audit Configuration File begin - rules # conf id: must match the conf info ( token) field in filter.conf # audit- level: one of "nond', "bdef"genedd' or "detailed" # incluie-msg: either "y or ono" # address: the e-mail address to which mall should be sent # burb: the burb where the reviewer's e-mail address is locate d default is: trusted mailaudit ( conf-id audit-level include-Msg address burb) end-rules mailaudit ( Chadie detailed yes chadie@kite.com internal) mailaudit ( Linus generic no lv@blanketorg external) mailaudit ( Lucy brief yes expert@nickel.psychiatfist.com internal Mail messages may be very large, especially for a binary filter or a message size filter. The 1og to filie' terminal logs messages to a file in a directory. The directory is configurable. There will be a single instance of one such directory preconfigured, on the system. When configuring a new instance, the directory will need to be created', typed, and added to the facility that rolls over audit and log files. If there is a manual review tool it will be able to process messages from this directory. This could be used in a manner analogous to strikeback reports, mail a simple notice, and store the whole thing in a file. The 28 mail notifier described previously would be used in this scenario to send a brief or generic rejection notice. The configurable options include the directory to use when writing out the message, the choice of rejection message to include (if any) and whether or not to include the message or just the rejection message. A single configuration file will exist to contain the configuration information for all terminals of this type. Two entries will be preconfigured; one for each of the standard flows. The information in config_info will be the path to the configuration file and the terminal identifier. For example:

Terminal[LogToFilel conf terminal( LogToFile continfo ( letrJfilterifileaudit-conf intext) intext conCterminal(LogToFile conf-info(letcJfllterlfileauditconf extint) extint) An example of the contents of the corresponding file audit configuration file is shown in the following example.

Mall Audit Configuration File begin-rules # conf id: must match the conf info ( token) field in filter.conf # audift- level: one of "none","brief', "genedd% or "detailed" # incluic - msg: either "yee or "nd' directory: directory where message files will be written fileaudit ( conf id audit-level include_msg directory) end-rules fileaudit ( intext detailed yes ivarlspooVflteiWintext) fileaudit (extint generic no Narispoonialoglexdnt) Another terminal type is the "audiC terminal. Ibis terminal sends a message to the audit device. This will he of a type specific to filtering and will include the source burb, destination burb and the brief audit message. Nothing is configurable in this terminal. A single entry will be preconfigured in filter. Mnú Terminal[Audit] conLterminal ( Audit conf-info ( none none) "Audit Message") The terminal examples described above are exemplary only and not intended to be exclusive or limiting. Those skilled in the art will recognize that other terminal types may be constructed without exceeding the spirit and scope of the present invention.

29 Although the present invention has been described with reference to the preferred embodiments, those sidlled in the art will recognize that changes may be made in forin and detail without departing from the spirit and scope of the invention.

APPENDIX 1 Filter Configuration File Example # # Description: Configures the terminals. modifiers and filters for m'clil filtering.

what is configurable:

# conf-info(path token):

# Configuration information for terminals. modifiers and fitters are all specified in the same way # using conf the info rule. This rule indudes a path to a configuration file and a token. For # simple items, the token alone may be sufficient. For others, the file may include everything # and the token may not be used. if multiple items share a configuration file, then the file may # be specified by the path and the token may indicate a specific entry in the file. If a token or # path field is unused it must be set to the string "nond'. This means that "none' cannot be 4 used as a valid value for either of these fields.

# confterminal ( terminal conf-infb() conf-id # A configured terminal is given with the conf-terminal rule. This associates an identifier with the terminal type and this set of configuration information. For many there will be no # configurables, so they may be preconfigured and the user will not be able to configure 9 additional ones- The terminal field must writain a valid field from the Terminal[ list- # conf-modifier ( modifier conf-info() confid A configured modifier is given with the conf-rnodifier rule. This associates an identifier with the 9 modifier type and this set of configuration information. The modifier field must contain a valid field from the Modified 1 list conf-rllter (filter conf-info() conf id # A configured filter is given with the conf-filter rule. This associates an identifier with the # fitter type and this set of configuration information. The filter field must contain a 50 valid field # from the Filted 1 list.

# 31 # Examples:

# FILTERS:

# Configuring a key word search filter:

# conf-fiiter( KeyWord conf-info (letc/fltterlkwsfkws.conf none) keyword) Configuring a size fitter # conf-fiiter( Size conf-info (letclfliterlsizelsize.conf size) size) Configuring a binary filter con(-filter( Binary conf info letciffiter/binary/binary.conf binary) binary) # Modifier& # Configuring a generic rejection reason modifier:

# conf-Modifie GenericRejectionReason" conf info( letclfilter/g eneric-reasgeneric. file none) generic-Modlifier) TERM 1 NALS:

# Configuring the log to file terminal:

conf-terminai( "LogToFile" conf-infb(letclfjfterlfileauditconf intext) log_to_ftle) # Configuring the mail to reviewer terminal:

# conf-terminal( "Mai[ToReviewer'conf info(letcifilter/mailaudit.conf John) "John Smith") 25 # Configuring the audit file terminal:

conf-terminal ("Audit' conf-intb(none none) audit-msg) # 9 -4- A 1-01 1 1-1.19.1 -!1 P0.04.f begin_rules conf-info(path token) conf terminal ( terminal conf-infb() conf id) conf modifier ( modifier conf-info conf id) conf-filter ( filter conf-info conf id) end-rules list of terminal module types. There may only be one such list 40 # Terminal [ "Mal[ToReviewer' "LogToFile" "Audit' "Delive' "RetumToSendel" list of modifier module types. There may only be one such list # Modifier [ "GenedcRejecdonReasan" 1 # list of filter module types. There may only be one such list.

# Filter [ "Size" "KeyWord" "Binasy" 1 # Configuring the return to sender terminal:

conf - terminal ( ReturnToSender conf info(none brief) "Return w/bdef' conf - terminal ( RetumToSender conf-info (none generic) "Return w/generit" conf-terminal ( ReturriToSender conf-info(none detailed) "Return w/details" 32 # Configuring the deliver to recipients terminal: conf-terminal ( Deliver conf-info(none none) 'Veliver Mait') # Configuring the audit terminal:

conf-terminal ( Audit conf-info ( none none) 'Audit Message') C 1996 Secure Computing Corporation 33

Claims (26)

1. A method of filtering electronic mail messages, comprising the steps of. defining a plurality of nodes, wherein each node identifies an operation and wherein one of the nodes is a filter node which identifies messages to filter- interconnecting nodes from the plurality of nodes such that the interconnected nodes describe a security policy; and passing-an electronic mail message through the filter node, wherein the step of passing an electronic mall message through the filter node -Mcludes the steps of:

   detenTining if the electronic mail message is one which is to be filtered; if the electronic mail message is identified as to be filtered, processing the electronic mail message through one or more filter flows; and is otherwise delivering the electronic mail message without filtering.
2. 2. The method of claim 1, wherein the step of processing the electronic mail message comprises the stops of. analyzing the message to determine if it has a particular characteristic; and disposing of the electronic mail message based on the outcome of the analysis.
3. 3. The method of claim 2, wherein the step of disposing of the electronic mail message comprises the step of delivering the message.
4. 4. The method of claim 2, wherein the step of disposing of the electronic mail message comprises the step of rejecting the message.
5. 5. The method of claim 2, wherein the step of disposing of the electronic, nail message comprises the step of transmitTing an audit message.

   34
6. 6. The method of claim 3, wherein the step of disposing of the electronic mail message comprises the steps of:

   delivering the mcssage; rejecting the message; and transmitting an audit message.
7. 7, The method of claim 1, wherein the step of disposing of the electronic mail message comprises the step of modifying the first electronic rnail message.
8. 8. The method of claim 7, wherein the step of disposing of the electronic mail message comprises the step of altering the first electronic mail message address.
9. 9. The method of claim 7, wherein the step of disposing of the electronic mail message comprises the step of altering the first electronic mail message header.
10. 10. An electronic mail filter, comprising:

    an analysis module for analyzing an electronic mail message, wherein the analysis module includes:

    node defining means for defining a plurality of nodes, wherein each node identifies an operation and wherein one of the riodes is a filter node which identifies messages to fitter; and interconnecting means for inemnnecting nodes from the plurality of nodes such that the interconnected nodes describe a security policy; and an output module, connected to the analysis module, for generating a plurality of output messages, wherein one of the plurality of messages is generated as a function of analysis of the electronic mail message by the analysis module.
11. 11. The electronic mail filter of claim 10, wherein the node defining means includes means for creating a plurality of individual independent filter, modifier and terminal nodes; and wherein the interconnecting means includes means for interconnecting 5 the plurality of individual filter, modifier and terminal nodes.
12. 12. A system for filtering electronic mail, comprising: means for receiving electronic mail messages, including a first message, from one or more sources; and an analysis module for determining whether to filter the first message, wherein the analysis module includes:

    a plurality of filters, including a first filter, for analyzing characteristics of the first message; and one or more terminals, including a first terminal, for delivering is the first message to one or more destinations.
13. 13. The system of claim 12, wherein the analysis module further comprises a plurality of modifiers, including a first modifier, wherein each of the plurality of modifiers operates to modify the first message.
14. 14. A method of managing a filter map, comprising the steps: identifying one or more nodes to be included in the map, wherein each node defines an operation to be performed on a message, wherein the step of identifying includes the step of defining a security policy; defining an order in which operations are to be perforned on the message; graphically positioning each of the one or more nodes according to the defined order; and graphically identifying connections between the nodes as a function of one or more routing paths available from any one node.

    36
15. 15. A method for constructing an electronic mail filter having one or more message routing paths, comprising the steps:

    identifying a policy describing the one or more message routing paths; defining a plurality of filter nodes for analyzing electronic mail messages; defining a plurality of modifier nodes for modifying. electronic mail messages; defining one or more terminal nodes for delivering electronic mail messages and other electronic information; and interconnecting the plurality of filter nodes, modifier nodes and terminal nodes so as to implement the policy.
16. 16. An electronic mail system, comprising:

    a mail filter (220) having a plurality of filter objects (802, 803, 804), wherein the filter objects are. arranged in a flow which enforces a security policy; and a mail delivery agent (2 10) connected to the mail filter (22 0), wherein the mail delivery agent receives an electronic mail message and routes the electronic mail message based on a mail filter policy, wherein the mail filter policy determines mail to queue and mail to pass on; wherein the mail filter retrieves electronic mail messages queued by the mail delivery agent and filters the retrieved electronic messages according to the security policy.
17. 17. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a terminal node type (802).
18. 18. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a modifier node type (803).

    37
19. 19. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a filter node type (804).
20. 20. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a plurality of node types (802, 803, 804), wherein each node type includes an initialization section, a message processing.; ection and a node clean-up section.
21. 21. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a plurality of node types (802, 803, 804), wherein one of the plurality of node types appends information on to a mail message.
22. 22. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a plurality of node types (802, 803, 804), wheTein one of the plurality of node types generates audit messages.
23. 23. The electronic mail system according to claim 16 or 20, wherein the mail filter policy is stored 'm a mail filter policy file as a set of burb pairs, wherein each burb pair includes a first and a second burb, wherein messages from the first to the second burb are queued by the mail delivery agent.
24. 24. A method of filtering electronic mail messages, comprising the steps of. providing a plurality of node types; connecting the plurality of node types according to a secujity policy; 25 receiving an electronic mail message; and analyzing the electronic mail message as a function of the electronic mail message.
25. 25. 7he method according to claim 24, wherein the step of connecting includes the steps ofdisplaying the plurality of nodc types as icons within a visual medium; 38 placing copies of the icons on the visual medium in respowe to input from a user; and connecting the icons placed on the visual medium.
26. 26. The method according to claim 24, wherein the stcp of connecting includes the step of configuring the plurality of nodes types to perforni a function from onc: of a set of functions including forwarding, rejecting and returning the message.

    26. The method according to claim 24, wherein the step of connecting includes the step of configuring the plurality of nodes types to perform a function from one of a set of functions including forwarding, rejecting and returning the message.

    Amendments to the claims have been filed as follows CLAIMS I. A method of filtering electronic mail messages, comprising the steps of. defining a plurality of nodes, wherein each node identifies an operation and wherein one of the nodes is a filter node which identifies messages to filter; interconnecting nodes from the plurality of nodes such that the interconnected nodes describe a security policy; and passing-an electronic mail message through the filter node, wherein the step of passing an electronic mall message through the filter node includes the steps of.

    determining if the electronic mail message is one which is to be filtered; if the electronic mail message is identified as to he filtered.

    processing the electronic mail message through one or more filter flows; and is otherwise delivering the electronic mall message without filtering.

    2. The method of claim 1, wherein the step of processing die electronic mail message comprises the steps of. analy2ing the message to determine if it has a particular charactefistic; and disposing of the electronic mail message based on the outcome of the analysis.

    The method of claim 2, wherein the step of disposing of the electronic mall message comprises the step of delivering the message.

    4. The method of claim 2, wherein the step of disposing of the electronic mail message comprises the step of rejecting the message.

    5. The method of claim 2, wherein the step of disposing of the electronic inail message comprises the step of transmitting an audit messagc, yei 6. The method of claim 3, wherein the step of disposing of the electronic mail message comprises the steps of:

    delivering the mcssage; rejecting the message; and transmitting an audit message.

    7. The method of claim 1, wherein the step of disposing of the electronic mail message comprises the step of modifying the first electronic mail message.

    8. The method of claim 7. wherein the step of disposing of the electronic mail message comprises the step of altering the first electronic niail message address.

    9. The method of claim 7, wherein the step of disposing of the electronic mail message comprises the step of altering the first electronic mail message header.

    10. An electronic mail filter, comprising:

    an analysis module for analyzing an electronic mail message, wherein the analysis module includes:

    node definiDg means for defining a plurality of nodes. wherein each node identifies an operation and wherein one of the nodes is a filter node which identifies messages to filter; and interconnecting means for interconnecting nodes from the plurality of nodes such that the interconnected nodes describe a security policy; and an output module, connected to the analysis module, for generating a plurality of output messages, wherein one of the plurality of messages is generated as a function of analysis of the electronic mail message by the analysis module.

    4- 11. The electronic mail filter of claiin 10, wherein the node defining means includes means for creating a plurality of individual independent filter, modifier and terminal nodes. and wherein the interconnecting means includes means for interconnecting the plurality of individual filter, modifier and terminal nodes.

    12. A system for filtering electronic mail, comprising: means for receiving electronic mail messages, including a first message, from one or more sources; and an analysis module for determining whether to filter the first message, wherein the analysis module includes a plurality of nodes, wherein the nodes are interconnected to enforce a security policy and wherein the Plurality of nodes include; a plurality of filter nodes, including a first filter node, for is analyzing characteristics of the first message; and one or more terminal nodes, including a first terminal node, for delivering the first message to one or more ations.

    13. The system of claim 12, wherein the plurality of nodes further include a plurality of modifier nodes, including a first modifier node, wherein each of the pluraUty of modifier nodes operates to modify one or more electronic mail message and wherein the first modifier node operates to modify the first message.

    14. A method of managing a filter map, comprising the steps: identifying one or more nodes to be included in the map, wherein each node defines an operation to be performed on a message, wherein the step of identifying includes the step of defining a security policy; def an order in which operations are to be performed on the message; graphically positioning each of the one or more nodes according to the defined order; and graphically identifying connections between the nodes as a function of one or more routing paths available from any one node.

    4-2- 15. A method for constructing an electronic mail filter having one or more message routing paths, comprising the steps:

    identifying a policy describing the one or more message routing paths, defining a plurality of filter nodes for analyzing electronic mail messages; defining a plurality of modifier nodes for modifying electronic mail messages; defining one or more terminal nodes for delivering electronic mail messages and other electronic information; and interconnecting the plurality of filter nodes, modifier nodes and terminal nodes so as to implement the policy.

    16. An electronic mail system, comprising:

    is a mail filter (220) having a plurality of filter objects (802, 803, 804), wherein the filter objects are arranged in a flow which enforces a security policy; and a mail delivery agent (210) connected to the mall filter (220), wherein the mail delivery agent receives an electronic mail message and routes the electronic mail message based on a mail filter policy, wherein the mail filter policy determines mail to queue and mail to pass on; wherein the mail filter retrieves electronic mail messages queued by the mail delivery agent and filters the retrieved electronic messages according to the security policy.

    17. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a terminal node type (802).

    18. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a modifier node type (R03).

    19. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a filter node type (804).

    20. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a plurality of node types (802, 903, 804), wherein each node type includes an initialization section, a message processing section and a node clean-up section.

    21. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a plurality of node "s (802, 803, 804), wherein one of the plurality of node types appends information on to a mail message.

    22. The electronic mail system according to claim 16, wherein the plurality of filter objects includes a plurality of node types (802, 803, 804), wherein one of the plurality of node types generates audit messages.

    23. The electronic mail system according to claim. 16 or 20, wherein the mail filter policy is stored in a mail filter policy file as a set of burb pairs, wherein each burb pair includes a first and a second burb, wherein messages from the first to the second burb are queued by the mail delivery agent.

    24. A method of filtering electronic mail messages, comprising the steps of. providing a plurality of node types; connecting the plurality of node types according to a seculity policy; 25 receiving an electronic mail message; and analyzing the electronic mail message as a function of the electronic mail message.

    25. The method according to claim 24, wherein the step of connecting includes the steps ofdisplaying the plurality of nodc: types as icons within a visual medium; placing copies of the icons on the visual medium in respowe to input from a user; and connecting the icons placed on the visual medium.