BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a diagram illustrating a network for identifying spam email, according to an embodiment of the present invention;
FIG. 2 is a diagram illustrating a network for identifying spam email with an augmented domain name server, according to an embodiment of the present invention;
FIG. 3 is a flow diagram illustrating a spam identification methodology, according to an embodiment of the present invention;
FIG. 4 is a flow diagram illustrating an augmented domain name server entry retrieval methodology, according to an embodiment of the present invention;
FIG. 5 is a flow diagram illustrating an augmented domain name server organization methodology, according to an embodiment of the present invention;
FIG. 6 is a flow diagram illustrating an augmented domain name server spam indication methodology, according to an embodiment of the present invention; and
FIG. 7 is a diagram illustrating an illustrative hardware implementation of a computing system in accordance with which one or more components/methodologies of the present invention may be implemented, according to an embodiment of the present invention.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS
As will be illustrated in detail below, the present invention introduces techniques for classification of received email for the purpose of filtering out spam email.
Referring initially to FIG. 1, a diagram illustrates a network for identifying spam email, according to an embodiment of the present invention. In the present environment, senders and receivers of email are facilitated by Internet connection services and infrastructure, and corresponding mail servers. In this environment, there is at least one spammer's client system 102 and at least one receiver's client system 104. Spammer's client system 102 may generate spam which can be distributed by a corresponding spammer's mail server 106, or may transmit packets which bypass spammer's mail server 106 because they conform to the proper content to be acceptable to a typical receiver's mail server 108. Thus, the embodiments of the present invention are not restricted by the spammer's adoption of a sending mail server.
The typical flow of spam is as follows: spam is generated at a spammer's client system 102, forwarded optionally to an intermediate spammer's mail server 106, via a network, such as, for example, the Internet 110. The email is forwarded to receiver's mail server 108 and subsequently retrieved by a receiver at receiver's client system 104. Receiver's mail server 108 may potentially identify some spam by deploying known spam email detection techniques. However, without embodiments of the present invention deployed at receiver's email server 108, cleverly disguised spam may not be detected, and consequently may be presented as inbound mail to the receiver at receiver's client system 104.
Referring now to FIG. 2, a diagram illustrates a network for identifying spam email with an augmented domain name server, according to an embodiment of the present invention. A special augmented domain name server (ADNS) 212 is employed to maintain a copy of the Internet domain registry. The registry is comprised of information concerning the ownership, origin date, term ending date and authoritative name servers for domains. ADNS 212 contains this information as entries within a cache. Entries include a flag designating whether the entry details a known spam site and a timestamp that records the first time the DNS entry was recorded. In general, the newer the domain, the more likely it will come under scrutiny as a potential spammer domain. A more detailed description of the functionality of ADNS 212 is provided below in FIG. 4.
In accordance with an embodiment of the present invention, a spam detection flow is described as follows with respect to FIG. 2: The spammer generates spam email at spammer's client system 202 which, as in FIG. 1, is forwarded optionally to an intermediate spammer's mail server 206 via the Internet 210, ultimately reaching receiver's mail server 208. Receiver's mail server 208 performs specialized checking, a more detailed description of which is provided below in FIG. 3, to determine whether the email is likely spam. In so doing, receiver's mail server 208, using a local network 214, may access archived information on ADNS 212. If identified as spam, receiver's client system 204 is spared the inconvenience of receiving spam email because the spam may be sorted into a separate inbox designated for spam or automatically discarded.
Referring now to FIG. 3, a flow diagram illustrates a spam email identification methodology, according to an embodiment of the present invention. In block 302, the mail server accepts a new email. In block 304, the straightforward or obvious uniform resource locators (URLs) are enumerated or reduced to the simply identified domains or explicit Internet Protocol (IP) addresses. These domains and IP addresses can then be referenced either in a maintained cache of know spam entities in accordance with the system of FIG. 1, or by the augmented domain name server in accordance with the system of FIG. 2, in block 306.
The invention is not limited to the maintenance of a dynamic registry or to a local cache. The collection of entries can simply be a “blacklist” of domains and IP addresses known to be spam-ridden. Each entry contains standard information as described above plus the spam flag and the first identified timestamp. A domain as described in this invention is not limited to the base Internet assigned domain. Instead, the domain name may be a “name-dot-domain” extension to an existing domain, because that extension might be the only part that is producing spam. In this description, “domain” will refer to either the Internet domain or an extension referring to an Internet resource. If the domain is found to be in the “blacklist” or the augmented domain name server's cache the determination concerning likelihood of being spam can be obtained. The finding could be the discovery of an extremely new domain entry and although not marked with the spam flag, it might be tentatively marked as spam. In such an application, it would be expected that the receiver would periodically check the separate inbox, provided for spam to validate the results.
Referring back to the methodology of FIG. 3, if the test of block 306 yields a positive spam result, the methodology terminates at block 308 and the email is maintained as spam or discarded. If the test of block 306 yields a negative spam result, it remains possible that a spam email contains hypertext, or a hyperlink, that does not obviously translate to a known spam target URL. In block 310, it is determined if the email contains at least one HTML or other suitable browser-interpretable script. If no such scripts exist, the methodology terminates at block 312, where the email is maintained as non-spam email. If such scripts are found to exist, the methodology continues to block 314 where a succession of user interactions are processed using an apparatus to emulate the end user action via a simulated invocation of the target script to potentially expose more content for verification. If it is determined that any enumerated URLs are spam in block 316, then the email is maintained as spam and the methodology terminates at block 308. Otherwise, the email is maintained as non-spam email and the methodology terminates at block 312.
Referring now to FIG. 4, a flow diagram illustrates an augmented domain name server entry retrieval methodology, according to an embodiment of the present invention. The process of determining if a URL comes from a spammer domain is performed by requesting a lookup by the ADNS in block 402. In block 404 it is determined if an entry exists. If an entry exists, the entry is found and returned to the caller in block 406 terminating the methodology at block 408. If an entry does not exist, the ADNS will obtain ADNS resource records in block 410 and create a new entry with its spam flag “off” in block 412, before returning same to the caller in block 406 and terminating the methodology in block 408.
Referring now to FIG. 5, a flow diagram illustrates an augmented domain name server organization methodology, according to an embodiment of the present invention. The augmented domain name server can be used to maintain a dynamic list of domains. As described previously, data name servers provide information concerning the registry for a domain. Three scenarios are now described below with respect to FIG. 5.
The methodology begins at block 502, where ADNS receives routine DNS information. In block 504, it is determined if the information includes a new entry. If a new entry is included, it is cached along with a “first seen” timestamp in block 506 with the spam flag “off”. If a new entry is not included, it is determined if the information includes an update or reactivation of a previously received entry in block 508. If the information includes an update or reactivation, the relevant changes are copied without affecting the “first seen” timestamp in block 510. If the information does not include an update or reactivation, it is determined if the information is for deletion of an entry in block 512. If the information is for deletion, the previously existing cached entry is repopulated but the spam flag and the “first seen” timestamp is not disturbed in block 514. The methodology terminates at block 516, after blocks 506, 510 and 514, or for those updates that are not important to the functioning of the ADNS. The probability that a given entry is filtered out as spam is determined in accordance with the “first seen” timestamp of the entry. More specifically, an entry is weighted higher as probable spam when a “first seen” timestamp is first created. Additionally, an entry is weighted less as probable spam as time passes from the “first seen” timestamp.
Referring now to FIG. 6, a flow diagram illustrates an augmented domain name server spam indication methodology, according to an embodiment of the present invention. The spam flag may be adjusted by a call to the appropriate service in the ADNS in block 602. The flag is cleared or set in accordance with the call parameter in block 604, and the methodology terminates in block 606. Such update calls may result from receiver feedback through the receiver's mail server. Other updates may occur by agents that collect information from other sources.
Referring now to FIG. 7, a block diagram illustrates an exemplary hardware implementation of a computing system in accordance with which one or more components/methodologies of the invention (e.g., components/methodologies described in the context of FIGS. 1-6) may be implemented, according to an embodiment of the present invention.
As shown, the computer system may be implemented in accordance with a processor 710, a memory 712, I/O devices 714, and a network interface 716, coupled via a computer bus 718 or alternate connection arrangement.
It is to be appreciated that the term “processor” as used herein is intended to include any processing device, such as, for example, one that includes a CPU (central processing unit) and/or other processing circuitry. It is also to be understood that the term “processor” may refer to more than one processing device and that various elements associated with a processing device may be shared by other processing devices.
The term “memory” as used herein is intended to include memory associated with a processor or CPU, such as, for example, RAM, ROM, a fixed memory device (e.g., hard drive), a removable memory device (e.g., diskette), flash memory, etc.
In addition, the phrase “input/output devices” or “I/O devices” as used herein is intended to include, for example, one or more input devices (e.g., keyboard, mouse, scanner, etc.) for entering data to the processing unit, and/or one or more output devices (e.g., speaker, display, printer, etc.) for presenting results associated with the processing unit.
Still further, the phrase “network interface” as used herein is intended to include, for example, one or more transceivers to permit the computer system to communicate with another computer system via an appropriate communications protocol.
Software components including instructions or code for performing the methodologies described herein may be stored in one or more of the associated memory devices (e.g., ROM, fixed or removable memory) and, when ready to be utilized, loaded in part or in whole (e.g., into RAM) and executed by a CPU.
Although illustrative embodiments of the present invention have been described herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various other changes and modifications may be made by one skilled in the art without departing from the scope or spirit of the invention.
Patent Application
20070271343
