E-mail management services

#Disclosed embodiments herein relate generally to e-mail management systems and more particularly to e-mail management systems (EMSs) employing traffic monitoring and management, and for managing and filtering electronic messages based on the traffic monitoring and management.

#E-mail management is commonly handled by ISPs that have user/subscribers or by companies which employs the e-mail users. A part of e-mail management comprises filtering for spam or virus control, but when such e-mail management is performed at the ISP or at the company server location, valuable communications bandwidth and computing resources are expended on routing, analyzing, and other handling of spurious e-mail traffic. Present e-mail management systems are further characterized by a lack of real-time monitoring, feedback, and updating of rules regarding e-mail traffic or SMTP connection situations. Management and monitoring of e-mail traffic situations is commonly handled through human intervention.

#Other present systems for blocking spam or viruses include systems that populate decoy email addresses around the Internet, where the decoy email addresses act as spam collectors. Human editors then review the messages that come in, catalog them, and create a database of such junk-mail messages and their checksums. The created database is then promulgated to subscribers of the service, and each message received at the customer premises is checked against the virus/spam database. Again, in this instance, the detection and monitoring of the Internet for new virus and spam messages is not in real time, and the customer premise mail server must still receive all of the spurious e-mails and then analyze all the incoming emails to see whether there is a match in the database.

#For a more complete understanding of the present invention, reference is now made to the following detailed description taken in conjunction with the accompanying drawings. It is emphasized that various features may not be drawn to scale. In fact, the dimensions of various features may be arbitrarily increased or reduced for clarity of discussion. In addition, it is emphasized that some components may not be illustrated for clarity of discussion. Reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

#FIG. 1 is a general block diagram generally describing e-mail delivery over the Internet;

#FIG. 2 is a block diagram illustrating possible placements of an active E-Mail Management System in the Internet e-mail delivery path;

#Referring initially to FIG. 1, illustrated is a prior art system 100 for the delivery of e-mail messages through the Internet 101 or other computer network. Sending mail servers 102a, 102b (having associated source Internet protocol (IP) addresses) and receiving mail servers 102c, 102d (having associated destination IP addresses), or other message gateways, allow electronic messages, such as electronic mails (or “e-mails”) to be delivered to and from sending client machines 104a-104d to receiving client machines 104e-104h, or other devices such as cell phones, pagers, and/or hand-held computers. In accordance with conventional systems, the transmission direction of the e-mails may also be reversed, where the sending machines and servers become the receiving machines and servers and vice versa.

#E-mail messages are typically composed by an application running on a client machine 104. When composition of the message is completed, the user uploads the completed message to a mail server 102. The mail server 102 in one embodiment is owned by an Internet Service Provider (ISP) or by a private corporation for whom the user works. The user client machine 104 connects to the mail server 102 via dial-up, digital subscriber loop (DSL), cable Internet, or by other appropriate means. One standard for e-mail formats is described by RFC 822 obsoleted by RFC2822, which are a standard and a proposed standard, respectively, promulgated by Internet Engineering Task Force (“IETF”). The protocol by which e-mail messages are transmitted from sending mail server 102 to receiving mail server 102 are described by RFC821, obsoleted by RFC 2821, which are also a standard and a proposed standard, respectively, of the IETF. These standards can be found at www.ietf.org. The present disclosure hereby incorporates by reference the subject matter of the RFC 821 and RFC 822 standards and the RFC 2821 and RFC2822 proposed standards. If the proposed standards are updated from the versions published in April 2001, it is the subject matter of the April 2001 versions of these proposed standards that is hereby incorporated by reference. The RFC 821 and RFC 2821 documents describe a Simple Mail Transport Protocol (“SMTP”), which is the protocol by which e-mail messages have typically been transported over the Internet.

#SMTP servers and SMTP clients (SMTP clients are network computers, not to be confused with the client machines 104) provide a mail transport service, and therefore act as Mail Transfer Agents (“MTAs”). Mail User Agents (“MUAs” or “UAs”) are normally thought of as the sources and targets of mail. At the source, an MUA might be the source mail server 102a, 102b that collects mail to be transmitted from a user and hands it off to an MTA within the network 101. The final (“delivery”) MTA would be thought of as handing the mail off to an MUA, which might be the destination mail server 102c, 102d that holds a user's mail in the user's inbox.