Abstract: A computerized method for electronic communication includes issuing via a mail client a set of extensions in a command to a MX server for an initial electronic communication; determining in the mail client one or more of the extensions, which failed; and for a subsequent electronic communication between the mail client and the MX server, for a predetermined time period, not issuing to the MX server by the mail client the one or more extensions, which failed.

Abstract: Techniques for compressing a set of input addresses to generate a set of one or more rules for various network applications and tools such as routers, firewalls, and others. A tree is generated based upon a set of input addresses. A set of one or more rules may be generated based upon the generated tree and a tolerance value. The set of one or more rules may identify one or more address segments that include the input addresses and may also include one or more additional addresses. In one embodiment, the set of one or more rules may be one or more Classless Internet Domain Routing (CIDR) expressions. The set of one or more rules may be provided to various network applications and tools for further processing.

Abstract: An e-mail system is described that includes a flow control filter, which is particularly suited for filtering on a per-domain (host) basis. During processing of incoming e-mail, each child MTA process created to handle a particular new connection connects to a flow control filter service, so that it can interact with the service during arrival of a message. This interaction provides a complete description of the incoming client, including IP address and host name, as well as the complete SMTP interaction. Since the flow control filter service monitors all children processes, it attains a global view of traffic flowing through the system. By virtue of its global view, the flow control filter service can track information on a per domain basis, including total volume of e-mail received from a particular domain over a given period of time.

Abstract: An electronic mail system with a methodology providing distributed message storage and processing is described. In particular, this methodology breaks up how the individual components of message data are stored. Message data itself is broken up into two parts: a metadata (mutable) portion, and an immutable portion. The metadata portion represents that part of the message data that may change over time. This includes message status flags (e.g., the IMAP “message deleted” flag) and the message's position within a particular message folder, among other information. The immutable portion, which comprises the bulk of electronic mail data (namely, the message itself), once stored is never edited. Immutable data is written f+1 times on as many unique servers, to tolerate f number of server failures using Lampson's stable storage algorithm. The metadata portion is stored 2f+1 times on as many unique servers to tolerate f number of server failures using quorum voting.

Abstract: An e-mail system is described that includes a mass-mail accelerator (MMA), which is particularly suited for processing mass e-mailings. Instead of being posted to a message transfer agent (MTA), outgoing messages are instead passed to the MMA for carrying out highly parallel e-mail delivery/routing. The MMA employs a plurality of queues, which may either be general or specific. A specific queue is configured to handle only e-mail destined for a particular domain, such as the AOL.com domain; a general queue is configured to handle all other e-mail. Each queue manages a pool of MTA threads. During MMA operation, once a message has been passed to a queue, that queue examines its MTA threads to see if one is ready to accept the message. If an MTA thread is ready, the queue will assign the message to that MTA. The MTA thread proceeds to handle the work of the SMTP exchange between the MMA and the target real-world MTA (e.g., an AOL MTA).

Abstract: An electronic mail (“e-mail”) system is described that enforces authentication or encryption to/from Mail Transfer Agents and from Mail User Agents. In one embodiment, for example, an electronic mail (e-mail) system is described that comprises: a message transfer agent (MTA) available for a client to connect to; program logic for authenticating the client, through use of a certificate, in order to identify the client as approved for establishing a secured connection with the MTA; program logic for establishing a secured connection between the client and the MTA in instances where the client can be authenticated; program logic for testing encryption strength of the secured connection; and program logic for terminating the secured connection in instances where the secured connection has inadequate encryption strength.

Abstract: An electronic mail (“e-mail”) system is described that provides a methodology that allows the system to determine when it is appropriate to relay e-mail messages, particularly from “roaming” users. In basic operation, the methodology of the present invention first checks whether the client has been authenticated. If not, the decision of whether relaying is allowed may be subject to other rules in the system, such as whether the user currently resides behind the company's firewall. Of interest herein is a case where the client has been authenticated. In that case, the system can allow relaying for everyone who has a certificate (“cert”) signed by certain certificate authorities (“CAs”). Additionally, the system can require specific cert subjects.

Abstract: An electronic mail (“e-mail”) system providing improved methodology for processing messages sent to mailing lists is described. The system include an “Injector” component which serves to “inject” messages into one or more Message Transfer Agents (MTAs). The system's Mailing List Manager (MLM), acting through the Injector, posts the address to a first MTA. If that MTA successfully processes the address, it responds with a “success” result, which may be passed back through the Injector to the MLM. If, on the other hand, that MTA is not successful, then the address is passed off to a second MTA. Again, if that MTA is successful, it will indicate that success back to the MLM; otherwise, the address is then passed off to the next MTA. The foregoing sequence continues until either the address for the given recipient is successfully processed by one of the MTAs or all of the available MTAs have been exhausted.