^' TECHNICAL FIELD

[0001 ] The present invention relates to the field of electronic messaging generally and in particular to .methods for filtering unsolicited email.

BACKGROUND

[0002] Email over the Internet and other networks have become a mainstay of business and personal communications. Email over the Internet is typically sent using the Simple Mail Transfer Protocol ("SMTP"), a popular text ^" baaed mail transport and delivery protocol. SMTP is defined in The Internet Society Request of Comment ("RFC") No. 2821 (April 2001.), which is hereby incorporated by reference,

[0003] SMTP contemplates that transmission of emails occurs from a sending user's host (or "originating server") to the receiving user's host (or "receiving server") when the two hosts are connected to the same network such as the Internet or other transport service or connected to different networks coupled by a gateway,

[0004] Under SMTP, the sending and receiving servers establish a

Communications connection over the transport service. Then, the originating server (sometimes referred to herein as the remote server) initiates a mail transaction, which includes commands to specify certain information about the session, including the originator and destination of the mail. This information is referred to as the "envelope.'" Next the originating server sends a command to transmit the message content itself. The message content is composed of a header and a body. The header includes structured field/value pairs. The body is the actual message which can be formatted in accordance with MIME, for example.

[0005] The receiving server responds to each command with a reply. For example, replies indicate dial die command, was accepted or that a temporary or permanent error condition exists. Replies include three digit codes (such as "250").

[U006] Unsolicited hulk email C'UBh")- popuiaily known as -spam," is 3 growing problem for email users. Spam clogs users' uiboxes, wastes netwojk bandwidth consumes human and machine resources to evaluate and diseaid, and often is used to disseminate malicious rode or perpetrate fraud or other nnlawlυl or undesirable activity.

[0007] A number ol approaches have beet! proposed to address tlie piobletn ol

UBIL One approach is to assess the content incoming email and to hltcr out messages with certain content associated with UBE However, senders quickly adapt eoutenf to circumvent these systems. In response, ever more aggressive content fillers may be utilized. However, this leads to IaWe positives - that is, legitimate emails that ate lla ¹ OtiR eλed or filtered as UBF.

[0008J When legitimate emails are filtered as UBH, itseis do not recehe potentially important communications. 1 0 mitigate this risk, filtered UBE can be placed into a quarantine for periodic review by the user. However, this consumes human and machine resources and can delay tcceipt of an urgent legitimate email that is mistakenly illteied as UBE pϊaee imo quaiantine.

[0009] Another approach is to post suspect UBE scndtus on a deny list

However, spenders of spam will frequently change servers, sometimes hijacking otherwise legitimate systems. This countei -tacue lniiiis the effectiveness of the deny list

[00 ! 01 Another approach dial has been adopted is the challenge 1 espouse system, in which the recipient mail server sends a diallenge to unknown mod sender and qu _' iidutuies the sender s løaii until the sender provides an appropriate ttλponso to the challenge. A drawback fo tins system is tfuit it imposes delay and inconvenience on legitimate but unknown sendfis. Also, if a legitimate sundei aoai nut toi whafevft reason respond to the chalk nf_f, *heu the inconiiuξ? entail will not be received

{001 1 ] It would be desirable to more completely liitef UBIv while avoiding mistakenly ftUentig legitimate email, As used in this application, the teυn "legitimate" means a message othei than URE or other types of bulk email that aie

either prohibited by law or that are communications that computer users generally do not wish to receive. The term "legitimate' ^' as applied to a sender or connection .means a sender or connection not engaged in sending UBE.

SI1MMδRY ULXHKJN VENiIQN

(0012] A method and apparatus is provided tor filtering UBE, In accordance with one aspect of the invention, a method is provided for processing a message sent hy a remote server in accordance with a communications protocol, such as SMTP, The method includes establishing a Communications connection with the remote server, accepting from the remote server data pertaining to the connection, including information pertaining to at least one of the following: the remote server, the sender of the message, the destination of the message, and determining if the data pertaining to the connection meets criteria associated with legitimate messages. If the data pertaining to flie connection does not meet the criteria associated with legitimate messages, then a stimulus signal is sent, to the remote server. Further processing of the session then proceeds depending on whether the remote server responds to the stimulus signal in the manner required by the communications protocol.

J0013] in accordance with another aspect of the invention, an apparatus is provided for processing a message sent by a remote server in accordance with a communications protocol. The apparatus includes a Communications port adapted for establishing a communications connection with the remote server, a database of known connections, and a processor coupled to the communications port and the database of known, connections. The processor is programmed to accept as input from the remote server data pertaining to the connection, including information pertaining to one or more of the remote server, the sender of the message and the destination of the message. The processor uses the database of known connections to determine if the data pertaining to the connection meets criteria associated with legitimate messages. The processor sends a stimulus signal to the remote server if the data pertaining to the connection does not meets the criteria associated with legitimate messages. The processor processes the connection in response to whether the remote

server responds to the stimulus signal in the manner required by the communications protocol.

[0014] In accordance with yet another aspect oi ^' tho invention, computer program product is provided for processing a message sent by a remote server. The computer program product includes a computer data storage medium and computer program instructions recorded on the computer data storage medium. The computer program instructions are executable by a computer processor. When executed, the instructions cause the processor to accept as input from the remote server data pertaining to the connection, including information pertaining to at least one of the following: the remote server, the sender of the message, the destination of the message, determine if the data pertaining to the connection meets criteria associated with legitimate messages, semi a stimulus signal to the remote server if the data pertaining to the connection does not meet the criteria associated with authorized messages, and process the connection in response to whether the remote server responds to the stimulus signal in the manner required by the communications protocol.

BRIEF DESCRIPTION OF THR DRAWINGS

[0015] The description herein makes reference to the accompanying drawings wherein like reference numerals refer to like parts throughout the several views, and wherein:

[0016] FK). 1 is a block diagram of an email system in which embodiments of the present invention are implemented.

