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 the control of electronic messages, e.g. offensive electronic messages, including employment of entity risk classification.
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 and viruses.
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 prioritizing important business communications ahead of unsolicited, unwelcome messages.
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:
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 the employment of entity risk classification (or contributing to).
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.
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.
Referring now to
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.
As will be described in more detail below, in various embodiments, boundary mail server 104 includes a mail transfer agent (MTA) component 302 and a mail filter component 304 (
Continue to refer to
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.
In various embodiments, one of the internal servers, e.g. mail management server 114, may also be used as an analysis server, to facilitate analysis of various suspicious electronic mails by administrators of enterprise computing environment 100.
Referring now to
24 The term “entities” as used herein refer to any entities (of interest) associated with the messages handled by the system, including in particular, but are not limited to, senders of the messages, and servers involved in the originating and forwarding of the messages to the system. Of course, senders of the messages may include, but are not limited to, individual senders, business partners (domain), mailing lists, and so forth. In alternate embodiments, more or less message associated entities may be tracked and/or risk classified. In some embodiments, the message associated entities that get risk classified may be less than the message associated entities tracked.
In various embodiments, lists 208 may include a white list and a black list. For these embodiments, membership with the white list denotes the risk perceived to be within an acceptable low level. Accordingly, messages associated with members of the white list may e.g. be automatically accepted (or alternatively, automatically accepted unless other dangerous signs are present). Similarly, membership with the black list denotes the risk perceived to be above an unacceptable high level. Accordingly, messages associated with members of the black list may e.g. be automatically rejected (or alternatively, automatically rejected unless other mitigating signs are present).
In various embodiments, lists 208 further include a green list. For these embodiments, membership with the green list denotes the risk perceived to be relatively low, but not necessarily below the acceptable low level. Accordingly, messages associated with members of the green list may e.g. be biased for acceptance, subject to one or more additional confirmation analysis, when considering for acceptance or rejection.
In various embodiments, lists 208 further include a yellow list. For these embodiments, membership with the yellow list denotes the risk perceived to be relatively high, but not necessarily higher than the unacceptable high level. Accordingly, messages associated with members of the yellow list may e.g. be biased for rejection, subject to one or more additional rebuttal analysis, when considering for acceptance or rejection.
Of course, in various embodiments, more less lists may be employed, and the risk levels separating the various lists are application dependent, and may vary from implementation to implementation.
Still referring to
Additionally, for the illustrated embodiments, mail management server 114 also includes risk assessment and classification engine 214 adapted to assess the risk associated with accepting a message associated with a tracked entity. Further, risk assessment and classification engine 214 is adapted to organize and enroll the tracked entities as members of lists 208, based at least in part on their assessed risks.
For the illustrated embodiments, mail management server 114 also includes a number of scripts 222, including pull script 224 and push script 226. The former, i.e. pull script 224, is adapted to facilitate pulling of message handling information from boundary mail servers 104, including creation of the above described tracked entities and message records 204 and 206, based on the message handling information pulled. Whereas, the latter, i.e. push script 226, is adapted to facilitate pushing of the most current version of lists 208 onto boundary mail servers 104 for use to manage message ingress. The arrangement allows boundary mail servers 104 to operate more efficiently, without having to access mail management server 114 across the enterprise's internal network during operation.
In alternate embodiments, in lieu of the pull and push script 224-226, scripts adapted to “push” message handling information onto mail management server 114, and “pull” the current version of lists 208 from mail management server 114 may be provided to the boundary mail servers 104 instead.
Continuing to refer to
Referring now to
Further, for the embodiments, mail server 104 includes MTA 302 and mail filter 304. As described earlier, MTA 302 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 mail filter 304 is adapted to determine whether a received electronic mail is to be accepted or rejected. For the embodiments, mail filter 304 employs lists 328 when performing the acceptance and rejection determination. In various embodiments, mail filter 304 may also employ other tools, when performing the acceptance and rejection determination, including but not limited to the header analysis technique described in co-pending application Ser. No. 11/036,916, filed on Jan. 14, 2005.
For the illustrated embodiments, mail filter 304 further includes tracker 306 for extracting and tracking entities associated with messages, allowing the tracking operation to be integrally performed as part of the filtering process. As described earlier, the tracked entities may be individual senders, business partners (domain), mailing lists, and so forth.
For the embodiments, mail server 104 also includes one or more persistent storage units (or storage media) 312, employed to stored management databases 202 and management data structures 212. Further, mail server 104 includes one or more processors and associated non-persistent storage (such as random access memory) 314, coupled to storage medium 312, to execute MTA 302 and mail filter 304. For these embodiments, MTA 302 and mail filter 304 (including tracker 306) are implemented in software. In alternate embodiments, MTA 302 and mail filter 304 (including tracker 306) may be implemented in hardware, in part or in whole.
Referring now to
Next, mail sender 120/110 sends the electronic mail through the conversation session, op 406, and MTA 302 accepts the electronic mail, and provides a copy of the received electronic mail to mail filter 304, to determine whether the electronic mail is to be accepted or rejected, op 408.
In response, mail filter 304 analyzes the electronic mail, employing lists 328 (and optionally, other analysis tools), as earlier described, op 410. Mail filter 304 characterizes the electronic mail, based at least in part on the result of the analysis, and makes an accept/reject determination for the electronic mail, op 410. In various embodiments, if a sender is of sufficient high risk per lists 328, mail filter 304 rejects the electronic mail, regardless of whether servers associated with the electronic mail are high risk or not. Likewise, in various embodiments, if a server associated with an electronic mail is of sufficient high risk per lists 328, mail filter 304 rejects the electronic mail, regardless of whether the sender and other servers associated with the electronic mail are high risk or not. In other embodiments, other acceptance/rejection criteria may be employed, i.e. they may vary from implementation to implementation.
Additionally, for the illustrated embodiments, mail filter 304 further invokes tracker 306 to integrally perform the entity tracking operation, as described earlier. Operation of tracker 306 will be further described below.
Still referring to
If the electronic mail is to be accepted, MTA 302 forwards the electronic mail to the appropriate internal mail server 110, op 416. Further, if instructed, MTA 302 further sends a copy of the electronic message to an analysis server, e.g. mail management server 114, op 416.
In various embodiments, the electronic mail is provided from mail sender 120/110 to MTA 302 in parts, in particular, first an identification of the sender, followed by identifications of the recipients, and then the body of the electronic mail, and MTA 302 invokes mail filter 304 to determine acceptance or rejection of the electronic mail for each part. In other words, the electronic mail may be rejected after receiving only the identification of the sender, or after receiving identifications of the recipients, without waiting for the entire electronic mail to be provided. Again, the approach may have the advantage of efficient operation.
In alternate embodiments, the filtering operation, including the employment of lists 208, may be practiced after the entire electronic message has been received. In particular, lists 208 may be employed for an initial pass to determine whether to accept the electronic messages or subject them to additional analysis, thereby allowing decisions to accept electronic messages from trusted/proper entities more efficiently made.
Having now described an example environment for practicing the present invention, we refer now to
Each of the data objects 502-508 includes appropriate pointers associating the data objects, i.e. associating tracked entities (senders and servers) with messages handled, and vice versa, as well as associating tracked entities (senders and servers) with the various lists of (of varying perceived risks).
In alternate embodiments, other data structure and/or organization may be employed instead.
For the illustrated embodiments, the message activity information includes at least the messages the entities are associated with. In various embodiments, message activity information may also include the number of recipients addressed, the frequency of addressing these recipients, the average size of the messages, and other metrics of the like.
For the embodiments, after all messages have been processed for a tracked entity, block 808, engine 214 determines a risk classification for the tracked entity, block 810. In various embodiments, engine 214 determines the risk classification based on the risk metric associated with the tracked entity. For the embodiments, upon determining the appropriate risk classification, engine 214 enrolls the tracked entity as a member of an appropriate one of lists 208 accordingly, block 810, if the tracked entity is a tracked entity being classified for the first time. For tracked entity having been previously classified, engine 214 may de-enroll and re-enroll the tracked entity accordingly. For example, if the risk metric begins to indicate a sufficiently higher degree of risk, engine 214 may move the tracked entity from e.g. the earlier described example green list, to the earlier described example yellow list. Similarly, if the risk metric begins to indicate a sufficiently lower degree of risk, engine 214 may move the tracked entity from e.g. the earlier described example yellow list, to the earlier described example green list.
The process 800 is repeated for each tracked entity.
Accordingly, the electronic message management system 101 is particular suitable for managing unwelcome or undesirable electronic messages for an enterprise computing environment 100. 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. Further, system 101 enables unwelcome or undesirable electronic messages to be rejected outright, lessening wasteful network traffic on the internal network. Still further, system 101 enables the acceptance/rejection determination to be more efficiently and reliably performed, with the employment of entity risk classification.
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.
The present application is a non-provisional application of provisional application 60/540,997, entitled “Multi-class Messaging and Trusted Senders”, filed on Feb. 2, 2004. The present application claims priority to said provisional application, and incorporates its specifications by reference, to the extent the '997 specification is consistent with the specification of this non-provisional application.
Number | Date | Country | |
---|---|---|---|
60540997 | Feb 2004 | US |