Electronic Message Management System With Risk Based Message Processing
RELATED APPLICATIONS
[0001] The present application is a non-provisional application of provisional application 60/544,636, entitled "Agent Monitoring/Reporting/Dynamic resource Allocation Instructions", filed on February 13, 2004, and provisional application 60/544,774, entitled "Dynamic/Intelligent Resource Allocation Using Agents and/or Other Operating Instructions", filed on February 13, 2004. The present application claims priority to said provisional applications, and incorporates their specifications by reference, to the extent the '636 and '774 specifications are consistent with the specification of this non-provisional application. TECHNICAL FIELD
[0002] Embodiments of the present invention relate generally, but not limited, to the fields of data processing and data communication. In particular, embodiments of the present invention relate to risk based processing of electronic messages.
BACKGROUND
[0003] With advances in computing and networking technology, electronic messaging, such as email, has become ubiquitous. It is used for personal as well as business communication. However, in recent years, the effectiveness of electronic messaging is undermined due to the rise and proliferation of spam mails (i.e. uninvited and/or solicitation commercial or non-commercial electronic messages) and viruses (i.e. malicious code). [0004] Large enterprises, such as multi-national corporations, handle millions of electronic messages each day, employing multiple geographically dispersed servers, to
serve their far flung constituent clients. The problem of unwelcome or undesirable electronic messages is especially difficult for them, and creates a significant hurdle to timely processing and routing important business communications.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] The present invention will be described by way of exemplary embodiments, but not limitations, illustrated in the accompanying drawings in which like references denote similar elements, and in which:
[0006] Figure 1 illustrates an overview of an electronic message management system, suitable for practicing the invention, in accordance with some embodiments;
[0007] Figure 2 illustrates a boundary mail server of Figure 1 in further detail, in accordance with some embodiments; [0008] Figure 3 illustrates the mail management server of Figure 1 in further detail, in accordance with some embodiments;
[0009] Figure 4 illustrates a portion of the operational flow of the identifier/classifier of Figure 2, in accordance with some embodiments;
[0010] Figure 5 illustrates a portion of the operational flow of the data store of Figure 3, in accordance with some embodiments; and
[0011] Figure 6 illustrates a portion of the operational flow of message processor of
Figure 3, in accordance with some embodiments.
DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS
[0012] Illustrative embodiments of the present invention include, but are not limited to, an electronic message management system, including e.g. a central mail management server, and a number of boundary mail servers, adapted to manage electronic messages, including risk based processing of messages (or contributing to). [0013] Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of their work to others skilled in the art. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced with only some of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to one skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well-known features are omitted or simplified in order not to obscure the illustrative embodiments.
[0014] The phrase "in one embodiment" is used repeatedly. The phrase generally does not refer to the same embodiment; however, it may. The terms "comprising", "having" and "including" are synonymous, unless the context dictates otherwise. The term "server" may be a hardware or a software implementation, unless the context clearly indicates one implementation over the other.
[0015] Referring now to Figure 1, wherein an overview of an electronic message management system, in accordance with some embodiments, is shown. As will be apparent to those skilled in the art, the electronic message management system is particularly suitable for large enterprises, handling millions of electronic messages per day, utilizing numerous geographically dispersed servers. Since electronic mail is the most predominant form of electronic messages, for ease of understanding, the remaining descriptions will primary be presented in the context of electronic mail management. However, one skilled in the art will appreciate that the present invention may be practiced to manage all types of electronic messages, including but
not limited to electronic mails. Further, the present invention may be practiced in computing environments having other architectures.
[0016] As illustrated, for the embodiments, electronic message management system 101 includes a central mail management server 114 and a number of distributed mail servers 104. For the embodiments, distributed mail servers 104 are placed on a number of devices, such as firewalls 102, located at a number of boundary points of enterprise computing environment 100. In alternate embodiments, the mail servers need not be placed on the same machine as the firewall. The firewall machines may sit on separate hardware from the mail servers, just in front of them and modulating access to them by servers outside the enterprise computing environment 100. The zone into which the perimeter mail servers are placed is usually called a "DMZ" (demilitarized zone), and is typically reserved for those few boundary servers (e.g. email, http, etc.) that need to provide network services that connect directly to external clients on the Internet (e.g. email senders, web browsers, etc.). Accordingly, distributed mail servers 104, whether it is placed directly on the same hardware with the firewall, or on separate hardware behind the firewall, in a DMZ, may also be referred to as boundary mail servers 104. Further, for the embodiments, boundary mail servers 104 are operatively coupled to central mail management server 114, through e.g. Intranet fabric 106. Intranet fabric 106 represents a collection of one or more networking devices, such as routers, switches and the like, to provide the operative coupling between boundary mail servers 104 and mail management server
114.
[0017] As will be described in more detail below, in various embodiments, boundary mail server 104 includes a mail transfer agent (MTA) component 202 and a message identification and classify combination 204 (Figure 2). In particular, MTA 202 is adapted to receive emails from electronic mail senders (which may be outside or within enterprise computing environment 100) using e.g. the Simple Mail Transfer Protocol (SMTP) and its extensions defined by the Internet Engineering Task Force (IETF) in [RFC2822] and related specifications. Message identification and classify combination 204, on the other hand, is adapted to identify sender types for external
senders of inbound messages, if possible, and classify the inbound messages into message classes, reflective of their perceived security risks (to computing environment 100, and/or its "owner" entity). In various embodiments, the classifications are based at least in part on the results of the identification operation(s). An example of a suitable MTA is Sendmail, available from Sendmail, Inc. of Emeryville, CA, in particular, versions that support the Milter Application Programming Interface. Hereinafter, for ease of understanding, the term "perceived security risk" shall be used (including in the claims) in its "short" form (i.e. without repeated qualification on the entity with the risk exposure), however, unless specified otherwise, or the context clearly dictates a different meaning, the term should be construed to mean the "security risk as perceived to computing environment 100 and/or its "owner" entity). "Owner" shall have a general, and not a legalistically precise meaning. [0018] Continuing to refer to Figure 1, central mail management server 114 includes a message store 302, store manager 310 and message processors (e.g. mail filter) 312. Message store 302 and store manager 310 are adapted to collaborate to facilitate storing of messages with associated perceived security risks. And message processors (e.g. mail filter) 312, on the other hand, are adapted to process (e.g. filter) the stored messages in a manner that takes into consideration of their perceived security risks.
[0019] In various embodiments, message processors 312 are adapted to process the messages in an order that that takes into consideration of their perceived security risks. As a result, messages with lower perceived security risks are generally processed with a lower average wait time. In particular, messages with the lowest perceived security risks are processed with a lowest average wait time, whereas messages with the highest perceived security risks are processed with a highest average wait time, when compared to messages of other perceived security risk levels. [0020] In various embodiments, message processors 312 are adapted to process the messages with a scrutiny level that that takes into consideration of their perceived
security risks. As a result, messages with lower perceived security risks are processed with lesser amount of scrutiny. In particular, messages with the lowest perceived security risks are processed with the least amount of scrutiny, and messages with the highest perceived security risks are processed with a highest amount of scrutiny, when compared to messages of other perceived security risk levels.
[0021] Still referring to Figure 1, enterprise computing environment 100 is coupled to the external world, e.g. to various external mail senders, relays or receivers 120, through public network 122. External mail senders, relays or receivers 120 represent a broad range of these elements known in the art. Public network 122 may comprise one or more interconnected public networks, including but are not limited to the famous Internet.
[0022] Within enterprise computing environment 100, firewall 102 (including mail server 104 are coupled to other internal servers, such as the earlier described mail management server 114 and internal mail servers 110, and mail clients 112, through a number of internal networks, including but not limited to intranet 106 and local area networks 108.
[0023] Referring now to Figure 2, wherein a boundary mail server 104 is illustrated in further detail, in accordance to various embodiments. As alluded to earlier, mail server 104 includes MTA 202 and message identification and classification combination 204. As described earlier, MTA 202 is adapted to send and receive electronic mails to and from other mail senders/receivers or relays 120/110 (internal or external to enterprise computing environment 100), and message identification and classification combination 204 is adapted to identify sender types for external senders of inbound messages, if possible, and then classify the inbound messages into message classes, reflective of their perceived security risks, based at least in part on the results of the identification operation(s).
[0024] In various embodiments, message identification and classification combination 204 is adapted to identify the sender type of a sender of a message by performing one or more validation operations. The term "validation operations" as
used herein refers to operations that attempt to validate the sender based at least in part on protocol and/or data extensions. Examples of validation operations include, but are not limited to, comparison of the sender's internet protocol address against lists of previously classified internet addresses, reverse domain name lookup operations, sender permitted from determination operations, domain level decryption operations, and so forth.
[0025] In various embodiments, message identification and classification combination 204 is alternatively or additionally adapted to identify the sender type of a sender of a message by performing one or more authentication operations. The term "authentication operations" as used herein refers to operations that attempt to authenticate the sender based at least in part on sender level cryptography. Examples of validation operations include, but are not limited to, authenticating digital signatures and the like [0026] In various embodiments, message identification and classification combination 204 is adapted to classify the messages into appropriate message classes that are reflective of the perceived security risks, based at least in part on the results of the identification operations. In various embodiments, message identification and classification combination 204 is adapted to classify the messages into - a privileged entity class (for messages originating from e.g. "privileged" business partners); a key entity class (for messages originating from e.g. "key" business partners; - a known entity class (for messages originating from e.g. known entities, such as known corporations); - known recipient partners class (for messages originating from e.g. other known messaging partners of the recipients); and an unidentified sender class (for messages originating from senders/domains that cannot be otherwise identified). [0027] For the embodiments, a boundary mail server 104 may further include management databases 222 for storing various data 224 employed by message
identification and classification combination 204 to perform its identification and classification operations. The exact natures of these data are implementation dependent. For example, if reverse domain name lookup operation is performed to validate a sender, data 224 may comprise the network addresses of a number of domain name services. As another example, if domain or recipient level decryption is supported to authentic a sender, data 224 may comprise one or more decryption keys. As another example, if internet address comparison is used to validate a sender, data 224 may comprise one or more lists of previously categorized internet addresses. [0028] For the embodiments, mail server 104 also includes one or more persistent storage units (or storage media) 212, employed to store the earlier described management databases 202 and working data. Further, mail server 104 includes one or more processors and associated non-persistent storage (such as random access memory) 214, coupled to storage medium 212, to execute MTA 202 and message identification and classification combination 204. For these embodiments, MTA 202 and message identification and classification combination 204 are implemented in software. In alternate embodiments, MTA 202 and message identification and classification combination 204 may be implemented in hardware, in part or in whole. Portions of the operational flow of MTA 202 and message identification and classification combination 204 will be further described below.
[0029] Referring now to Figure 3, wherein mail management server 114 is illustrated in further detail, in accordance with various embodiments. As illustrated, for the embodiments, mail management server 114 includes a data store 302 and store manager 310 to facilitate storing messages with attributed perceived security risks, e.g. as reflective by their assigned message classifications. For the illustrated embodiments, data store 302 includes a number of message queues 304 having associated processing priorities. For the illustrated embodiments, messages are stored into prioritized queues 304 based at least in part on their attributed perceived security risks.
[0030] As described earlier, for the illustrated embodiments, mail management server 114 further includes one or more message processors (e.g. mail filter) 312 adapted to process the messages in a manner that takes in consideration of their perceived security risk. In particular, one or more message processors (e.g. mail filter) 312 are adapted to process messages with lower perceived security risks with lower average wait times. In particular, messages with the lowest perceived security risks are processed with the lowest average wait time, and messages with the highest perceived security risks are processed with the highest average wait time. [0031] Various implementation schemes may be employed to provide the desired processing prioritization. In various embodiments, the messages are processed in order of their perceived security risk with the lowest perceived security risk messages (stored in the message queue with the highest processing priority) processed first, before messages of the next higher perceived security risk (stored in the message queue with the next lower processing priority) are processed. This technique may also be augmented with some guaranteed processing for messages of higher perceived security risks.
[0032] In alternate embodiments, different message processors may be employed to process messages with different perceived security risks, with the message processor employed to process messages with lower perceived security risk (e.g. stored in the message queue with higher processing priority) being given more resources (e.g. more power processor, more memory, and so forth,), as compared to resources given to other message processors. The queues may be physically distinct, or logically distinct (e.g. by virtue of the priorities accorded them). Such broad meaning (i.e. physical or logical distinct) are intended for the term "queue", as it is used hereinafter, including their usage in the claims. In particular, the message processor employs to process messages with the lowest perceived security risk (e.g. stored in the message queue with the highest processing priority) being given the most amount of resources, and message processor employs to process messages with the highest perceived security risk (e.g. stored in the message queue with the lowest processing priority) being given the least amount of resources. Accordingly, resources of
computing environment 100, in particular, electronic message management system 101, may be more efficiently employed to process electronic messages, in favor of the authentic business related electronic messages.
[0033] In various embodiments, message processors (e.g. mail filter) 312 are adapted to process messages with lower perceived security risks with lower level of scrutiny. In particular, messages with the lowest perceived security risks are processed with the lowest amount of scrutiny, and messages with the highest perceived security risks are processed with the highest amount of scrutiny. For examples, messages with the lowest perceived security risks may be processed for virus detection only, and applying a most liberal attachment policy, and messages with the highest perceived security risks may be processed for spam as well as virus detection, and applying a least liberal attachment policy.
[0034] Continuing to refer to Figure 3, for the illustrated embodiments, mail management server 114 further includes one or more persistent storage units (storage medium) 342, employed to stored management databases 302. Further, mail management server 114 includes one or more processors and associated non- persistent storage (such as random access memory) 344, coupled to storage medium 342, to execute store manager 310 and message processors (e.g. mail filter) 312. For these embodiments, store manager 310 and message processors (e.g. mail filter) 312 are implemented in software. In alternate embodiments, store manager 310 and message processors (e.g. mail filter) 312 may be implemented in hardware, in part or in whole.
[0035] We refer now to Figures 4-6 to further describe message identification and classification combination 204, store manager 310 and message processors (e.g. mail filter) 312, more specifically, the relatively more relevant portions of their operational flow.
[0036] Figure 4 illustrates a portion of the operational flow of message identification and classification combination 204, in accordance with some embodiments. As illustrated, on receipt of a message, in particular, an inbound message, message
identification and classification combination 204, attempts to identify the message, if possible, block 402. As described earlier, in various embodiments, message identification and classification combination 204 performs one or more validation operations. In various embodiments, message identification and classification combination 204, may alternatively or additionally, perform one or more authentication operations. Refer to earlier description for examples of validation and authentication operations.
[0037] On completion of identification, whether successful or not, message identification and classification combination 204, classifies the message into one of the message classifications, reflective of the perceived security risk, based at least in part on the result of the identification operation(s), block 404. For example, if the message is originated from a privileged business partner, message identification and classification combination 204 classifies the message into the privileged entity class having the lowest perceived security risk, or if the message's origination is unidentified, message identification and classification combination 204 classifies the message into the unidentified message class, having the highest perceived security risk. Other messages are classified into appropriate message classes, in like manner, reflective of their perceived security risks. The granularity, i.e. number of intermediate message classes having intermediate perceived security risk levels, may vary from embodiments to embodiments.
[0038] On classifying the message, for the illustrated embodiments, message identification and classification combination 204 annotates the message with the classification information accordingly, and then forwards the identified/classified message to store manager 310 for storage, and subsequent processing by message processors 312, block 406.
[0039] Figure 5 illustrates a portion of the operational flow of store manager 310, in accordance with some embodiments. As illustrated, on receipt of a message annotated with its perceived security risk, store manager 310 causes the message to be stored into message store 302 accordingly, based at least in part on the message's
perceived security risk, block 502. As described earlier, in various embodiments, the message is annotated with a message class reflective of its perceived security risk, store manager 310 causes the message to be stored into a message queue with appropriate processing priority (commensurate to the perceived security risk).
[0040] Figure 6 illustrates a portion of the operational flow of message processor(s) 312, in accordance with some embodiments. As illustrated, when invoked, message processor(s) 312 selects messages of a security risk level for processing, block 602. In various embodiments, where messages of a particular security risk level are stored in a message queue having a commensurate processing priority, message processor(s) 312 selects messages stored in a message queue of a particular priority for processing. In various embodiments, message processor(s) 312 selects and processes messages one security risk level (e.g. one message queue) at a time, from the lowest security risk (highest processing priority) to the highest security risk (lowest processing priority).
[0041] On selection of messages of a perceived security risk (message queue of a particular priority), message processor(s) 312 retrieves one of the messages, block 604 and processes (e.g. filters) it accordingly, block 606. As described earlier, in various embodiments, message processor(s) 312 applies a level of scrutiny that is commensurate to the perceived security risk. In particular, message processor(s) 312 applies a lowest level of scrutiny for messages with the lowest perceived security risk (e.g. those stored in a message queue with the highest processing priority), and applies a highest level of scrutiny for messages with the highest perceived security risk (e.g. those stored in a message queue with the lowest processing priority). Refer to earlier description for examples
[0042] On processing a message, message processor(s) 312 returns to block 604 and continues processing from there, if there are additional messages to be processed for the selected perceived security risk level (e.g. the selected message queue). For the embodiments, if all messages of the selected perceived security risk level (e.g. the selected message queue) have been processed, but there remains other messages of
higher perceived security risk level to be processed, message processor(s) 312 returns to block 602, and continues processing from there. If all messages of all perceived security risk levels (e.g. of all message queues) have been processed, processing terminates.
[0043] Accordingly, the electronic message management system 101 is particularly suitable for managing unwelcome or undesirable electronic messages for an enterprise computing environment 100 and for expediting the processing and delivery of electronic messages that are important or valuable. System 101 enables the enterprise to manage the policies for electronic message management from a central location, which in turn enables the enterprise to manage electronic message acceptance/rejection uniformly, even if their equipment is geographically dispersed. Resources of computing environment 100, in particular, electronic message management system 101, may be more efficiently employed to process electronic messages, in favor of the authentic business related electronic messages. Resultantly, system 101 enables messages from of higher business importance, e.g. those from privileged business partners to be processed/attended to first.
[0044] Although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that a wide variety of alternate and/or equivalent implementations may be substituted for the specific embodiments shown and described, without departing from the scope of the present invention. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that this invention be limited only by the claims and the equivalents thereof.