[0017] I ¹ MG. 2 is a block diagram illustrating in greater detail a filtering module for use in the email system shown in FSG. 1.

[0018} FIG. 3 is a flow chart of the operation of the filtering module of FlG.

2 in accordance with a first embodiment of the invention;

[0019] FlG. 4 is a How chart of the operation of the filtering module of FlCX 2 in accordance with a second embodiment of the invention;

[0020] FKl. 5 is a flow chart oi ^' tbc operation of the filtering module of FiG. 2 in accordance with a third embodiment of the invention;

[0021] FiG, (S is a block diagram of an email system iu accordance with a fourth embodiment of the invention; and

[0022] FIG. 7 is a block diagram of an email system in accordance with a fifth embodiment of the invention.

DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023 J Referring to FIG. ϊ, an email system 10 is illustrated in which embodiments of the present invention are implemented. Email system 10 includes a receiving hosf 12 and an originating server 14 in communications via the public Internet 16 to transfer email using SMTP, The disclosed embodiments can be implemented using any suitable messaging protocol and is not limited to email or SMTP. The disclosed embodiments can also be implemented over any suitable type of network and are not limited to use with the public Internet,

[0024] Receiving host 12 includes an receiving server 18 coupled to a file system 20 and a mailbox 22. Other configurations for receiving hosf 12 are possible and ancillary equipment and software such as firewalls have been omitted for ease- of understanding the invention. A desktop email diem 24 such as Microsoft Outlook ^{1 M} ji, coupled to the mailbox. Originating host [4 includes a remote or originating server 26 that is coupled to a file system 28. With respect to its outgoing email Communications, originating server 26 is sometimes referred to as the client in the SMTP specifications.

j 00251 In accordance with SMTP, originating server 26 on host 14 initiates a connection with server 18 on host 12 for purposes of transmitting one or more emails in the course of a communications session. The communications session includes a

series of commands issued by originating server 2.6 and replies issued by receiving server 18. The following table illustrates a simplified session between a receiving server ("S") and an originating server ("C'):

Table One

[0026] 220 vww . foo . com ESMTP post f ix

11 E L LO t a r g e t . α oiu

250 Hello L a r qe t , c om

MA IL FROM ; <s ende r Q t: 3 rget , cocα>

250 Ok

RCPT TO: < ^" recipient!?f00. coκι>

250 Ok

DATA

354 End data wi t h <CRXLF> . <CR,><LF>

Subj ect : tes t: message

From : sencle r^ targe t: . com

To ; recip ienn? foo . coxa

Tes t data ,

£50 Ok: queued as .12345

QOIT

221

[0027] In each session, the originating server 26 transmits data that initiates, constitutes or otherwise pertains to the session itself before transmitting the message content. This session information, also known as session data, can be contained in the message envelopes or can be Information, derived from the syntax, order or context of the session commands transmitted by the originating server, For example, session information can include the IP address of the originating server, envelope sender of the message, and the envelope destination of the message, Part of this information is typically placed in a message envelope. After receiving and processing the envelope, the server 18 receives the message content, which comprises a header section and a body.

[0028] It is desired to filter UBK and other unauthorized messages that are sent to receiving host 12. Referring to FIG. 2, a tillering system 30 which resides on SMTP server 18 .filters incoming SMTP sessions to temporarily reject UBE and other unauthorized messages. Aa will be explained below, temporary rejection of messages

can occur after the envelope Ls received buf before the message content is transferred to the receiving hosts. For ease ot ^' iUusirauon, Filtering module η) LS disclosed heroin as software Implemented only ΌU SM TP server 18. However, the programming logic of Oltering module 30 can be distributed over more thaυ oυe computer oi implemented in hardware if desued.

[0079 J Filtering system 30 includes a connection assessment module 32, a eouteλt assessment module 34 and a connection behavior testing module ^6. Connection assessment module M ami context assessment module 34 assesses tile data pertaining to fhe session for new connections to determine whether that data meets criteria associated with legitimate email. These criteria are discussed below in detail, but gencialiy speaking can include primary criteria (which if met mean thai a conned ion is legitimate and will be accepted) and secondary criteria (which if met mean that a connection is possibly legitimate but will not at this time be accepted, instead iufoπnatioti about the connection will be recorded for use in future sessions involving the same originating server and sender),

[0030J Connection assessment module 32 is in communication's with a database 38 which includes information about known connections including historical transactions with known connections. Database 38 can reside locally on receiving host 12 or can be hosted remotely and can include information gathered by leeching host 12 or by multiple hosts. Database 38 can be a single database or can be distributed in different physical databases. Connection assessment module 32 assesses the information us the envelope to determine whether the connection is a priority connection or at least a known connection A priority connection is a connection identified in database 38 as legitimate. Priority connections can be idemiiitd m the database by the IV address of the originating server, the envelope sendci the envelope destination or a combination of all ihret..

[00 } ! ] A " ^' Known'" conπeeHυn is a connection that has snrnUu dmsacteristies as connections previously established with the receiving server 18. Snch similar chai actcristics can include the IP address of the originating server, envelope sendci, envelope desunatiou, subnet foi the originating sen er 26 ( )nce connection

assessment modulo 32 identifies a connect ion as being known, ii can query diabase 38 for historical transaction data involving ihc eounecύoo Io determine if the connection is legitimate, This historical transaction data can include for example the number of ptevious times that tbe cormec ύon iuis attempted delivery. If the numbei of attempted deliveries exceeds? a predetermined threshold (such as three for example), then the connection can be considered both known and legitimate. Other historical data that can be used to validate a eonnectiou includes the anxmm of time I hat has elapsed since the connection was last established with the destination seiver or with any server belonging to a given set of destination servers, with longer Umc periods indicative of non-UBE messages.

100321 Connection assessment modtilc 32 can use other criieria to determine if a connection is priority, lαiown or otherwise legitimate. Criteria should be selected that are associated with legitimate messages,

[0033] Context assessment module M can be applied to previously unknown connections. Context assessment module 34 can also coupled to database 38 as well as externa! tesoui ces 40. Context assessment module 34 applies additional inquiries or criteria based on information other than the data pertaining to the connection that is transmitted by the originating server, fhe^e contextual inquiries can include:

is the remote servei on only one black list? [-J Ii yes]

is the remote server on more than one black list? [-3 if yesj

is ihc remote sei ver on a local white-list? 1+5 if yes |

has the remote serves attempted delivery of an email to a large nunibej < ^■■ >( different desiinaiious over a short period of time-'' j-2 if ya>]

iti ύiG s emote serves not allowed to send emails as part of the domain specified in the envelop render? [-5 if ye.sj

does the t-rse DNS of the remote sen-er snatch the .sender information in die envelope? [ } 1 if yes, -1 if no]

is the remote server known on the local server as a server with which connections are often established? [1-2 of yes]

[OU34] A heuristic approach can be used For assessing context. F ¹ Or example, each inquiry or criteria can be assigned a given weight (as illustrated in brackets above) and an overall context assessment score can be computed adding up the resulting scores, Jf the context assessment achieves a predetermined minimum score (such as 6 using the weightings illustrated above), the context of the connection is deemed favorable. Otherwise, the context Ls deemed unfavorable. Other suitable scoring schemes and algorithms can be used,

[0035] Behavior testing module 36 can be applied to those connections who are neither priority or known and that have either favorable or unfavorable contexts. Behavior testing module generates a reply or other stimulus signal which is transmitted to the originating server to determine whether the originating server will respond iti the manner required by SMTP or ihe applicable protocol under which the message has been transmitted.

[0036] To comply with SMTP or other protocol requires time and resources.

Senders of UBR and other unauthorized messages are motivated to send many millions of messages as cheaply and quickly as possible, and accordingly they do not choose to expend the time and resources required to comply with the protocol.

[0037] If an originating server complies with the applicable protocol, it is more likely to be operated by a legitimate sender of email (as opposed to a spammer) and accordingly the message is likely to be legitimate. On the other hand, if the originating server does not comply with the applicable protocol, it is more likely a spammer and accordingly the message is likely to be UBE or oilier unauthorized email.

[('0381 Various stimulus signals may be employed, including: transmitting queries that are not frequently used; transmitting a reply after a delay of at ten to thirty seconds or more since the originating server's command is received; transmitting a

J)-

teply that requires flic originating server to send messages one at a time, and nni accepting commands ihat arc transmitted in the wrung order.

[0Oi^j More thatj one stimulus signal can be used. Other suitable stimulus signals can be used. Information about how the originating, server 26 responds fo the stimulus signal oi signals can be added to database 38. S'Or oainμic, if originating bcrver 26 responds to flic .stimulus signal or signals hi aocoϊdanee with SMTP os other applicable ptotocol, ihen the connection cau be added to database 38 as a known connection.

[0040] Referring to FIG 3, the operation of filtering system 30 is illustrated in accordance with a first embodiment. Beginning at block 42, a connection is established ovei the Internet between originating server 26 and receiving sei vei 18. λt block 44. originating server 26 sends and receiving server 18 receives session data, At block 46, the receiving server I K uses the filtering system ?ϋ to assess the session data, As illustrated in block 48, this assessment will include queries to database 38 as well as other external resources (not shown in FIG ^" V).

fθt)4 1] As explained above, the assessment of session data can be made using eitlier or both υi ^' connection assessment module 32 and context assessment module }A. The objective of the assessment is to apply to the session data one or more festp or other criteria that are associated with the authentic messages. For example, connection assessment module 32 can determine if the connection is a piiσrUv connection. Context assessment module 34 can apply additional tests oi criteria tυ previously unknown connections, such determining whether the remote server is on a black list The invention is not limited to specific tests or criteria thru make use of session data. Other appropriate tests uud ciiteria will occur to those skilled in lhe art oj electronic messages and these can be used as well

[0042] λi derision block 5U- a determination is made as fo whether the session dala has met the applicable tests or other ciiteria to conclude that lhe eouυeetion us legitimate. If the session data has met the test or other eritcda, then control mo\es to block 52, who e the filtering system K) accepts tlie message content. If the session data docs not meet the test or other criteria then control moves to block 5<1, when,

connection behavior testing module 36 sends a stimulus to originating server 26 to determine if originating server 26 is compliant with SMTP or other applicable protocol.

[0043] At decision block 56, a determination is made as to whether the behavior of sending server 26 is compliant with SEvITP or other applicable protocol, IT the behavior is compliant, contra! moves to block 58. where database 38 is updated with information about the connection. For example, the connection may be indicated as a '"known' ¹ or "priority" connection in database 38. Control then moves to block 52, where the filtering system 30 accepts the message content.

[0044] ϊf at block 56 it is delerrøiued that the behavior of originating server 26 is not compliant with SMTP or the applicable standard, then control moves to block 60, where the session is temporarily rejected. Rejection can be accomplished by sending a reply to the originating server 26 that indicates the occurrence of a temporary error or other problem at the receiving server 1 S and can request the originating server 26 to rεsend the message. For example, with the SMTP protocol a 4xx reply may be sent.

[0045] A temporary error reply is in effect another means of testing behavior of the originating server. Servers that send UBE or other unauthorized messages typically do not. comply with requirements under SMTP or other protocols to resend messages after receiving a temporary error response. Thus, UBB or other unauthorized messages will likely not be resent, thus reducing spam. However, legitimate messages from legitimate sources are likely to be resem, Alternatively, at block 6O ₅ the session can be rejected a non-temporary basis.

[0046] At block 60, database 38 can be updated with information from the envelope of the rejected connection, which can be deemed as "known ^*5 even if rejected, Because spammers are unlikely to reestablish the connection, the database may accumulate a large number of connections that have been seen only once or seen multiple times, but only during a single, short time period such as an hour for example. 1 hese one-time connections can be periodically purged from the database.

^■ I I-

Alternatively, they can be removed if they were last seen more than, for example, twelve months ago.

[0047] Referring to FKJ-. 4, the operation of filtering system 30 is illustrated in accordance with a second embodiment. Beginning at block 62, a connection is established over the Internet between originating server 26 and receiving server 18. At block 64, originating server 26 sends and receiving server 1 8 receives session data. At block 66, the receiving server 18 uses the filtering system 30 to assess the session data, As illustrated in block 68, this assessment will include queries to database 38 as well as other external resources (not shown in FlG. A).

10048] λs explained above, the assessment of session data at block 66 can be made using either or both of connection assessment module 32 and contexi assessment module 34. The objective of the assessment is to apply to the session data one or more tests or other criteria that are associated with the authentic messages. For example, connection assessment module 32 can determine if the connection is a priority connection. Context assessment module 34 can apply additional tests or criteria to previously unknown connections, such determining whether the remote server is on a black list. The invention is not limited to specific tests or criteria that make use of session data. Other appropriate tests and criteria will occur to those skilled in the art of electronic messages and these can be used as well.

[0049] The tests and criteria that are applied at decision block 66 can be placed info two or more groups including primary criteria and secondary criteria. Primary criteria are tests or other criteria which, if met, indicate that the connection is authorized or otherwise legitimate, F ¹ Or example, a primary criteria can be that the connection is a priority connection on database 38. Another primary criteria can be that the connection is known and that the historical transaction data for the connection indicates that it is legitimate.

[0050] Secondary criteria are tests or other criteria which if met indicate a possibility that a connection is authorized. For example a secondary criteria can be that a connection is known (but is not associated wilh historical transaction data indicating legitimacy) based on the content of database 38, Another secondary

critei U can be that the eouumiυii. if not known, at least has a favorable context as determined by context assessment module 34

[0051] λt decision block 70 a del et ruination JLS nuulϋ as to whether the session data has met the applicable primary criteria. If the session data has rurt piimaiy eπtem, iben control moves to block 72, where fiu; filleting system >0 accepts the message contera. If the session data does not meet the primary criteria, then control moves to decision block 74 where dctei initiation is made as to wliethei the session data meets the secondary CJ iferia. 11 the session data has met the secondary criteria, then control moves to block 76 where database >8 is updated with information about the connection. For example the connection may be indicated as a " ^" known" or "priority" connection in database 38. Control then moves to block 78 where filtering <3>stem 30 rejects the connection t\ _* described below,

[C)05?J If at decision block IA it is determined that the session data has not met the sccondaiy criteria, then coπtiol moves to block 80. where connection behavior testing module id sends one oτ moie stimulus .signals to originating seiυer ?h to determine if oiigmating server 2ϋ is compliant with SMTP or other applicable protocol λt decision block 82, a determination is made as to whether the behavior of sending server 26 is compliant with SMFP or other applicable protocol. Sf the behavior is compliant, control moves to block 7b, where database 38 is updated with ini ^' oimafiυn about the connection, tot example, the connection may be indicated as a '"known' ^" or "priority" connection in database 18 Control then moves to block 78, where filtering system 30 rejects the connection as described below.

[005^j Ai block /8. rejection can be accomplished on a temporary -basis by sending α reply to the originating set vet 76 ύuύ indicates the occurrence of a tempo* aiv error or other pjnblem at the leuervmjx servcx 18 and can require th<" originating serve.! IU to i esend the message as explained abose Alturnutιvel>, icjedion at block 7S f.;ui be on a non-tempoi ary basis Noie that if database 38 IN updated a! block 76 ioi connections that have not meet the primary or seeondajy cnieπa, then the database may accumulate ά larye number of connections from

spammers. The one-time connections can be periodically purged from the database as described above,

[0054] In effect, the application of primary and secondary criteria divide connections into three categories of trust levels: (!) those connections that have sufficient indications of legitimacy (i.e., meet the primary criteria) and are therefore considered legitimate; (2) those connections that have intermediate indications of legitimacy (i.e., meet the secondary criteria but not the primary criteria) and are therefore considered possibly legitimate; and (3) those connections that have insufficient indications of legitimacy (i.e. do not meet the primary or secondary criteria) and are therefore considered suspect. Legitimate connections are accepted. Connections that are possibly legitimate are posted to the database (step 76) and then temporarily rejected (step 78). The filtering system 30 can be programmed so that it. is more likely to treat such connections as being legitimate if they are re-established following rejection. Connections whose legitimacy is suspect are subjected to testing by connection behavior testing module 36 (step 80). If the behavior test indicate compliance with the protocol, then the connections are treated as possibly legitimate and posted to the database (step 76) and then temporarily rejected (step 78).

[0055] Connections can be divided up into more granular categories of trust by increasing the number of classes of criteria that are applied, such as primary, secondary and tertiary,

[0056] Referring to FlG. 5, the operation of filtering system 30 is illustrated in accordance with a third embodiment. Beginning at block 84, a connection is established over the Internet between originating server 26 and receiving server 18. At block 85, originating server 26 sends and receiving server 18 receives session data. At block 86, the receiving server 18 uses the filtering system 30 to assess the session data. This assessment can include queries to database 38 as well as other externa! resources (not shown in FIG. 5).

[0057] Specifically, connection assessment module 32 determines if the connection is a priority connection or a known connection. Af decision block 88, if the connection is a priority connection, then control moves to block 90, where the

filtering system 30 accepts the message content. If the connection is not a priority connection, then control moves to decision block 92. At decision block 92, if the connection is a known connection, then control moves to block 94. At block 94, connection assessment module 32 can query database 38 tor historical transaction data involving the connection to determine if the connection is legitimate. This historical transaction data can include for example the number of previous times that the connection has attempted delivery, if the number of attempted deliveries exceeds a predetermined threshold (such as three for example), then the connection can be considered both known and legitimate. Other historical data that can be used to validate a connection includes the amount of time that has elapsed since the connection was last established, with longer time periods indicative of noivUBG messages.

[0058] At decision block 96, if the connection is considered legitimate, then control moves to block 90, where filtering system 30 accepts the message content. If the connection is not considered legitimate, then control moves to block 98, where filtering system 30 updates database 38 with information about the connection. Depending on the specific algorithm used to determine if a known connection is legitimate, the accumulation of historical transaction data in database 38 can increase the chances that filtering system 30 will conclude that, a connection is legitimate. For example, a known connection can be considered legitimate if delivery is attempted N times, where N is a predetermined number between 1 and 4. Control then moves to block 100, where filtering system 30 temporarily rejects the connection.

[0059] Referring back to decision block 92, if the connection is not a known connection, then control moves to block 102, where connection context assessment module can assess previously unknown connections. Context assessment module 34 applies additional tests or other criteria to determine if the context of the connection is favorable, an explained above. Context assessment module 34 can also be coupled to database 38 as wed as to external resources 40,

[0060] λt decision block 104, if the context of the connection ia favorable, control moves to block 106, where filtering system 30 updates database 38 with

information about the connection, including adding She connection Io the list of known connection.

[0061] Referring back to decision block 104, if context assessment module 34 determines that the context of the connection is not favorable, then control moves to block 108, where connection behavior testing module 36 sends a stimulus to originating server 26 Io determine if originating server 26 is compliant with SM TP or other applicable protocol.

[0062] Al decision block 1 10, if behavior testing module 36 determines that the behavior of sending server 26 is compliant with SMTP or other applicable protocol, then control moves to block 106, where database 38 is updated with information about the connection, including adding the connection to the list of known connection. If behavior testing module 36 determines that the behavior of sending server 26 is not compliant with SMTP or other applicable protocol, then control moves to block 100, where filtering system 30 temporarily rejects the connection.

[0063] Because database 38 is updated at block 106, if the connection is reestablished in the future, it will be identified as a known connection at block 92 and potentially accepted if connection assessment module 32 determines that the connection is legitimate (block 96). Other information about the connection can be recorded in database 38 and depending on the specific algorithm used to determine if a known connection is legitimate, the accumulation of that historical transaction data in database 38 can increase the chances that filtering system 30 will conclude that a connection is legitimate in a future communications session,

[0064] Alter processing at block 106, control moves to block 100, where the filtering system 30 temporarily rejects the connection by sending a reply to the originating server 26 that indicates the occurrence of a temporary error or other problem at tile receiving server 18 and can require (in accordance with the applicable protocol) that the originating server 26 reseπd the message as explained above. Although the protocol requires the sender to resend the message, sender of 13 BE often ignore such requirements,

[00651 ^" Note that if a connection meets certain primary criteria (such as being α priority connection at decision block SS or being a known and legitimate connection at decision block 96), then the connection is considered authentic and is accepted. If a connection does not meet these primary criteria but meets certain secondary criteria (such as at least being known or having a favorable context) then infomiatiou about the connection is added to database 38 (at blocks 98 and 106), increasing the probability that it will be accepted in a future session. If the connection does not meet either the primary or secondary criteria, then the connection is rejected. However, before rejecting the connection, behavior testing module 36 tests the behavior of the originating server 26, and if the originating server 26 behaves in accordance with the applicable protocol, then information about the connection is added to the database 38 (at block 106).

[0066] Referring to FIG, 6 a block diagram of an entail system 10' illustrated in accordance with a fourth embodiment of the invention. Bm ail system 10' includes a receiving host 14'. Incoming STMP connections 1 1 1 are redirected from email system 10' to a server separate server on which a filtering system 30' resides. Filtering system 30' is substantially identical to filtering system 30 described above. Filtering system 30" accepts legitimate email hi accordance with the first through third embodiments described above and then forwards those accepted emails to the receivin •g& host 14'.

[0067] Referring to FiG. 7, a block diagram of an email system 112 illustrated in accordance with a fourth embodiment of the invention. A filtering system 30" can be part of a larger system 1 12 for processing incoming messages. Filtering system 30" is substantially identical to filtering system 30 described above. Larger system 112 includes a virus filtering module i 14, a content filtering module 1 16, an archive module J 18 and a store and forward module 120. Virus filtering module i 14 and content filtering module 1 16 arc coupled to quarantines 122 to store suspect messages. Archive module 1 IS is coupled to backup data storage 124 to hold archived messages. Larger system 1 12 can be implemented on incoming server 18,

[00681 WUuu fiitcπng system 3ϋ" is used m laigcr system 1 12, it can be placed at she iVυnt end to filter out incoming suspect incoming email messages based OD session data without the requirement ol receiving and processing message content Becan.se connections bearing suspect messages can be iemporai Iy rejected, legitimate senders will attempt iutnre deliver}' ol legitimate messages.

[0069] Hie filler nig system 30" can piuvide psocessmg effscjuieies by rejecting suspect messages based on session data because computational Iv expensive processing υf message content can be avoided. Also, because the content of suspect emails is not received, storage demands are reduced.

[0070] A ho, Hie above-mentioned embodiments have been described in order, to allow easy undei standing of the present invention, and do not limit the present invention. Un the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims, which scope is to be accorded the broadest interpretation so as to encompass all sueti modifications and equivalent structures as is permitted under the law.