Systems and methods for preventing spam and denial of service attacks in messaging, packet multimedia, and other networks

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims the benefit of U.S. Provisional Patent application 60/529,532 filed on Dec. 15, 2003, 60/579,575 filed on Jun. 14, 2004, and 60/605,993 filed on Aug. 31, 2004, the disclosures of which are incorporated herein by reference.

TECHNICAL FIELD OF THE INVENTION

0002This invention pertains in general to electronic communication in messaging networks, such as email and similar media, in packet multimedia networks, such as those using Voice over Internet Protocol (VoIP) technologies, and in other networks, such as those providing web-based transaction services. The invention pertains in particular to providing authentication of message originators (senders) and media session originators (callers), such that unsolicited communications originated by commercial and/or disreputable entities, commonly referred to as spam, may be rejected prior to acceptance or redirected to an alternate network. The invention further pertains in particular to creating a network in which servers receive traffic only from other servers that are trusted and authorized. Offered traffic from unauthorized, untrusted computers does not even reach the destination server, thereby preventing unwanted signalling such as spam and Denial of Service attacks. The invention further pertains in particular to a mechanism whereby legitimate businesses may correspond via electronic mail with interested customers, and send direct mail electronically to interested recipients.

BACKGROUND OF THE INVENTION

0003Spam is generally defined as any communication that is both unsolicited and unwanted. It has become a costly, annoying, often offensive, and occasionally destructive common hazard in most users' experience with electronic messaging (email). Similarly, most people with a telephone have experienced unwanted and unsolicited calls from telemarketers, and most people with a residential address receive junk mail, both of which may properly be considered a kind of spam as well. Spam is often sent in large quantities to random recipients by less-than-reputable organizations or individuals, but even ordinary products advertised with low-volume and inoffensive communications can be unsolicited and unwanted, and therefore be classified as spam.

0004Messaging spam currently consumes network capacity in an amount roughly equal to the intended traffic. Over the next half decade this unwanted consumption is expected to grow to roughly three times the intended traffic. Voice spam (telemarketing) pays its own way in the “Plain Old Telephone Service” (POTS) network, but as VoIP and related technologies continue their steady growth to prominence, the economics of the situation will change. Voice spam, and eventually multimedia spam, will grow to traffic proportions that reach and perhaps surpass those of messaging spam.

0005Many systems exist which attempt to prevent the flow of messaging spam. The most common technique involves lexically scanning each message passing through a server or arriving in a user's mailbox, and discarding or setting aside those messages which match certain patterns. One widely-used such system is the Brightmail message filtering service. Others include filtering capabilities built into popular message handling software such as sendmail, Microsoft Exchange, and Microsoft Outlook. Usually, the email address of the sender is forged in order to evade these filters, and spammers tend to change their message content frequently as well, again in an attempt to evade filters. Thus even the best filters, including the highly-regarded Bayesian analysis technique found in Spam Assassin and similar programs, can never be 100% effective.

0006Further, while lexical scanners and other filters can, to some degree, prevent users from receiving spam, they cannot prevent the messages from being sent in the first place. They are inherently reactive, catching new forms as they are discovered. An extreme example of this technique can be found in Vipul's Razor, commercialized by Cloudmark as SpamNet, which provides a user-driven spam-reporting system that in turn provides distribution of filter rules. Because of this reactive nature, the network traffic associated with spam is not avoided. Several techniques exist which attempt to prevent those who create spam from being able to send any messages at all. However, these tend to depend on vigilance by large numbers of network administrators, and can easily be circumvented by intentional non-conformers. As well, the practice of forging headers mentioned above contributes further to the difficulty in this problem. Because there is no shortage of such non-conformant service providers, the cost of spam to its senders is so low that they can generate enormous volumes of it and still recover the cost with only a few responses. Thus the cost of messaging spam is actually borne more by those users who don't want it than by the spammers and their customers. The non-electronic counterpart of messaging spam, junk mail, generally doesn't overwhelm its recipients precisely because it costs its senders real money. Only by raising the cost or reducing the response rate can the messaging spammer's business model be rendered unworkable.

0007Proposals have been made that attempt to shift the cost of electronic messaging to senders by having them perform costly tasks for each message. In one approach, cited in the April, 2003, issue of <i>Technology Review</i>, unknown senders are forced by the recipient to spend roughly 10 seconds computing the response to a challenge, thereby proving their legitimate desire to have the message accepted. In another, cited Mar. 20, 2003 by <i>InternetWeek</i>, messages from unknown senders are rejected unless they carry a code purchased from a charitable organization. These proposals do appear to shift costs to senders in a way that would destroy the spammer's business case. However, they also rely upon significant infrastructure changes within the messaging network in order to operate, and require senders to take steps that benefit recipients with no corresponding advantage to themselves.

0008An emerging class of messaging spam prevention techniques involves detecting legitimate senders and giving them free tokens, which they include in each message so that the message will be recognized by the recipients' email infrastructure as valid. Several different token-based systems are in use, featuring various kinds of tokens. Among these are challenge-response systems, which detect real users by imposing a reverse-Turing test upon senders, and thenceforth use the sender's email address as a token for safe passage (for example, Mailblocks); secret-word systems, wherein recipients provide senders with a character string, known only amongst themselves and the recipients' mail server, to be included in the message Subject (for example, MailKey); and copyrighted-token systems, in which legitimate users are licensed to attach a copyrighted character string, such as a poem, to their messages for safe passage (Habeas). Each of these is essentially a non-cryptographic means of user authentication, and in such systems forgery is both trivial to accomplish and hard to detect.

0009A few techniques exist which take advantage of cryptographic authentication. Many lexical filters allow messages that are signed using common protocols (S/MIME, PGP) to pass unhindered. However, no mail server attempts to verify the signature because the encryption involved uses keys that are available only to the end users participating in the message. Though invalid messages can be ignored by recipients using this technique, forged signatures can be used for server passage, so traffic reduction is not achieved. Similarly, the ArmorPost Email Privacy system, previously disclosed by the present inventors in U.S. patent application Ser. No. 10/701,355 entitled “System and method for private messaging” and filed Nov. 4, 2003, permits end users to ignore messages that are not signed and encrypted. In that system, a server verifies cryptographic signatures and discards invalid messages, so forgeries are prevented. However, most email users do not regard encryption as a significant need, so the likelihood that most recipients can depend upon most legitimate senders to use this system is low. The Yahoo DomainKeys proposal also uses server-generated and server-verified cryptographic signatures for message source authentication. However, that system relies upon self-published, and therefore potentially self-signed, encryption certificates stored in openly accessible Domain Name System (DNS) servers. Such an approach raises important trustworthiness and scalability questions.

0010Efforts are ongoing in the networking standards community to create mechanisms whereby certain network topology constraints may be imposed on mail servers. The AntiSpam Research Group (ASRG) of the Internet Engineering Task Force (IETF) in particular are standardizing a requirement that mail servers which are authorized to send mail from a domain be identified in the name server for that domain. Proposals to this process include Microsoft's “Caller ID for Email” and the “Sender Policy Framework” (SPF). These “Reverse Mail Exchanger” techniques have the potential to be effective in preventing forgery of senders' addresses, and in identifying renegade networks. However, they have the side effect of making somewhat difficult, and thereby potentially preventing entirely, behaviors upon which certain legitimate users depend. Further, for any portion of the network to benefit from these techniques, it is necessary for substantially all of the network to participate. Such an extreme dependence on universal deployment can lead to significant delays in activation of the benefits.

0011Similar issues arise for multimedia spam as arise for messaging spam. In the POTS network, traditional telemarketing is regulated, somewhat successfully, through the so-called “Do Not Call List” approach. In VoIP technologies, which support not just voice calls but generalize to sessions supporting any combination of streaming media, this approach will be mostly ineffective due to the different economics associated with traditional telephony compared with those of VoIP.

0012Specifically, circuit-oriented technologies and traditional tariffing practices create call pricing that makes international telemarketing generally expensive; domestic telemarketing is not inexpensive, either. Organizations that engage in traditional telemarketing are generally well funded and reasonably reputable; the high cost of calling keeps out the riff-raff, as it were, just as the price of mailing affects the quality and volume of junk mail people receive. However, in a VoIP network a caller experiences roughly the same very low cost regardless of location and calling volume, just as in the case of electronic messaging. Many countries do not or cannot charge their traditional international tariffs on VoIP calls, so there is a significant cost advantage to using VoIP technology. Since domestic regulations generally do not extend internationally, and calling costs are mostly the same for VoIP-based telemarketing regardless of origin, unwanted calls will rise in frequency to and beyond the levels which prompted “Do Not Call” regulations. Worse, the ease of originating VoIP-based calls using ordinary computers may lead to many of the same sorts of annoyances and hazards in this medium as are seen in electronic messaging.

0013With these similarities, it might seem that many of the same approaches created over the years for preventing messaging spam could apply to preventing voice and multimedia spam. However, while the signalling architectures of messaging and VoIP are fundamentally the same, their content architectures are quite different. Content filtering techniques that are used to analyze text-based messages generally are not applicable to VoIP-based audio or video streams. Real-time streaming media content analysis technologies may or may not mature sufficiently for widespread use. However, as has been seen in the messaging anti-spam arena, content filtering does not solve the problem anyway. Clearly, just as is required to stop messaging spam, stopping VoIP spam requires authentication of the call setup signalling and its sender. With this in place, unwanted calls can be screened on the basis of sender identity, and call-handling servers can constrain their users to reasonable numbers of calls in any given period of time.

0014What is needed, then, is a system for authenticating message senders and media session originators that is not susceptible to forgeries, is not required to impose the indignity of a reverse-Turing test (although it could impose one for additional assurance), is sufficiently simple that practically all senders, callers, and service providers will endure no significant burden using it, and is sufficiently simple that any recipient mail or call server can participate, thereby rejecting spam prior to its entry into the recipient network. Such a system would further be able to track and control the number of messages sent, calls placed, and recipients named by participating senders and callers. Multiple levels of service can be offered for heavy and light users, but the system would simply not offer a service level that permits a user to send the number of messages required by successful spammers, or to place more outgoing calls than a human can reasonably make. Recipients can thus be assured that any communication arriving through such a system is legitimate; recipient mail and call servers can successfully reject any other communications, thereby avoiding the unwanted traffic and the cost of its corresponding network capacity. Such a system would further be able to provide its benefits immediately to any user of a network which deploys it, without being required to wait for universal deployment in other networks before benefiting from local deployment.

0015It is thus a principal aim of the present invention to create an antispam solution that is both simpler for originators and more reliable for recipients than existing options, and which permits receiving service providers to protect their networks from unwanted traffic, immediately upon deployment in their networks.

0016Network Denial of Service (DoS) attacks, whether from a single source or, more commonly, from multiple sources in what is called a Distributed Denial of Service (DDoS) attack, have the potential to disable a server and prevent its legitimate users from receiving the expected service. One way to characterize attack strategies is to recognize whether the attacker is attempting to access the victim server's application layer and overwhelm its processing capacity or memory resources, or merely overwhelm its packet layer with junk and consume all of its network bandwidth.

0017In general, both classes of attack are difficult to defend. A DDoS of sufficient scope can consume a server's network access bandwidth entirely without the server itself being able to do anything, simply due to the architecture of networks: the bandwidth consumption occurs on a resource that is physically encountered by the packets before the target server is involved. Similarly, if the server is listening to the network at the application layer (usually a TCP or UDP port number) in order to provide the corresponding service, attack packets aimed at that application layer (port) must be handled at least partly in order to determine if they are valid and eligible for service.

0018Typical defenses, well known to those skilled in the art, include firewalls, which can stop packets addressed to a service the server does not provide; intrusion detection/prevention systems, which monitor traffic for abnormal patterns and redirect or halt extraordinary loads; application-layer gateways, which attempt to perform some portion of the service processing (often the request validation and authorization portions) in advance of the actual server; and over-provisioning, in which the service provider allocates excess server and/or network access capacity so that an attacker's job is that much harder. Overprovisioning is simple, but usually not inexpensive, and merely moves the problem to a higher resource plateau; the defender ends up paying more for larger attacks and not gaining any value from the extra resource that isn't needed for the service. Application-layer gateways are in a practical sense just as vulnerable to the DDoS attack as the servers they are protecting. The exact vulnerabilities may be different, due to diverse implementations and distribution of the service state machine. However, fundamentally this is simply another form of overprovisioning so the costs must be considered carefully. The first two defenses, on the other hand, do attempt to conserve resources. They endow routers, which would exist in the network anyway, with additional functionality that attempts to screen out packets that would be invalid at, or simply overwhelm, the server. In both cases, however, determining application-layer validity of a particular packet or stream of packets can generally only be performed with 100% accuracy by the application layer itself, due to state and algorithm/semantic dependencies. Therefore, routers with firewall or IPS capability typically screen only for syntactic correctness. While this is a significant improvement over an unprotected server, blocking many packet-layer attacks, an effective application-layer attack may still be constructed using “correct” packets. As with spam filters, ever finer definitions of “correct” do not prevent unwanted packets; they merely change the specifics of the attacker's requirements, thus precipitating an escalating interchange of capabilities development (also called an “arms race”).

0019These defenses also struggle to distinguish random traffic, which may or may not be valid, from traffic that can be predicted because it is explicitly authorized. Most services are designed to handle random traffic, such as incoming email from arbitrary sources or web requests from arbitrary unknown clients. Therefore, firewall and IPS designs tend to be tuned to such behavior as well. However, in general a service will actually experience both random traffic and routine traffic, such as correspondence with known associates or web-based process signalling among known business partners. Attempts to distinguish these categories of traffic run into the problem of identity spoofing by attackers, which cannot be prevented without a strong authentication technique such as one based upon Public Key Cryptography. A common solution is to establish explicitly authorized encrypted tunnels (sometimes called Virtual Private Networks, or VPNs) among the correspondents. This technique can be quite effective, but it suffers high complexity due to the need for exchange of encryption keys among the participants. While public-key implementations such as Transport Layer Security (TLS) handle part of this problem automatically, the critical first step—trading trusted public key certificates—still depends in many applications on interpersonal exchange or bilateral agreement. To accomplish this step with more than a few correspondents is challenging; to establish arbitrary new relationships quickly is beyond the capabilities of prior art systems. Further, since a server handling both random and routine traffic is by definition exposed to the random traffic, attack traffic may overwhelm server resources and still block VPN traffic despite its known, expected, and authorized nature.

0020What is needed, then, is a system whereby different types of traffic may be handled with different defense mechanisms, as well as a defense mechanism specifically designed to detect and promptly handle predicted, authorized traffic while applying traditional techniques to the arbitrary remaining traffic. Such a system would be very simple to configure and manage, and would not require bilateral agreements among pairs of correspondents.

0021It is thus another principal aim of the present invention to create a DoS defense that reliably separates predicted traffic from random traffic, ensures that attacks structured as valid random traffic cannot impinge upon the predicted traffic, and does so without incurring the so-called “n-squared” complexity of multiple bilateral relationships among predicted correspondents.

0022Because of the prevalence of spam in email, it is for all practical purposes impossible for legitimate businesses to use email as a medium for legitimate advertising. Several companies have attempted to create legitimate direct email marketing businesses, but economies of scale require that for such a business to be viable it must subscribe a significant portion of network users as participants, yet before such an event it must subscribe a significant portion of potential advertisers. Further, societal forces require that such a business earn the trust of the community before users will subscribe and agree to receive marketing messages (also known as “opt-in”). Many existing systems based on opt-in are generally untrusted in the user community because their operators share the permission with one another in an unconstrained fashion. A user who opts in for advertising messages from a human-services charity may begin to receive messages from an animal-rights organization, for example. These secondary messages are considered spam, the credibility of the primary organization is damaged, and the user no longer opts in anywhere.

0023It is the sharing of email addresses among these advertisers that creates the problem. Similarly, the “Do-not-Spam Registry” authorized by the so-called CAN-SPAM Act recently enacted in the United States is expected to create more spam than it prevents precisely because it shares a large list of valid email addresses with those who would advertise. While they are required not to send advertising messages to those listed, it is likely that unscrupulous organizations will violate this restriction routinely. Further, many advertising organizations, including both spammers and legitimate businesses, exist outside the jurisdiction of U.S. law. They may be able to access the “Registry” CAN-SPAM authorizes without being subject to its usage limitations.

0024Most current mass-targeted advertising in the Internet medium takes place via search engines, such as the widely-used Google. These services provide a mechanism for users to specify what information they seek, and respond with a list of likely sources for that information. Most search engines provide results that include both non-commercial sources and advertisements.

0025Because of the difficulties identified above with direct email marketing, such advertising is inherently poorly targetted. Advertisers must attract users to their information, and entice them to provide an address for future direct mail. No mechanism exists for advertisers to offer future information to users, who may or may not search again, and who may or may not provide an address. Users who prefer not to provide an address cannot be reached with existing systems.

0026What is needed, then, is a system whereby legitimate businesses and other organizations may advertise through a reputable and trusted intermediary, users may selectively permit direct email marketing on topics or advertisers of interest, and users' addresses are never shared directly with the advertisers. In such a system, the trusted intermediary would provide a communication path between the advertiser and the users who have opted in, whereby only the intermediary knows the addresses of the users. Thus, advertisers would be unable to share addresses and convert a legitimate opt-in into spam. The intermediary would have sufficient pre-existing scale and trust to attract both advertisers and users in large numbers, thereby overcoming the business deficiencies of existing direct email marketing companies.

0027It is thus another principal aim of the present invention to provide a system that enables direct email marketing, by legitimate advertisers and targetted at verified recipients, through a trusted intermediary that does not share users' email addresses with advertisers. That is, having eliminated spam, it is desirable to enable legitimate email marketing.

SUMMARY OF THE INVENTION

0028Accordingly, the present invention provides a simple, universal means of creating and distributing cryptographic tokens for authenticating messages, senders, call signalling, and callers. The present invention further provides that user addresses are confirmed to be valid, cryptographic tokens are created and distributed for each user address automatically, and a cryptographic token associated with a user address is thereby assured to correspond correctly with that address. The present invention also provides that the address of a message's sender or session's originator is confirmed to be valid, a cryptographic token that binds the message/call request and its validated sender/caller is created automatically and attached to the message/signalling, and the recipients are thereby assured of the sender's/caller's address. In addition, the present invention provides that message and call setup traffic from each user address can be limited to typical or enhanced levels by subscription. Taken together, these features provide the significant additional advantage that spam traffic can be rejected at recipient mail and call servers, thereby avoiding the cost associated with moving such traffic within the network.

0029The present invention additionally provides a gateway which distinguishes predicted, authorized network traffic from traditional arbitrary network traffic. Further, in the present invention the discriminated traffic is routed to its destination in a manner that prevents each class from interfering with the other at the application layer, such that the receiving gateway can handle the authorized traffic at a higher priority than the arbitrary traffic. The present invention also provides that the application layer ports used for authorized traffic are randomized in a manner that prevents discovery of the correct port by any sender other than an authorized sender, thus making it practically impossible for an application layer denial of service attack to find the application and disrupt the authorized traffic.

0030The present invention additionally provides a scalable, trustable means of electronic advertising. Further, the present invention provides that advertising may be delivered specifically to self-identified interested parties via direct electronic mail, without identifying to the advertiser the interest parties' addresses.

0031The above and other advantages of the present invention are carried out in one form by a system of cooperating elements, each of which applies cryptographic and other procedural means as specified below to ensure the authenticity of a message or call request as it is conveyed from its sender to its recipients.

BRIEF DESCRIPTION OF THE DRAWINGS

0032The invention will be better understood from a reading of the following detailed description in conjunction with the drawing figures, in which like reference designators are used to identify like elements and in which:

0033<figref idref="DRAWINGS">FIG. 1</figref> illustrates a high-level block diagram of the overall system in which the messaging spam prevention capability of the present invention operates;

0034<figref idref="DRAWINGS">FIG. 2</figref> illustrates a block diagram of a software program and corresponding computer system which can operate as a Messaging AntiSpam Gateway in the system of the present invention;

0035<figref idref="DRAWINGS">FIG. 3</figref> illustrates a block diagram of a software program and corresponding computer system which can operate as a Registry in the system of the present invention;

0036<figref idref="DRAWINGS">FIG. 4</figref> illustrates a block diagram of the authentication Token data structure in accordance with the present invention;

0037<figref idref="DRAWINGS">FIG. 5</figref> illustrates a flow chart for the Token Creation process in accordance with the present invention;

0038<figref idref="DRAWINGS">FIG. 6</figref> illustrates a flow chart for the Token Verification process in accordance with the present invention;

0039<figref idref="DRAWINGS">FIG. 7</figref> illustrates a combination signalling sequence chart and flow chart for the Message Transfer and Token Handling process in accordance with an embodiment of the present invention in which both sender and recipient are served by Messaging AntiSpam Gateways;

0040<figref idref="DRAWINGS">FIG. 8</figref> illustrates a combination signalling sequence chart and flow chart for the Message Transfer and Token Handling process in accordance with an embodiment of the present invention in which the sender is registered at a Registry and is not served by a Messaging AntiSpam Gateway, and the recipient is served by a Messaging AntiSpam Gateway;

0041<figref idref="DRAWINGS">FIG. 9</figref> illustrates a combination signalling sequence chart and flow chart for the Message Transfer and Token Handling process in accordance with an embodiment of the present invention in which the sender is not registered at a Registry and is not served by a Messaging AntiSpam Gateway, and the recipient is served by a Messaging AntiSpam Gateway;

0042<figref idref="DRAWINGS">FIG. 10</figref> illustrates a combination signalling sequence chart and flow chart for the Message Transfer and Token Handling process in accordance with an embodiment of the present invention in which the sender is served by a Messaging AntiSpam Gateway, and the recipient is registered at a Registry and is not served by a Messaging AntiSpam Gateway but instead uses an ArmorPost Agent Client;

0043<figref idref="DRAWINGS">FIG. 11</figref> illustrates a combination signalling sequence chart and flow chart for the Message Transfer and Token Handling process in accordance with an embodiment of the present invention in which both sender and recipient are registered at Registries, and neither is served by a Messaging AntiSpam Gateway, and each uses an ArmorPost Agent Client;

0044<figref idref="DRAWINGS">FIG. 12</figref> illustrates a combination signalling sequence chart and flow chart for the Message Transfer and Token Handling process in accordance with an embodiment of the present invention in which the sender is not registered at a Registry and is not served by a Messaging AntiSpam Gateway, and the recipient is registered at a Registry and not served by a Messaging AntiSpam Gateway but instead uses an ArmorPost Agent Client;

0045<figref idref="DRAWINGS">FIG. 13</figref> illustrates a high-level block diagram of the overall system in which the dynamic business directory capability of the present invention operates;

0046<figref idref="DRAWINGS">FIG. 14</figref> illustrates a block diagram of a software program and corresponding computer system which can operate as a Dynamic Directory Engine in the system of the present invention;

0047<figref idref="DRAWINGS">FIG. 15</figref> illustrates a block diagram of a software program and corresponding computer system which can operate as a Dynamic Directory Clearinghouse in the system of the present invention;

0048<figref idref="DRAWINGS">FIG. 16</figref> illustrates a combination signalling sequence chart and flow chart for an interactive mediated communication between a user and an advertiser in accordance with an embodiment of the present invention;

0049<figref idref="DRAWINGS">FIG. 17</figref> illustrates a combination signalling sequence chart and flow chart for a mediated bulletin from an advertiser to a user in accordance with an embodiment of the present invention;

0050<figref idref="DRAWINGS">FIG. 18</figref> illustrates a combination signalling sequence chart and flow chart for the Dynamic Directory transaction clearing process in accordance with an embodiment of the present invention;

0051<figref idref="DRAWINGS">FIG. 19</figref> illustrates a high-level block diagram of the overall system in which the multimedia spam prevention capability of the present invention operates;

0052<figref idref="DRAWINGS">FIG. 20</figref> illustrates a block diagram of a software program and corresponding computer system which can operate as a Multimedia AntiSpam Gateway in the system of the present invention;

0053<figref idref="DRAWINGS">FIG. 21</figref> illustrates a combination signalling sequence chart and flow chart for the Session Setup and Token Handling process in accordance with an embodiment of the present invention in which both caller and recipient are served by Multimedia AntiSpam Gateways;

0054<figref idref="DRAWINGS">FIG. 22</figref> illustrates a block diagram exemplifying the authorization topology of the present invention;

0055<figref idref="DRAWINGS">FIG. 23</figref> illustrates a combination signalling sequence chart and flow chart for an exemplary detailed Introduction process;

0056<figref idref="DRAWINGS">FIG. 24</figref> illustrates a block diagram of a software program and corresponding computer system which can operate as a Network Authority in the system of the present invention;

0057<figref idref="DRAWINGS">FIG. 25</figref> illustrates a high-level block diagram of the overall system in which the DoS prevention capability of the present invention operates;

0058<figref idref="DRAWINGS">FIG. 26</figref> illustrates a block diagram of a software program and corresponding computer system which can operate as a Secure Application Gateway in the system of the present invention;

0059<figref idref="DRAWINGS">FIG. 27</figref> illustrates a flow chart for the Port Randomization process in accordance with the present invention;

0060<figref idref="DRAWINGS">FIG. 28</figref> illustrates a combination signalling sequence chart and flow chart for the Transaction Data Exchange process in accordance with an embodiment of the present invention in which both originating and destination servers are protected by Secure Application Gateways; and

0061<figref idref="DRAWINGS">FIG. 29</figref> illustrates a combination signalling sequence chart and flow chart for the Transaction Data Exchange process in accordance with an embodiment of the present invention in which only the originating server is protected by a Secure Application Gateway.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

0062In <figref idref="DRAWINGS">FIG. 1</figref>, Messaging Spam Prevention System <b>100</b> represents the system of the present invention. It is in some respects an extension of the Private Messaging System disclosed by the present inventors in Utility patent application Ser. No. 10/701,355, and sharing many of its elements. That application is incorporated herein by reference and referred to hereinafter as ArmorPost. Several major elements make up this system. First, End-to-End Messaging Infrastructure <b>101</b> represents the messaging backbone to which the Spam Prevention capability is added. This Infrastructure can be any messaging system that allows users or automatic programs to exchange messages with one another. It is preferably the Internet-standard email service, but may also be implemented as an instant messaging service, a wireless short message service (SMS), any other messaging service, or any combination of these. Second, Packet Network <b>102</b> forms the foundation for all communication among elements, including End-to-End Messaging Infrastructure <b>101</b> and the messages exchanged thereon, but also supporting other non-messaging interactions such as web browsing. This element is preferably an Internet-based network, and may be the Internet itself, another network like it, or a composite of networks using multiple interworking technologies.

0063Connected to End-to-End Messaging Infrastructure <b>101</b> and Packet Network <b>102</b> is at least one User Registry <b>120</b> (also referred to as simply Registry <b>120</b>). This element allows users to register for service. It is similar in many respects to the Trusted Courier <b>120</b> described in ArmorPost Its components, Information Security component <b>121</b>, Account Management component <b>122</b>, Interface <b>123</b> to End-to-End Messaging Infrastructure <b>101</b>, and Interface <b>124</b> to Packet Network <b>102</b>, are all as described in ArmorPost. Additional functionality, which will become clear in the description of <figref idref="DRAWINGS">FIG. 3</figref>, is provided so that the various types of Client, described below, can acquire message authentication Tokens, and so that AntiSpam Gateways and certain Clients, also described below, can verify them.

0064Also connected to End-to-End Messaging Infrastructure <b>101</b> and Packet Network <b>102</b> are one or more Clients with various capabilities. Each Client is a set of computer software applications which enable acquisition of authentication Tokens and their placement in outgoing messages on behalf of an end user, in support of the Messaging Spam Prevention System.

0065ArmorPost Agent Clients <b>110</b> are instances of the ArmorPost Agent from the aforementioned ArmorPost System, and comprise Information Security component <b>111</b>, Messaging Client <b>112</b>, Interface <b>113</b> to End-to-End Messaging Infrastructure <b>101</b>, and Interface <b>114</b> to Packet Network <b>102</b>, all as described there. For the purposes of the Messaging Spam Prevention System, the functionality of this Agent is extended to include automatic generation of an authentication Token, and inclusion of the current Token in outgoing messages. Recalling that the ArmorPost Agent can be implemented with either a tight coupling or a loose coupling between Information Security component <b>111</b> and Messaging Client <b>112</b>, inclusion of the current Token in an outgoing message can either occur automatically or manually. The ArmorPost Agent is also extended to include verification of authentication Tokens found in incoming messages.

0066Standard Client <b>130</b> is nothing more than an unmodified Web Browser <b>131</b>, paired with an unmodified Messaging Client <b>132</b>. It communicates with other elements via End-to-End Messaging Infrastructure <b>101</b> on Interface <b>133</b> using standard messaging protocols; Interface <b>133</b> is identical to Interface <b>113</b>. It also communicates with other elements via Packet Network <b>102</b> on Interface <b>134</b> using standard packet protocols; Interface <b>134</b> is substantially identical to Interface <b>1114</b>. With Web Browser <b>131</b>, a user can authenticate to Registry <b>120</b> via its website by providing the account password established during Registration (see ArmorPost), then request and download a current authentication Token as needed. After thus acquiring a Token, the user can then attach or otherwise include it in an outgoing message using Messaging Client <b>132</b>. These actions are performed with standard functions of the respective components. This configuration supports the users who are unable to install a complete ArmorPost Agent Client <b>110</b>. Such inability may stem from a lack of permissions granted to the user by system administrators, or from lack of a suitable ArmorPost Agent implementation for the user's computer system.

0067Proxy Client <b>140</b> supports users who can neither install an ArmorPost Agent nor send and receive messages at all on a particular computer system. The standard Web Browser <b>141</b> which is the sole element of Proxy Client <b>140</b> allows the user to access Registry <b>120</b> via its website by providing the account password established during Registration. Once so authenticated, the website provides the user with functions for composing and sending messages with an authentication Token attached. Proxy Client <b>140</b> also communicates with Registry <b>120</b> via Packet Network <b>102</b> on Interface <b>144</b> using standard packet protocols; Interface <b>144</b> is substantially identical to Interface <b>114</b>.

0068At least one AntiSpam Gateway <b>150</b> sits between End-to-End Messaging Infrastructure <b>101</b> and one or more Protected Messaging Infrastructures <b>103</b>. Using Interface <b>153</b>, an AntiSpam Gateway <b>150</b> receives messages directed to users of a Protected Messaging Infrastructure <b>103</b> from End-to-End Messaging Infrastructure <b>101</b>, then decides whether the message should be relayed into Protected Messaging Infrastructure <b>103</b> via Interface <b>155</b>. Using Interface <b>155</b>, an AntiSpam Gateway <b>150</b> also receives messages sent by users of a Protected Messaging Infrastructure <b>103</b> to other users of End-to-End Messaging Infrastructure <b>101</b>. Note that Interfaces <b>153</b> and <b>155</b> are functionally equivalent both to one another and to Interface <b>123</b>, using the same standard message transfer protocols. For incoming messages, Information Security component <b>151</b> of AntiSpam Gateway <b>150</b> makes its decision by verifying any authentication Token in the message, using a procedure which is described in the context of <figref idref="DRAWINGS">FIG. 6</figref> below. That procedure uses communication between AntiSpam Gateway <b>150</b> and one or more Registries <b>120</b>; Interface <b>154</b> to Packet Network <b>102</b> provides the corresponding connectivity. Note that Interface <b>154</b> is functionally equivalent to Interface <b>124</b>. For outgoing messages, Information Security component <b>151</b> of AntiSpam Gateway <b>150</b> authenticates the senders of those messages, then adds an authentication Token to each message. In both directions, if the authentication decision is affirmative, Messaging Relay component <b>152</b> of AntiSpam Gateway <b>150</b> effects the relaying of the message. In a preferred embodiment, an implementation of Information Security component <b>151</b> is derived from an implementation of Information Security component <b>121</b> of the ArmorPost Trusted Courier <b>120</b>, and Messaging Relay component <b>152</b> is any of several commonly available message-transfer-agent (MTA) application programs, such as the popular sendmail.

0069AntiSpam Gateways <b>150</b> and User Registries <b>120</b> are related to one another in the sense that the users of a particular Protected Messaging Infrastructure <b>103</b>, served by one or more particular Messaging AntiSpam Gateways <b>150</b>, are registered in and provided account management services by a particular User Registry <b>120</b>. More detail on this relationship is provided in the descriptions of <figref idref="DRAWINGS">FIG. 2</figref> and <figref idref="DRAWINGS">FIG. 3</figref>.

0070Messaging Spam Prevention System <b>100</b> also includes one or more Network Authorities <b>160</b>, which control distribution of cryptographic key certificates. Each Network Authority <b>160</b> is responsible for certifying Registries <b>120</b> and Gateways <b>150</b> within its scope; more detail on this concept is provided in the description of <figref idref="DRAWINGS">FIG. 22</figref>. A Network Authority <b>160</b> contains an Information Security component <b>161</b> whose primary function is to perform the certifications cited above. Secondary functions include providing authenticated, encrypted communication between itself and entities with which it communicates: Registries <b>120</b>, Gateways <b>150</b>, and other Authorities <b>160</b>. Network Authority <b>160</b> also contains an Introduction Management component <b>162</b>. This component is responsible for distributing the encryption key certificates it controls to authenticated requestors, and obtaining certificates from other Network Authorities on behalf of the Registries and Gateways it serves. To support the communication needs of those two components, Network Authority <b>160</b> also features an Interface <b>164</b> to Packet Network <b>102</b>; this interface is substantially equivalent to Interfaces <b>124</b> and <b>154</b>.

0071Further detail on Messaging AntiSpam Gateway <b>150</b> is found in <figref idref="DRAWINGS">FIG. 2</figref>. In a preferred embodiment, an implementation of Information Security component <b>151</b> is derived from an implementation of Information Security component <b>121</b> of the ArmorPost Trusted Courier <b>120</b>, due to similarities in their performance requirements and the fact that both handle the cryptographic algorithms associated with creating and verifying authentication Tokens. However, the differences are significant. First, note that Messaging AntiSpam Gateway <b>150</b> contains no Account Management module similar to the one in the Trusted Courier and Registry <b>120</b>. Instead it contains a Database Distribution module <b>254</b>, which holds a subset of user account information from the corresponding User Registry <b>120</b>, along with certain messages that may be queued within the Gateway according to the procedures described later. This is a very important attribute due to the possible placement of multiple AntiSpam Gateways <b>150</b> at the boundaries of a Protected Messaging Infrastructure <b>103</b>, in support of a variety of network topologies. Each such AntiSpam Gateway <b>150</b> is generally responsive to the entire subscriber base of Protected Messaging Infrastructure <b>103</b>, and multiple such AntiSpam Gateways would generally not be able to provide unified account management functionality for users. Therefore, a User Registry <b>120</b> does so, distributing only the information needed by AntiSpam Gateways <b>150</b>, and retrieving from Gateways <b>150</b> the information stored there as requested by a user. Second, AntiSpam Gateway <b>150</b> does not have any modules for handling Background signalling, since those messages move directly between a Registry <b>120</b> and an ArmorPost Agent <b>110</b>, bypassing both Protected Messaging Infrastructure <b>103</b> and AntiSpam Gateway <b>150</b>.

0072Within Information Security component <b>151</b>, Token Handling module <b>250</b> is responsible for detecting authentication Tokens in incoming messages, and placing authentication Tokens in outgoing messages, according to the various conventions for Token inclusion described in the context of <figref idref="DRAWINGS">FIG. 4</figref>. Token Creation module <b>251</b> is responsible for generating Tokens as needed for outgoing messages, according to the procedures described in the context of <figref idref="DRAWINGS">FIG. 4</figref>. If a Token is present in an incoming message, Token Verification module <b>252</b> is responsible for establishing its authenticity according to the procedures described in the context of <figref idref="DRAWINGS">FIG. 6</figref>.

0073If an authentication Token is verified successfully, the message in which it arrived can be relayed to its recipient or recipients in Protected Messaging Infrastructure <b>103</b>. If an authentication Token is created successfully, the message into which it is placed can be relayed to its recipient or recipients in End-to-End Messaging Infrastructure <b>101</b>. Messaging Relay component <b>152</b> is responsible for this activity. In a preferred embodiment the main relaying function may be implemented as any of several commonly available message-transfer-agent (MTA) application programs, such as the popular sendmail. This embodiment is shown in <figref idref="DRAWINGS">FIG. 2</figref> as Standard MTA module <b>253</b>. Messaging Relay component <b>152</b> also includes a Database Distribution module <b>254</b>, which is responsible for managing certain user data in cooperation with a corresponding User Registry <b>120</b>. Data received from Registry <b>120</b> would generally include only that which is useful in identifying users of Protected Messaging Infrastructure <b>103</b>; other data may be distributed as described in subsequent procedures. Data held within Gateway <b>150</b> and sent to Registry <b>120</b> on request would generally include only headers of messages queued according to procedures described later in this specification. Detailed protocols for exchanging this information are omitted here, as they are well known to those skilled in the art and implemented using common standards.

0074In a preferred embodiment, AntiSpam Gateway <b>150</b> is designed to operate as a network element that permanently serves a particular Protected Messaging Infrastructure <b>103</b>. Its components are therefore housed in a specific Programmable Computing Platform <b>201</b>. Platform <b>201</b> is chosen to provide highly reliable operation and flexible scalability. Candidates satisfying such requirements are well-known to those skilled in the art, and are available from major vendors such as SUN, HP, Motorola, Intel, and many others. Platform <b>201</b> also includes a Communication Interface <b>202</b> for connecting to a network. This is typically implemented using two or more standard Ethernet links, which are well known to those skilled in the art. Additionally, Platform <b>201</b> provides an Information Storage medium <b>203</b> for holding data required by components Information Security <b>151</b> and Messaging Relay <b>152</b>, including configuration data such as message routing and Token-verification routing information, and user data distributed to Database Distribution module <b>254</b>. This is typically implemented as a magnetic “hard disk” module. Platform <b>201</b> and its subsystems are preferably implemented using standard components that are commonly available and well known to those skilled in the art.

0075In an alternate embodiment, AntiSpam Gateway <b>150</b> may be implemented adjacent to or integrated with an ArmorPost Agent Client <b>110</b> in an end user's environment, such that Protected Messaging Infrastructure <b>103</b> is not a sizable network but instead a single mailbox.

0076Detail of a User Registry <b>120</b> can be found in <figref idref="DRAWINGS">FIG. 3</figref>. Structurally, it is substantially similar to a Trusted Courier <b>120</b> from ArmorPost, with the addition of two modules specific to the needs of Messaging Spam Prevention System <b>100</b>. Specifically, Account Management component <b>122</b> is extended by Database Distribution module <b>323</b> and, optionally, Webmail Proxy module <b>324</b>. For descriptions of the rest of the components and modules in User Registry <b>120</b>, refer to ArmorPost and its description of Trusted Courier <b>120</b>.

0077Database Distribution module <b>323</b> is responsible for providing relevant excerpts of the User Database <b>322</b> to those AntiSpam Gateways <b>150</b> which serve the same network as Registry <b>120</b>. This module is also responsible for retrieving data stored in those same Gateways <b>150</b>, such as message headers, when requested by a user via External Website module <b>321</b>. Registry <b>120</b>'s Database Distribution module <b>323</b> can be considered the master of counterpart Database Distribution modules <b>254</b> in one or more AntiSpam Gateways <b>150</b>.

0078While the foregoing texts describes a Registry <b>120</b> and multiple corresponding Gateways <b>150</b> as distinct elements, an alternate embodiment may combine one of each into a single computing platform. This embodiment would be suitable for relatively small and localized instances of Protected Messaging Infrastructure <b>103</b>. Its structure is readily evident to those skilled in the art by combining the modules and components shown in <figref idref="DRAWINGS">FIGS. 2 and 3</figref>, and so is not shown separately.

0079User Registry <b>120</b> may optionally include a Webmail Proxy module <b>324</b> to provide support for Proxy Clients <b>140</b>. Users of webmail services, who have completed at least enough of Registration to establish an account, may log in at Registry <b>120</b> via External Website <b>321</b> of Account Management component <b>122</b> and use Webmail Proxy <b>324</b> to send and receive authenticated messages. Webmail Proxy <b>324</b> wraps each user's remote webmail interface, collecting the user's incoming messages, verifying authentication Tokens before presenting them, and generating authentication Tokens on outgoing messages from the user. Webmail Proxy <b>324</b> may also provide proxy access to standard messaging servers by wrapping the SMTP, POP3, and IMAP protocols on the user's behalf.

0080<figref idref="DRAWINGS">FIG. 4</figref> depicts several forms the authentication Token may take. Each form contains an Identifying Section, which provides information needed to verify the Token and to judge its timeliness with respect to the message carrying it. Each form also contains a Signature Section, which contains a cryptographic signature over certain identifying data. This signature ensures the Token contents cannot be tampered without being detected, and upon verification proves that the Token was issued by the identified issuer; depending on the Token form, verification of the signature may also prove that the Token is associated with the message carrying it. The following paragraphs describe each Token form in detail.

0081Gateway Token <b>401</b> is placed in an outgoing message by a Messaging AntiSpam Gateway <b>150</b> or a Registry <b>120</b>'s Webmail Proxy <b>324</b>, and in outgoing VoIP signalling by a Multimedia AntiSpam Gateway <b>1950</b>. Gateway Token <b>401</b> contains an Identifying Section <b>410</b>, which carries an Issuing Gateway Identifier <b>411</b> and a Token Date/Time <b>412</b>. Issuing Gateway Identifier <b>411</b> is preferably the domain name associated with the AntiSpam Gateway <b>150</b>/<b>1950</b> or Registry <b>120</b> that created the Gateway Token <b>401</b>, although it may take any form that is effective in identifying the Token's creator. Token Date/Time <b>412</b> notes the exact time and date at which the particular Gateway Token <b>401</b> was created. Gateway Token <b>401</b> also contains a Signature Section <b>415</b>, which contains a cryptographic digital signature certifying the authenticity of both the message to which the Token is attached and the AntiSpam Gateway <b>150</b>/<b>1950</b> or Registry <b>120</b>/Webmail Proxy <b>324</b> that issued the Gateway Token <b>401</b>. The cryptographic signature occupying Signature Section <b>415</b> may be generated using any of numerous suitable algorithms well-known to those skilled in the art. In a preferred embodiment, the popular RSA algorithm for asymmetric encryption and message authentication may be used, with the relevant key pair belonging to the AntiSpam Gateway <b>150</b>/<b>1950</b> or Registry <b>120</b>/Webmail Proxy <b>324</b> that issues the particular Gateway Token <b>401</b>. The data items used as input when creating the cryptographic signature are shown as components of Signature Section <b>415</b>, and are chosen to bind the Token to both the message and its sender. From: Address <b>416</b> is the messaging or multimedia address used by the sender of the message/signal in which Gateway Token <b>401</b> is placed; its presence indicates that AntiSpam Gateway <b>150</b>/<b>1950</b> or Registry <b>120</b>/Webmail Proxy <b>324</b> has authenticated the message sender/caller and certifies the From: Address <b>416</b> as valid. Token Date/Time <b>417</b> is substantially identical to Token Date/Time <b>412</b> in Unencrypted Section <b>410</b>; its presence links Unencrypted Section <b>410</b> to Signature Section <b>415</b>. Finally, Hashed To: List <b>418</b> represents the primary recipients of the message or signal to which the Token is attached; it links Signature Section <b>415</b> and Gateway Token <b>401</b> itself to the message. A cryptographic (one-way) hash function is applied to the list of To: addresses in the message to create this data element, thereby normalizing the size of the signed input and providing privacy of correspondents in certain Token Verification scenarios (described later). Note that an alternate embodiment, shown as Alternate Gateway Token <b>460</b>, may use the entire message body as input to this hash function, producing Hashed Message field <b>468</b> instead of Hashed To: List <b>418</b>, in order to bind the Token to the message or signal more strongly. This reduces the potential value in capturing and replaying a Token further, although at the expense of additional processing to hash the entire message. A balance may be struck as well, using some lesser portion of the message body in the hash.

0082Agent Token <b>402</b> is generated and placed in an outgoing message by an ArmorPost Agent Client <b>110</b>. This Token form is structurally similar to the previous one, but with two significant differences. First, its Identifying Section <b>420</b> contains Verifying Registry Identifier <b>421</b>. This element names the Registry <b>120</b> at which the sending user is registered. Only this Registry <b>120</b> will be able to verify Agent Token <b>402</b> because while Registries <b>120</b> and AntiSpam Gateways <b>150</b> may learn one another's public keys through the Introduction protocol described later, as noted in ArmorPost the keys used by an Agent <b>110</b> are known only to its Courier <b>120</b>, which translates in the present invention to the keys used by an ArmorPost Agent Client <b>110</b> being known only to its Registry <b>120</b>. As with Issuing Gateway Identifier <b>411</b>, Verifying Registry Identifier <b>421</b> is preferably the domain name associated with the appropriate Registry <b>120</b>, although it may take any form that is effective in identifying the Token's verifier. Second, the cryptographic signature in Signature Section <b>425</b> of Agent Token <b>402</b> is produced using the key pair belonging to ArmorPost Agent Client <b>110</b>, which can only be verified by the Registry <b>120</b> at which the sending user is registered due to the design of key distribution in ArmorPost. The remaining elements of Agent Token <b>402</b> are the same as their counterparts in Gateway Token <b>401</b>. Token Date/Time <b>422</b> is substantially identical in usage and form to Token Date/Time <b>412</b>, while From: Address <b>426</b>, Token Date/Time <b>427</b>, and Hashed To: List <b>428</b> are used as input to create Signature Section <b>425</b> in the same way that From: Address <b>416</b>, Token Date/Time <b>417</b>, and Hashed To: List <b>418</b> are used as input to create Signature Section <b>415</b>. Agent Token <b>402</b> is appropriate for applications in which Agent Client <b>110</b> is a tightly-coupled implementation.

0083User Token <b>403</b> is generated by an ArmorPost Agent Client <b>110</b>, and placed in a file so that the user can attach it to an outgoing message. User Token <b>402</b> is appropriate for applications in which Agent Client <b>110</b> is a loosely-coupled implementation. Its Identifying Section <b>430</b> contains a Verifying Registry Identifier <b>431</b> and Token Date/Time <b>432</b> which are identical to the fields of the same name in Agent Token <b>402</b>. However, though Token Date/Time <b>432</b> represents the creation time of User Token <b>403</b>, this time is independent of any message timestamp. User Token <b>403</b> can have been created recently with respect to a message, but Token Date/Time <b>432</b> is unlikely to match exactly with the timestamp of the message to which it is attached. At best, if an ArmorPost Agent Client <b>110</b> is configured to generate a new one every 5-10 minutes, User Token <b>403</b> will be no older than 5-10 minutes before the message to which it is attached. The Signature Section <b>435</b> of User Token <b>403</b> contains a cryptographic signature generated from the key pair belonging to the ArmorPost Agent Client <b>110</b>, just as in Signature Section <b>425</b> of Agent Token <b>402</b>. However, the data elements used as input in forming the cryptographic signature in Signature Section <b>435</b> are different. The first difference is subtle: Sending User Address <b>436</b> is a valid messaging address associated with the user, but it is not necessarily the same address as appears in any particular message to which User Token <b>403</b> is attached. This occurs because the user may have multiple valid addresses, and when sending a message from any specific one of them may attach a User Token <b>403</b> that is formed from another specific one of them. Since ArmorPost Agent Client <b>110</b> is loosely-coupled in this scenario, it is unable to attach the User Token <b>403</b> automatically or generate User Token <b>403</b> in conjunction with sending a message. Therefore, Sending User Address <b>436</b> may not match the message From: address. For the same reason, Token Date/Time <b>437</b> does not match the message timestamp, though it does match Token Date/Time <b>432</b>. The second difference, which is also driven by not being bound to a message, is the absence of a Hashed To: List in Signature Section <b>435</b>. Thus the User Token <b>403</b> certifies only that the Token itself was created by a valid ArmorPost Agent Client <b>110</b>. It is possible to forge this Token by capturing and replaying it within the timeframe of the generation period, so in a preferred embodiment this window is configured to be as short as possible. New User Tokens <b>403</b> may be generated almost continuously if the user's computer is idle, or less frequently if it is actively in use.

0084Registry Token <b>404</b> is generated by a Registry <b>120</b> on behalf of a user with a Standard Client <b>130</b>—that is, one who cannot utilize an ArmorPost Agent Client <b>110</b> or a Proxy Client <b>140</b>—who is also not protected by an AntiSpam Gateway <b>150</b>. Such a user has no mechanism that generates Tokens autonomously. Therefore, the user may login at the correct Registry <b>120</b> and have it generate a Registry Token <b>404</b>. The user may then download this Token and manually place it in each outgoing message. Structurally, Registry Token <b>404</b> is substantially identical to User Token <b>403</b>, lacking in particular the ties to a specific message that Gateway Token <b>401</b> and Agent Token <b>402</b> offer, and requiring in particular that verification be performed at the Registry <b>120</b>. Again, however, subtle differences appear. First, because it is a time-consuming action to acquire a Registry Token <b>404</b>, a user is likely to do so only occasionally, and reuse the Token in many messages over a substantial span of time. Therefore, Token Date/Time <b>442</b> and the matching Token Date/Time <b>447</b> will generally by separated from the timestamp of a particular message by a long time. An embodiment may balance the need for user action against the risk of exposure to the user by allowing Registry Tokens <b>404</b> to be valid as long as 6-12 months. Another embodiment may allow users to choose the valid lifetime of their Registry Tokens <b>404</b> according to their own judgment of and sensitivity to the action vs. risk balance. Second, the cryptographic signature in Signature Section <b>445</b> of Registry Token <b>404</b> is generated and verified using the key pair assigned by Registry <b>120</b> for communication with a particular user. That is, the Registry Token <b>404</b> is signed by Registry <b>120</b> with a per-user key created during ArmorPost Registration, not by a key generated by an Agent <b>110</b> within the user's own environment. Thus Registry Token <b>404</b> certifies that the Token itself was created by a valid Registry <b>120</b> on behalf of a valid user, but it does not link in any way to the message carrying it or to the user's environment. Further, because its valid lifetime is significantly longer than that of a User Token <b>403</b>, the potential for capture and replay is significantly higher. In a preferred embodiment, all commercially reasonable effort should be made to provide systems that support either Gateway Tokens <b>401</b> or Agent Tokens <b>402</b>, and transition users off systems that only support either User Tokens <b>403</b> or Registry Tokens <b>404</b>.

0085Encrypted Gateway Token <b>405</b> is a variation on Gateway Token <b>401</b>, in which the entire contents of the Token are encrypted but otherwise identical in both structure and usage to those of Gateway Token <b>401</b>. Using asymmetric encryption, such as the public-key technology used throughout this disclosure, only the particular AntiSpam Gateway <b>150</b>/<b>1950</b> receiving the particular Token <b>405</b> (in a message or multimedia signalling unit) would be able to decipher Encrypted Section <b>450</b> and verify Signature Section <b>415</b>. Other encryption techniques may be used as well; for example, a shared secret symmetric encryption approach might permit a single Encrypted Gateway Token <b>405</b> to be received and verified by any number of AntiSpam Gateways <b>150</b>/<b>1950</b>, User Registries <b>120</b>, and ArmorPost Agent Clients <b>110</b>.

0086Finally, Alternate Gateway Token <b>406</b> offers yet another variation on this theme. It provides the option for a sending AntiSpam Gateway <b>150</b>/<b>1950</b> to choose encrypted or clear contents through Optional Encrypted Section <b>460</b>. If encrypted, Identifying Section <b>410</b> will be unrecognizable, so a verifying entity will first attempt to decrypt the Token <b>406</b> before attempting to verify it. This token form also uses a hash of the entire message/signalling unit, Hashed Message <b>468</b>, instead of hashing only the To: list.

0087In <figref idref="DRAWINGS">FIGS. 5 and 6</figref> we find the methods of Token processing which operate in both the Messaging Spam Prevention System <b>100</b> and the Multimedia Spam Prevention System <b>1900</b>. <figref idref="DRAWINGS">FIG. 5</figref> covers the first, that of creating authentication Tokens and placing them in outgoing messages/signalling units on behalf of message senders/callers. <figref idref="DRAWINGS">FIG. 6</figref> covers the second, that of detecting and verifying an authentication Token in a message/signalling unit that arrives at an AntiSpam Gateway <b>150</b>/<b>1950</b> or ArmorPost Agent Client <b>110</b>.

0088The Token Creation process <b>500</b> in <figref idref="DRAWINGS">FIG. 5</figref> begins at step <b>501</b> with a determination whether the sender or caller is served by an AntiSpam Gateway <b>150</b>/<b>1950</b>. If so, each time a user of Protected Messaging Infrastructure <b>103</b> or Protected Multimedia Signalling Infrastructure <b>1903</b> attempts to send a message or place a call, the message/signalling unit passes through AntiSpam Gateway <b>150</b>/<b>1950</b>, which in turn generates a Gateway Token and, as shown in step <b>502</b>, adds it to the message/signalling unit as a header. The generated Gateway Token may take the form of either Gateway Token <b>401</b>, Encrypted Gateway Token <b>405</b>, or Alternate Gateway Token <b>406</b>, depending on configuration deployed at the sending AntiSpam Gateway <b>150</b>/<b>1950</b> and on whether an appropriate encryption certificate can be acquired for a receiving AntiSpam Gateway <b>150</b>/<b>1950</b> (see <figref idref="DRAWINGS">FIGS. 7 and 21</figref> for detail on certificate acquisition, known here as Introduction). As described above, the Gateway Token contains in particular an identifier naming AntiSpam Gateway <b>150</b>/<b>1950</b>, and a cryptographic signature linking the sender/caller, the message/signalling unit, and the Gateway itself. Generation of the signature and assembly of the Token as described takes place using conventional means well known to those skilled in the art. No action is required on the user's part, so the method may end here, although for messaging users with complex needs the remaining branches may also be executed.

0089If the message sender is not served by an AntiSpam Gateway <b>150</b>, the method continues at step <b>503</b> with an Invitation to join a Registry <b>120</b> as described in ArmorPost in the context of its <figref idref="DRAWINGS">FIG. 4</figref>. This sets the stage for a message sender to begin generating or acquiring authentication Tokens for outgoing messages. In step <b>504</b>, Registration begins, processing as shown in <figref idref="DRAWINGS">FIG. 5</figref> of ArmorPost through step <b>507</b>. At that point, the user has created an account in Registry <b>120</b>, but not installed an ArmorPost Agent. Step <b>505</b> determines the capabilities of the registering user with respect to the environment in which that user operates. In the preferred embodiment this determination is integrated with the Registration Form processed at steps <b>505</b> and <b>506</b> in <figref idref="DRAWINGS">FIG. 5</figref> of ArmorPost. Depending on the capabilities so determined, the process branches.

0090Branch <b>510</b> is taken by users who are able to complete installation of an ArmorPost Agent, thereby becoming an ArmorPost Agent Client <b>110</b>. Step <b>516</b> completes the Registration as described in ArmorPost <figref idref="DRAWINGS">FIG. 5</figref> steps <b>508</b>-<b>522</b>. At step <b>517</b>, a determination is made based on an implementation attribute of the ArmorPost Agent so established. If the ArmorPost Agent is tightly coupled internally as described in ArmorPost, such that it can automatically act upon incoming and outgoing messages, at step <b>518</b> it generates an Agent Token <b>402</b> for each outgoing message and add it to the message as a header. As described above, Agent Token <b>402</b> contains in particular an identifier naming Registry <b>120</b>, and a cryptographic signature linking the sender, the message, and the Registry. Generation of the signature and assembly of the Token as described takes place using conventional means well known to those skilled in the art. No additional action is required on the user's part, so the method may end here. On the other hand, if the ArmorPost Agent that results from Registration is loosely coupled internally, such that it can act autonomously but cannot act automatically on incoming and outgoing messages, it will, as shown in step <b>519</b>, periodically generate a User Token <b>403</b> and make it available for placement in outgoing messages. Again, generation of the signature and assembly of the Token as described takes place using conventional means well known to those skilled in the art. Since automatic inclusion is not possible in this case, the User Token <b>403</b> would be included in the message manually by the user prior to sending. This manual inclusion may take the form of a header or an additional block of text in the message body, and may require specific user action for each message or be at least partly automatic, depending on the capabilities of the user's Messaging Client <b>112</b>. Many such application programs are available to users, and the possible mechanisms are various, as is well known to those skilled in the art.

0091Branch <b>520</b> is taken by users who cannot complete installation of an ArmorPost Agent, whether due to lack of privilege or for any other reason, and who therefore operate a Standard Client <b>130</b>. It may also be taken by users who have completed installation of an ArmorPost Agent, but who for some reason are operating without it, such as when borrowing a different computer, and therefore choose to operate a Standard Client <b>130</b>. At Step <b>526</b>, the ArmorPost Registration concludes with an active account but without downloading and installing an ArmorPost Agent in the user's current environment. To acquire an authentication Token, at step <b>527</b> the user logs on to the website of Registry <b>120</b>, requests that it generate a current Registry Token <b>404</b>, and downloads the resulting Token either as a file or as text copied from the webpage display. At the same time, the issuing Registry <b>120</b> records the date and time of issuance so that previously-issued Registry Tokens <b>404</b> may be invalidated. As for the other Token types, generation of the signature and assembly of the Token as described take place using conventional means well known to those skilled in the art. The user then at step <b>528</b> adds the Registry Token <b>404</b> to any outgoing messages that are sent during the Token's validity period. As with step <b>519</b>, this manual inclusion may take the form of a header or an additional block of text in the message body, and may require specific user action for each message or be at least partly automatic, depending on the capabilities of the user's Messaging Client <b>112</b>. Many such application programs are available to users, and the possible mechanisms are various, as is well known to those skilled in the art.

0092Whether a user completes ArmorPost Registration via branch <b>510</b> or <b>520</b>, under certain circumstances the user's normal (Agent or Standard) Client environment is not available, such as when away from the computer system on which it is installed. Further, for certain messaging environments, particularly web-based email, it is desirable to provide a web-based interface that a registered user may access from any computer. Branch <b>530</b> can be taken by a user in this situation, by using a Proxy Client <b>140</b> at step <b>536</b> to log on to the website of Registry <b>120</b> and access its Webmail Proxy <b>324</b>. Once so logged in and thereby authenticated, the user may at step <b>537</b> compose a message, to which Webmail Proxy <b>324</b> attaches a Gateway Token <b>401</b> as an additional block of text in the message body. Webmail Proxy <b>324</b> then sends the message via the user's designated mail service, acting for and as the user in interactions with said mail service.

0093In <figref idref="DRAWINGS">FIG. 6</figref>, the various methods of Token Verification are described. A message carrying an authentication Token may arrive at either an AntiSpam Gateway <b>150</b>/<b>1950</b> or at an ArmorPost Agent Client <b>110</b>; different procedures are followed at the two elements.

0094A Messaging AntiSpam Gateway <b>150</b>, a Multimedia AntiSpam Gateway <b>1950</b>, or a Webmail Proxy <b>324</b> receiving a message carrying a Token performs Procedure <b>600</b>, which begins at step <b>601</b> by decrypting the Token, if necessary, using the receiving Gateway's own certificate or the system's shared secret as described above. Next, for all Token types, the Gateway at Step <b>602</b> compares the Token Date/Time field in the corresponding Identifying Section with the message or signalling unit date (which normally includes both date and time) as well as the current date and time. If the Token is older than either the message or the current time by a significant duration, which depends upon the Token type as described above in the context of <figref idref="DRAWINGS">FIG. 4</figref>, the message/call may be discarded or rejected. Continuing to step <b>603</b>, the incoming Token is examined to determine its type; subsequent processing is specific to each type of authentication Token. Branch <b>604</b><i>a </i>is taken if it is a Gateway Token <b>401</b>, Encrypted Gateway Token <b>405</b> (which at this point is substantially identical to Gateway Token <b>401</b>), or Alternate Gateway Token <b>406</b>. In that case, at step <b>605</b><i>a </i>the receiving AntiSpam Gateway <b>150</b>/<b>1950</b> or Registry <b>120</b>/Webmail Proxy <b>324</b> uses the Issuing Gateway Identifier <b>411</b> to locate a certificate for the sending AntiSpam Gateway <b>150</b>/<b>1950</b> or Registry <b>120</b>/Webmail Proxy <b>324</b>. If none can be found locally, the receiving Gateway or Registry has not been Introduced to the sending Gateway or Registry, so an Introduction is requested from the Network Authority <b>160</b> that is superior to the receiving AntiSpam Gateway <b>150</b>/<b>1950</b> or Webmail Proxy <b>324</b>. The Introduction process follows the principle of providing the certificate of one node, for signature validation by another, via the chain of Network Authorities trusted by the node requiring the certificate. For details of the Authority topology and Introduction protocol, refer to the description of <figref idref="DRAWINGS">FIG. 22</figref>. Suffice to say here that in a preferred embodiment, a series of special DNS queries directed through the tree of Network Authorities is used to retrieve the certificate, followed by a validation of the retrieved certificate by verifying its Certificate Authority signatures in the chain of trust up to the Root Network Authority before using the certificate. With a certificate now available for the sending Gateway <b>150</b>/<b>1950</b> or Registry <b>120</b>/Webmail Proxy <b>324</b>, the receiving Gateway <b>150</b>/<b>1950</b> or Webmail Proxy <b>324</b> may now, in step <b>606</b><i>a</i>, verify the Gateway Token. To do so, Procedure <b>630</b> is used. Upon its completion, the result of the verification is used at step <b>607</b> to decide whether the message should be relayed or dropped.

0095An ArmorPost Agent Client <b>110</b> receiving a message carrying a Token performs Procedure <b>610</b>, which for all Token types begins at step <b>611</b> by comparing the Token Date/Time field in the corresponding Identifying Section with the message date (which normally includes both date and time) as well as the current date and time. If the Token is older than either the message or the current time by a significant duration, which depends upon the Token type as described above in the context of <figref idref="DRAWINGS">FIG. 4</figref>, the message may be discarded. Continuing to step <b>612</b>, the incoming Token is examined to determine its type; subsequent processing is specific to each type of authentication Token. Step <b>613</b> is executed if the incoming Token is a Gateway Token <b>401</b>/<b>406</b>, and the Issuing Gateway Identifier <b>411</b> names an AntiSpam Gateway <b>150</b> or Webmail Proxy <b>324</b> that is known to the ArmorPost Agent Client <b>110</b>. In this case, at step <b>613</b><i>a </i>that Gateway or Registry's certificate is passed to Procedure <b>630</b> to verify the incoming Token locally. Step <b>614</b> is executed if the incoming Token is a Gateway Token <b>401</b>/<b>406</b> and its Issuing Gateway Identifier <b>411</b> names an AntiSpam Gateway <b>150</b> or Webmail Proxy <b>324</b> that is not known, or if the incoming Token is of any other type. In this case, a remote Token Verification is needed, so Procedure <b>620</b> is used in step <b>614</b><i>a </i>to pass the Token and relevant portions of the message to ArmorPost Agent Client <b>110</b>'s Registry <b>120</b> for verification. Whether step <b>613</b> or step <b>614</b> was executed, at step <b>615</b> the result of the verification is used to decide whether the message should be presented or discarded.

0096Procedure <b>620</b> verifies any type of Token by querying a superior or specified Registry <b>120</b>. It may be performed on behalf of any system element that cannot verify a particular Token, including an ArmorPost Agent Client <b>110</b>, an AntiSpam Gateway <b>150</b>, a Registry <b>120</b>, or a Webmail Proxy <b>324</b>. The procedure begins at step <b>621</b>, in which the Date: value, From: address, and To: list (or in the alternate embodiment, the partial or full message body) are extracted from the message carrying the Token being verified. Step <b>622</b> transforms the To: list or message body using a one-way cryptographic hash function so that the verification request being sent to a remote Registry <b>120</b> does not unnecessarily reveal the message to a third party. Note that in some situations Procedure <b>620</b> is used recursively. In such an event, step <b>621</b> of the inner Procedure <b>620</b> extracts the message Date: and From: address from the query message received as part of the outer Procedure <b>620</b>, while the inner step <b>622</b> extracts the To: list or message body already hashed from that received query. At step <b>623</b>, then, the verification inputs acquired in the two previous steps, along with the Token itself, are sent in a query message to the appropriate Registry <b>120</b>. If Procedure <b>620</b> is used in the context of Procedure <b>610</b>, then that Registry <b>120</b> is the one at which the requesting ArmorPost Agent Client <b>110</b> is registered. If Procedure <b>620</b> is being used in the context of Procedure <b>600</b>, or recursively from Procedure <b>620</b>, then the appropriate Registry <b>120</b> is the one named in the Verifying Registry Identifier field of the current Token.

0097Upon arrival of the query message at the appropriate Registry <b>120</b>, that Registry <b>120</b> at step <b>624</b> examines the received Token and determines its type, which governs the path taken by subsequent processing. Branch <b>625</b><i>a </i>is taken if the Token is a Gateway Token. At step <b>626</b><i>a</i>, a certificate for the AntiSpam Gateway <b>150</b> named in the Issuing Gateway Identifier <b>411</b> field of Gateway Token <b>401</b>/<b>406</b> is acquired. If the current Registry <b>120</b> has been introduced to that Gateway <b>150</b> already, the certificate may be in a local cache; otherwise, an Introduction is requested from this Registry <b>120</b>'s superior Authority <b>160</b>, which if necessary requests it in turn up the hierarchy to the Root Authority. Once the Introduction is complete, step <b>627</b><i>a </i>uses the Issuing Gateway <b>150</b>'s certificate to verify the Gateway Token <b>401</b>/<b>406</b> by executing Procedure <b>630</b>, described below. The result of that procedure is reported as the result of this one at step <b>628</b><i>a. </i>

0098Branch <b>625</b><i>b </i>is taken for other types of Token that are verified at another Registry <b>120</b>. That is, if the Token being verified is an Agent Token <b>402</b>, User Token <b>403</b>, or Registry Token <b>404</b>, and the Verifying Registry Identifier field names a different Registry <b>120</b> than the current one, this branch is chosen. The first step, <b>626</b><i>b</i>, is to locate a certificate for the other Registry <b>120</b>. If the two Registries <b>120</b> have already been Introduced, this certificate may be available in a local cache; if not the current Registry <b>120</b> requests the Introduction from its superior Registry <b>120</b>, as before iterating the request through the hierarchy to the Root Registry if necessary. Once the Introduction is complete, step <b>627</b><i>b </i>recurses on Procedure <b>620</b> to request Token verification from the remote Registry <b>120</b>. Step <b>628</b><i>b </i>reports the result of the inner Procedure <b>620</b> as the result of the current, outer, Procedure <b>620</b>.

0099Branch <b>625</b><i>c </i>is taken for any Agent, User, or Registry Token verifiable at the current Registry <b>120</b>; that is, if the Verifying Registry Identifier field names this Registry. In that case, the certificate of the user for whom the Token was created, as identified by the From: address in the verification request, should be available in the local user database at step <b>626</b><i>c</i>; if not, the Token is rejected. In step <b>627</b><i>c</i>, the Token Date/Time value from the Token being verified is compared against the current date and time. If the Token is too old, it is rejected. If the Token is a Registry Token <b>404</b>, the Token Date/Time <b>442</b> is also compared against the date and time at which the last Registry Token <b>404</b> was issued by Registry <b>120</b> back in step <b>527</b> of <figref idref="DRAWINGS">FIG. 5</figref>. If the Token is older than the most recently issued Token, it is rejected. Note that in both of these date comparisons, some number of extra days' leeway may be granted to allow for delays in message delivery. This extra lifetime may be set administratively by the Registry <b>120</b>, or the user may be allowed to set it. Assuming the date checks pass, the cryptographic signature in the Token's Signature Section is verified using the input data in the verification request, the user's certificate located in step <b>626</b><i>c</i>, and the Token itself. The specific arrangement of data provided to the verification algorithm is as described in the context of <figref idref="DRAWINGS">FIG. 4</figref>, which depicts the contents of each Token type. The specific algorithm used for signature verification may vary according to the implementation, although in a preferred embodiment it is the well-known RSA signature technique using asymmetric keys. At step <b>628</b><i>c</i>, the result of the signature verification is reported as the result of the Token verification.

0100Regardless of which branch is taken through Procedure <b>620</b>, at step <b>629</b> the result of the verification is returned to the requester in a message.

0101Procedure <b>630</b> verifies a Gateway Token <b>401</b>/<b>406</b> directly within either an AntiSpam Gateway <b>150</b>/<b>1950</b>, a Registry <b>120</b>, a Webmail Proxy <b>324</b>, or an ArmorPost Agent Client <b>110</b>. It may be called as a subroutine from Procedures <b>600</b>, <b>610</b>, and <b>620</b> as appropriate and as previously described. The procedure begins with step <b>631</b>, in which the From: address, Date: value, and To: list (or in the alternate embodiment, the full or partial message body) are extracted from the message carrying the Gateway Token being verified. At step <b>632</b>, the To: list or message body is transformed using a cryptographic one-way hash function, the result of which should match what was used in creating the Token. Note that Procedure <b>630</b> may be used either directly upon receipt of a message carrying a Gateway Token, or as part of Procedure <b>620</b> in response to a verification request. In the latter case, the verification input data acquired in steps <b>631</b> and <b>632</b> are pulled directly from the request instead of from the Token-bearing message; the To: list or message body is already in hashed form. Step <b>633</b> uses the input data as shown in <figref idref="DRAWINGS">FIG. 4</figref> and the Issuing Gateway's certificate acquired prior to beginning Procedure <b>630</b> to verify the cryptographic signature in the Gateway Token's Signature Section <b>415</b>. The specific algorithm used for signature verification may vary according to the implementation, although in a preferred embodiment it is the well-known RSA signature technique using asymmetric keys. In step <b>634</b>, the procedure reports the result of step <b>633</b>'s signature verification as the result of Procedure <b>630</b>.

0102The next section describes <figref idref="DRAWINGS">FIGS. 7-12</figref>, which put Token processing in the context of message flow scenarios. The primary discriminants among these figures are whether the sender and recipient are served by a Messaging AntiSpam Gateway <b>150</b> and, if the sender is not so served, whether the sender is a registered user of a Registry <b>120</b>. The combinations yield six separate scenarios, each of which is depicted in its own diagram.

0103In <figref idref="DRAWINGS">FIG. 7</figref> both the sender and the recipient of a message are served by an AntiSpam Gateway <b>150</b>. The figure depicts a separate Gateway for each of sender and recipient, but the scenario also applies if both are served by the same Gateway. The scenario begins in step <b>701</b> with the sender composing and sending a message. It traverses the sending service provider's infrastructure in step <b>702</b>, arriving at the sender's AntiSpam Gateway <b>150</b>. Step <b>703</b> shows the sending Gateway authenticating the sender of the message; note that this may be implemented in a cooperative fashion with the remainder of the sender's service provider network infrastructure, and generally uses authentication techniques that are well known by those skilled in the art. In step <b>704</b> the message is counted against the sender's traffic allocation. This is a significant attribute of the present invention. Prior art systems generally take the step of authenticating the sender, but do not prevent senders from generating excessive traffic. Spam tends to be sent in very large quantities; enforcing a traffic limit of, for example, 50 messages per day for each user can prevent a great deal of spam traffic. Message counting is critical in preventing spam: without it, a valid Token might be used innumerable times before its expiration, thereby allowing an automatic process to send spam that appears to be valid. The message counting is intended to limit traffic for each sender to a message rate that is both humanly possible and insufficient for spammers' purposes. If the message would cause the sender to exceed the allotted traffic volume, it is dropped or rejected. The message may also be queued pending a notification to and corresponding confirmation from the sender that the excess messages are intended. This approach could be used in situations where the sender is known not to be an intentional spammer, such as an authenticated user of an enterprise network. In such cases, the occasional excess traffic might be expected and admitted upon confirmation, but detection of unintended excess traffic is used to prevent clandestine spamming by zombies installed via an infectious vector (virus, worm, trojan horse, or other malware).

0104If the message is allowed to go through, at step <b>705</b> the Gateway decides whether encryption is required, either on the Token to be generated, on the message relay transaction to come, or both. If so, and no encryption key certificate is already known for the destination Gateway, an Introduction is requested by sending an Introduction Request message, Step <b>706</b>, to the superior Network Authority <b>160</b> for this Gateway <b>150</b>. At Step <b>707</b>, Authority <b>160</b> retrieves the destination Gateway's certificate, either from its own database or by recursively requesting Introduction via higher level Authorities, depending on whether it is the Authority for the destination Gateway or not; for more detail on this procedure refer to the description of <figref idref="DRAWINGS">FIG. 22</figref>. The certificate is returned to the sending Gateway in Step <b>708</b>, the Introduction Response message.

0105At Step <b>709</b>, then a Gateway Token <b>401</b>, <b>405</b>, or <b>406</b> is generated, depending on the Gateway operator's preferences as previously described, and added to the message as a header. In step <b>710</b> the message is relayed to the recipient's service provider. Step <b>711</b> depicts the message, with its Gateway Token, in transit between the two service providers' networks. This transfer operation may be encrypted or unencrypted, depending on Gateway operators' preferences and, optionally, per-user configuration data. If encryption is to be applied, the receiving Gateway's certificate retrieved during Introduction, and the sending Gateway's certificate, are used in the standard way by the Transport Layer Security (TLS) protocol, which is well known to those skilled in the art.

0106The message arrives at the AntiSpam Gateway <b>150</b> protecting the recipient's service provider's network, and at step <b>712</b>, the incoming message is scanned for the presence of an authentication Token. Since in this scenario one was placed in the message by the sending AntiSpam Gateway <b>150</b>, it will be detected; the alternative scenario, in which no Token would be detected, is shown in <figref idref="DRAWINGS">FIG. 9</figref>. To verify the Token, a certificate noting the public key of the sending Gateway is required. If the receiving Gateway has previously been introduced to the sending Gateway, this certificate may be found in a local memory buffer that is used to retain introduction data. Otherwise, at step <b>713</b> an Introduction is requested. Step <b>714</b> shows this Introduction Request in transit to the superior Authority <b>160</b>; the request may be forwarded up the hierarchy as far as necessary, even to the Root Authority. The Authority <b>160</b> at which the sending Gateway <b>150</b> is known retrieves its certificate in step <b>715</b>, and sends it back to the receiving Gateway <b>150</b> that requested it in step <b>716</b>. For more detail on the Introduction protocol, refer to the description of <figref idref="DRAWINGS">FIG. 22</figref>. Back at the receiving AntiSpam Gateway <b>150</b>, with the certificate for the sending AntiSpam Gateway <b>150</b> now available, the Gateway Token may be verified in step <b>717</b>, as previously described in Procedure <b>600</b>. At step <b>718</b>, if the verification fails, the message may be dropped because its sender is inauthentic. At step <b>719</b>, if the verification passes, the message may be relayed to the recipient. Prior to relaying, however, the original Gateway Token from the sending Gateway <b>150</b> is replaced by a new Gateway Token from the receiving Gateway <b>150</b>. This prevents a recipient with an ArmorPost Agent Client <b>110</b> from reverifying the original Gateway Token; it instead verifies the new Gateway Token locally. If the old Token were simply removed, a recipient ArmorPost Agent Client <b>110</b> would trigger an invitation to the sender, which would also be inappropriate since the message and sender have already been verified at the AntiSpam Gateways <b>150</b>. Note that this implies awareness at ArmorPost Agent Client <b>110</b> of the certificates used by any and all AntiSpam Gateways <b>150</b> that may guard it; a mechanism for discovering these certificates is shown as part of <figref idref="DRAWINGS">FIG. 10</figref>. Alternatively, if receiving AntiSpam Gateway <b>150</b> is aware that none of its users are ArmorPost Agent Clients <b>110</b>, but instead are all Standard Clients <b>130</b>, it may omit replacing the token. At step <b>720</b> the message, with or without a new Token, moves to the messaging client of the recipient, which in step <b>721</b> receives it to conclude the scenario.

0107In <figref idref="DRAWINGS">FIG. 8</figref>, the sender of the message is registered to a Registry <b>120</b>, and is not served by an AntiSpam Gateway <b>150</b>, while the recipient is served by an AntiSpam Gateway <b>150</b>. The scenario begins at step <b>801</b> with the sender composing a message. At step <b>802</b> an authentication Token is attached to the message. In this scenario, the sender may or may not have an ArmorPost Agent Client <b>110</b>. Therefore the Token may be attached either manually or automatically, and may be of any type from <figref idref="DRAWINGS">FIG. 4</figref> except one of the Gateway Tokens. At step <b>803</b>, the message is sent, and step <b>804</b> depicts the message with its Token in transit toward the recipient. The message arrives at the receiving AntiSpam Gateway <b>150</b> protecting the recipient's service provider; in step <b>805</b> that element receives it and detects the Token that is in the message. In step <b>806</b>, the Registry <b>120</b> named by the Verifying Registry Identifier field is determined, and if the receiving AntiSpam Gateway <b>150</b> has not yet been Introduced to the verifying Registry <b>120</b>, an Introduction is requested. The Introduction signalling in steps <b>807</b>-<b>809</b> is substantially identical to that in steps <b>714</b>-<b>716</b> above. Note that the certificate retrieved at this point is not usable for verifying the Token directly. Instead, it is used to authenticate the Registry <b>120</b> that responds when requesting that it verify the Token, which takes place in step <b>810</b> using Procedure <b>620</b> from <figref idref="DRAWINGS">FIG. 6</figref>. Signalling that occurs during execution of Procedure <b>620</b> is depicted in steps <b>811</b>-<b>818</b>. First a Verify Token Request message, containing the verification input data as described previously and the Token itself, is sent from the receiving AntiSpam Gateway <b>150</b> to the verifying Registry <b>120</b> in step <b>811</b>. The certificate of the verifying Registry, obtained during Introduction, is used to authenticate that the server to which Gateway <b>150</b> connects is indeed the correct Registry <b>120</b>. At step <b>812</b>, the verifying Registry determines whether it has been Introduced to the requesting Gateway, and if not requests an Introduction from its own Authority hierarchy. Steps <b>813</b>-<b>815</b>, which are substantially identical to steps <b>807</b>-<b>809</b> and steps <b>714</b>-<b>716</b>, show this Introduction. Once the requesting Gateway's certificate is available, it can be authenticated as a permitted requester of Token verification. Assuming that authentication succeeds, at step <b>816</b> the verifying Registry <b>120</b> continues with branch <b>625</b><i>c </i>of Procedure <b>620</b> to verify the presented Token. If the Token verification is successful, at step <b>817</b> the verifying Registry increments the sending user's traffic count. If the message with which the verified Token is associated causes the permitted traffic level to be exceeded, or if the Token verification failed, the Token is rejected. Otherwise, the Token is approved. This result is returned to the requesting Gateway <b>150</b> in a Verify Token Response message at step <b>818</b>. Step <b>819</b> shows the Gateway receiving this response. The remainder of the scenario, steps <b>820</b>-<b>823</b>, proceed similarly to steps <b>718</b>-<b>721</b> in <figref idref="DRAWINGS">FIG. 7</figref>.

0108<figref idref="DRAWINGS">FIG. 9</figref> depicts the scenario in which the sender has neither registered with a Registry <b>120</b>, nor had the good fortune to be served by an AntiSpam Gateway <b>150</b>, while the recipient is so served. As usual, the sender composes and sends a message at step <b>901</b>. In this situation, though, the resulting message, shown in transit toward the recipient in step <b>902</b>, has no authentication Token in it of any type. This Tokenless message arrives at the AntiSpam Gateway <b>150</b> protecting the recipient's service provider's network, which in step <b>903</b> receives it and detects that there is no Token. In step <b>904</b>, the Gateway <b>150</b> stores the message for future use, and requests its own Registry <b>120</b> to Invite the sender of the message to register for antispam service. This request is made in step <b>905</b> via an Invitation Request message that contains the headers from the saved message. These headers are used to determine what address should be Invited. They may also be arranged for presentation to the recipient user upon logging in at Website <b>321</b> of Registry <b>120</b>. Note that, as described for Trusted Couriers in U.S. patent application Ser. No. 10/709,952 by the present inventors (referred to as ArmorPost Networking) the recipient's Registry <b>120</b> may not be permitted to invite this sender due to lack of scope. In that situation, which is not depicted in <figref idref="DRAWINGS">FIG. 9</figref>, the recipient's Registry <b>120</b> would defer the Invitation to a Registry <b>120</b> associated with its superior Network Authority <b>160</b>; this deferral may be repeated up the hierarchy until reaching a Registry that is permitted to make the Invitation to the sender. When a Registry <b>120</b> that may perform the Invitation is reached, it can at step <b>906</b> prepare an Invitation for the message sender. To ensure that the sender will only respond to the Invitation if it resulted from a message actually sent by the sender, the text of the invitation message preferably includes the recipient's address and the original message subject. It is also possible that no Registry in the network is enabled to perform Invitation. This could occur during early stages of deployment, before Agent Client <b>110</b> and/or Webmail Proxy module <b>324</b> have been implemented. In this case, alternative processing not depicted in <figref idref="DRAWINGS">FIG. 9</figref> and generally known to those skilled in the art could be used. For example, the incoming message may be treated as suspect and placed in a queue, perhaps with other such messages, while the recipient user is notified that one or more suspect messages are available for examination via External Website module <b>321</b>. Such “gray list” processing may also offer the opportunity for the recipient user to create a “white list” of senders from whom no Token is expected but messages should be delivered anyway.

0109Steps <b>907</b> and <b>908</b> depict in short the Invitation and Registration procedures which are described in detail in ArmorPost. If the invited user does not complete Registration, the Gateway and Registries involved in the process may after an appropriate duration discard the original message. On the other hand, if in the interim the recipient logs in at the Registry and, seeing the message header information, decides the sender is legitimate, the message may be released to the recipient prior to completion of the Registration. When Registration is complete, Registry <b>120</b> in step <b>909</b> increments the traffic counter for the newly registered sender, and in step <b>910</b> informs the recipient Gateway that the sender is valid by sending an Invitation Complete message in step <b>911</b>. If the Invitation Request had been deferred to a different Registry than the one directly affiliated with the recipient Gateway, this Invitation Complete message propagates back through the hierarchy to the originating Registry, and thence to the Gateway. When informed that the message sender is valid, the recipient Gateway <b>150</b> may at step <b>912</b> generate a Gateway Token and add it to the message, for the reasons previously explained. The message is then relayed to the recipient in step <b>913</b>; it is shown in transit, carrying the newly assigned Token, in step <b>914</b>. Also as previously explained, in certain circumstances a Gateway Token may not be generated and added to the message at this point. Finally, in step <b>915</b> the recipient's messaging client receives the message and handles it as normal.

0110<figref idref="DRAWINGS">FIG. 10</figref> depicts the scenario in which the sender is served by an AntiSpam Gateway <b>150</b>, and the recipient does not but instead is registered and has an ArmorPost Agent Client <b>110</b>. Many aspects of this scenario are similar to the previous ones, although Token handling in an ArmorPost Agent Client <b>110</b> differs in some subtle ways from Token handling in an AntiSpam Gateway <b>150</b>. The scenario begins, as usual, with the composition of a message by the sender. Steps <b>1001</b>-<b>1006</b> are in fact substantially identical to steps <b>701</b>-<b>704</b> and <b>709</b>-<b>710</b>, since both this scenario and the <figref idref="DRAWINGS">FIG. 7</figref> scenario share the attribute that the sender is served by an AntiSpam Gateway <b>150</b>. Therefore, the sender is authenticated, the message is counted against the sender's traffic allowance, and a Gateway Token <b>401</b> or <b>406</b> is added to the message. Gateway Token <b>405</b>, and the Introduction and encryption steps <b>705</b>-<b>708</b> from <figref idref="DRAWINGS">FIG. 7</figref>, are not used here because the recipient is not served by a Gateway. At step <b>1007</b>, the message with its Token is shown in transit to the recipient. Since the recipient is not served by an AntiSpam Gateway <b>150</b>, the ArmorPost Agent Client <b>110</b> receives the message at step <b>1008</b>, and determines that it carries a Gateway Token. It is possible that the sending Gateway <b>150</b>, named in the Issuing Gateway Identifier field <b>411</b> of Gateway Token <b>401</b>/<b>406</b>, is known to the receiving ArmorPost Agent Client <b>110</b>. If so, at step <b>1009</b> the sending Gateway's certificate is used to verify the Token locally using Procedure <b>630</b> from <figref idref="DRAWINGS">FIG. 6</figref>. If not, ArmorPost Agent Client <b>110</b> at step <b>1010</b> uses Procedure <b>620</b> to request verification from its Registry. Steps <b>1011</b> through <b>1017</b> detail the signalling used during that Procedure, and are similar to steps <b>811</b>-<b>818</b>. The Verify Token Request message, containing the verification input data and the Token, are conveyed to Registry <b>120</b> in step <b>1011</b>. The Registry at step <b>1012</b> examines the Issuing Gateway Identifier <b>411</b> in Gateway Token <b>401</b>/<b>406</b> and determines whether it already has a certificate for verifying that Gateway's Tokens. If not, an Introduction is requested. Steps <b>1013</b>-<b>1015</b> carry out the Introduction, and are substantially identical to steps <b>807</b>-<b>809</b> or <b>813</b>-<b>815</b>. Once the Registry and Gateway are Introduced, at step <b>1016</b> the Registry verifies the Token using Procedure <b>630</b>. The result of the verification is returned to the requesting ArmorPost Agent Client <b>110</b> in step <b>1017</b>. Whether the Token was verified locally at step <b>1009</b>, or remotely in steps <b>1010</b>-<b>1017</b>, if the verification failed the message is dropped at step <b>1018</b>. If the verification succeeded, the message is allowed to pass into the user's view at step <b>1019</b>. Optionally, at step <b>1020</b> the user's Registry <b>120</b> may choose to forward the sending Gateway's certificate to the user's ArmorPost Agent Client <b>110</b>, so that future Tokens from that Gateway may be verified there directly. This is shown as an Introduction message from Registry <b>120</b> to ArmorPost Agent Client <b>110</b> at step <b>1021</b>; the certificate is saved at step <b>1022</b>

0111<figref idref="DRAWINGS">FIG. 111</figref> depicts the scenario in which both sender and recipient are registered users with ArmorPost Agent Clients <b>110</b>, and neither is served by an AntiSpam Gateway <b>150</b>. Again, the flow is similar to the flow in previous scenarios. Steps <b>1101</b>-<b>1104</b> are substantially identical to steps <b>801</b>-<b>804</b>, except that the message with its Agent Token <b>402</b> makes it all the way to the recipient's client rather than stopping off at a Gateway first. At step <b>1105</b>, the client receives the message and detects the Token it carries. Seeing that it's an Agent Token <b>402</b>, which can only be verified by the Registry <b>120</b> at which the sender is registered, ArmorPost Agent Client <b>110</b> at step <b>1106</b> initiates Procedure <b>620</b> to request verification from its own Registry <b>120</b>. The signalling required to execute Procedure <b>620</b> is shown in steps <b>1107</b>-<b>1122</b>, beginning with the Verify Token Request message in step <b>1107</b>. In step <b>1108</b>, the recipient's Registry determines whether it has been Introduced to the sender's Registry; if not, Introduction is requested from its superior Authority. The same Introduction process as previously described is shown in steps <b>1109</b>-<b>1111</b>. With the sender's Registry's certificate now available, a second Procedure <b>620</b> is commenced at step <b>1112</b>. At this point, steps <b>1113</b>-<b>1120</b> are substantially identical to steps <b>811</b>-<b>818</b> as previously described. This concludes the second, or inner, Procedure <b>620</b>, and at step <b>1121</b> the verification result is forwarded by the sender's Registry to the recipient's Registry. Step <b>1122</b> conveys the verification result from the recipient's Registry to the recipient's ArmorPost Agent Client, concluding the first, or outer, Procedure <b>620</b>. As before, if the verification failed, the message is dropped at step <b>1123</b>. If the verification succeeded, the message is allowed into the user's view at step <b>1124</b>.

0112<figref idref="DRAWINGS">FIG. 12</figref> depicts the scenario in which the sender is neither registered at a Registry <b>120</b> nor served by an AntiSpam Gateway <b>150</b>, and the recipient, who is registered, uses an ArmorPost Agent Client <b>110</b> instead of being served by an AntiSpam Gateway <b>150</b>. This scenario is nearly identical to the one in <figref idref="DRAWINGS">FIG. 9</figref>, except that the ArmorPost Agent Client <b>110</b> acts to request the sender be invited, rather than having an AntiSpam Gateway <b>150</b> to do so. That is, steps <b>1201</b>-<b>1204</b> are substantially identical to steps <b>901</b>-<b>904</b>, except that steps <b>1203</b>-<b>1204</b> take place in ArmorPost Agent Client <b>110</b> where steps <b>903</b>-<b>904</b> take place in an AntiSpam Gateway <b>150</b>. Similarly, steps <b>1205</b>-<b>1211</b> are substantially identical to steps <b>905</b>-<b>911</b> except that they are initiated by the ArmorPost Agent Client <b>110</b> instead of an AntiSpam Gateway <b>150</b>. Once the Registry <b>120</b> reports that the sender is valid via the Invitation Complete message in step <b>1211</b>, the client may present the message in step <b>1212</b>.

0113Note that the foregoing six scenarios are representative of the possible scenarios that may occur in Messaging Spam Prevention System <b>100</b>. Numerous additional scenarios may be constructed from elements of these by those skilled in the art.

0114The Dynamic Business Directory System <b>1300</b> depicted in <figref idref="DRAWINGS">FIG. 13</figref> overlays the Messaging Spam Prevention System <b>100</b>. This overlay approach allows the Dynamic Business Directory System and its users to depend upon the spam-free environment. In addition to the multiple Registries <b>120</b> and Standard Clients <b>130</b> comprising Messaging Spam Prevention System <b>100</b>, the Packet Network <b>102</b> and End-to-End Messaging Infrastructure <b>101</b> upon which both Messaging Spam Prevention System <b>100</b> and Dynamic Business Directory System <b>1300</b> are constructed, and the interfaces among them, two new kinds of element are shown.

0115First, Directory Engines <b>1310</b> provide the mechanism whereby directory listings are created, stored, and presented to users. Generally, a Directory Engine <b>1310</b> is affiliated with a Registry <b>120</b>, both being owned and/or operated by a common organization so that business synergies may be realized between the two services. Referring to the definitions of Public and Private Registry derived from ArmorPost Networking, it is reasonable to expect that a Directory Engine <b>1310</b>'s corresponding Registry <b>120</b> will usually be a Public one, again because of the business goals the two systems working together satisfy: attracting users to interact with advertisers.

0116Directory Engine <b>1310</b> consists of three primary components. First is Messaging Processor <b>1311</b>. This component is responsible for message-based interactions with users, represented by User Standard Clients <b>130</b><i>a</i><b>1</b> and <b>130</b><i>b</i><b>1</b> in Spam Prevention System <b>100</b>, and businesses whose advertisements are listed with the Directory Engine, represented by Lister Standard Clients <b>130</b><i>a</i><b>2</b> and <b>130</b><i>b</i><b>2</b>. As shown in the figure, Messaging Processor <b>1311</b> is both a component of Directory Engine <b>1310</b> and a participant in Spam Prevention System <b>100</b>. As will be seen in <figref idref="DRAWINGS">FIG. 14</figref>, this is effected by an ArmorPost Agent Client <b>110</b> that is embedded as a module of Messaging Processor <b>1311</b>, making it possible to exchange spam-free messages with ordinary clients associated with both users and advertisers. Thus Messaging Processor <b>1311</b> may offer a mediated communication path between users and advertisers as well. The second of Directory Engine <b>1310</b>'s components is the Listing Processor <b>1312</b>, which is responsible for managing advertiser's listings. Both local listings belonging to advertisers who are direct customers of the local Directory Engine, and remote listings belonging to advertisers who are customers of other Directory Engines, are stored here. Finally, Display Server <b>1313</b> is responsible for presenting listings to users as they request information about advertisers. Thus Listing Processor <b>1312</b> and Display Server <b>1313</b> together offer a universal advertising medium allowing users to discover information about businesses of all sorts. This medium is in some respects similar to a so-called “Yellow Pages” directory, which is a well-known concept. Further, the ability of multiple Directory Engines <b>1310</b> to share their listings with one another, thus providing users of every Directory access to a common view from all Directories, may be considered analogous to a real estate “Multiple Listing Service,” which is also a well-known concept. The combination of these two ideas, and application of them to a networked environment, provides a unique opportunity to revitalize commercial communication using electronic messaging as a safe medium. Of course, without interconnect these capabilities cannot be made available broadly. Therefore, Interface <b>1313</b> provides message-based interconnect with other elements via End-to-End Messaging Infrastructure <b>101</b>, and Interface <b>1314</b> provides packet-level interconnect for all other types of communication via Packet Network <b>102</b>.

0117The second additional element appearing in Dynamic Business Directory System <b>1300</b> is the Directory Clearinghouse <b>1320</b>. While there may be multiple Directory Engines <b>1310</b>, the system includes only a single Clearinghouse. It may be affiliated with the Root Authority, although that is not required. The Directory Clearinghouse's role is to interconnect the various Directory Engines so that their listings may be shared, but without revealing to any one Directory Engine which other Directory Engine actually owns a particular listing. The latter feature is intended to prevent an environment in which Directory operators poach advertisers from one another. Thus listings are relayed among the Engines by the Clearinghouse, and transactions affecting the business of presenting listings are cleared through the Clearinghouse. Such transactions may include reporting the number of viewings a listing has enjoyed, the number of mediated communications requested by users at a particular Directory Engine, and mediated communications themselves. This architecture carries the potential to enable numerous additional transaction types, representing numerous alternative business models, the nature of which cannot be anticipated by the present inventors. Note that the practice of sharing a listing without revealing which Directory Engine owns it leads to running all mediated communication between an advertiser at one Directory Engine and a user at another through the Clearinghouse. This may pose a challenging operational environment at the Clearinghouse, so in an alternate embodiment the Directory Engines may be allowed to relay mediated communications amongst one another directly. This alternate embodiment would not prevent Directory Engine operators from knowing one another's advertisers, and therefore does not prevent poaching. However, poaching does not actually require knowledge of what Directory operator owns a particular listing for a particular advertiser, so making this information available does not necessarily hurt anything. Directory Clearinghouse <b>1320</b> consists of two primary components. Distribution Processor <b>1321</b> is responsible for providing the transaction clearing and inter-Directory communication capabilities described above, while Account Management component <b>1322</b> records the relationship with each Directory Engine <b>1310</b>. Interface <b>1323</b> provides message-based interconnect with other elements via End-to-End Messaging Infrastructure <b>101</b>. Interface <b>1324</b> provides packet-level interconnect for all other types of communication via Packet Network <b>102</b>.

0118Additional detail of Directory Engine <b>1310</b> can be seen in <figref idref="DRAWINGS">FIG. 14</figref>. Messaging Processor component <b>1311</b> is shown here as comprising an ArmorPost Agent Client <b>110</b> for the purpose of participating in the Spam Prevention System <b>100</b> as an authenticated sender of valid messages. There is also a Message Distribution module <b>1410</b>, which is responsible for storing and managing the distribution of mediated communications. When a user wishes to make an inquiry to an advertiser without revealing the user's own messaging address, this module handles the mapping between the user and the inquiry, so that any response from the advertiser may be relayed to the user. Also, when a user chooses to subscribe to bulletins from a particular advertiser or set of advertisers in a classification, Message Distribution module <b>1410</b> is responsible for recording the fact and managing the distribution of bulletins to users. In the embodiment that hides Directory Engine identities from one another for each advertiser, all bulletins also go to the Clearinghouse; in the alternate embodiment this module also records which other Directory Engines currently have users requesting a particular bulletin. Note that user addresses are never revealed outside the Directory Engine and associated Registry, protecting both the users' privacy and the Directory Engine operator's subscriber base.

0119The next component of Directory Engine <b>1310</b> is the Listing Processor <b>1312</b>, which provides the heart of the present invention's unique functionality with respect to Dynamic Business Directory System <b>1300</b>. The first of its modules is the Local Listing Database <b>1421</b>, which manages the listings of advertisers with whom the operator of a particular Directory Engine <b>1310</b> has a direct relationship. This constitutes the master data view of those listings. Remote Listing Cache <b>1422</b> manages the listings held by other Directory Engines <b>1310</b>. These listings are available for presentation to and interaction with users, but not for local management. Presentation Ordering module <b>1423</b> is responsible for collating all listings, both local and remote, into result lists according to user requests. For example, if a user indicates an interest for all advertisers of a certain category within a certain region, this module selects and orders the listings for presentation. Several criteria may be offered for selection, in a manner similar to a search engine or related technology. Within a result set, the presentation order is influenced heavily by feedback from previous users viewing the same advertisers. When users provide positive feedback on an advertiser, or choose to receive additional communications from an advertiser via messaging, that advertiser's position in the presentation order is improved. Various approaches are possible to weigh these and other dynamic attributes in ordering results, and the Presentation Ordering module <b>1423</b> is intended to be extensible so that additional attributes and weights may be added to the system over time. It is this responsiveness to user feedback and viewing traffic that makes the Dynamic Business Directory System <b>1300</b> dynamic. Note that, as previously observed, the behavior of Presentation Ordering module <b>1423</b> in selecting and ordering listings is conceptually similar to the behavior of an Internet search engine. The particular methods cited above for selecting and ordering, however, are quite different from those used in prior art search engines. For example, the well-known and highly-regarded Google Page-Rank approach weighs and orders each result according to its relative popularity or relevance by counting the number of other pages that point to it. This is a relatively slow-changing criterion, though not quite static, as the Google servers are obliged to “crawl” the network capturing and analyzing every we page in the network. The ability to respond rapidly to changes in a result's relevance according to this criterion is limited by the pace at which the network crawl can take place; with the sheer size of the network this is clearly less than dynamic. In the present invention, on the other hand, local user feedback can be acted on immediately, and remote user feedback is delayed only by its propagation through the Directory Clearinghouse. An implementation of the present invention may choose to report transactions that affect presentation ordering in batches spaced at regular intervals in order to optimize the traffic posed by the transactions against the value of the changes, or to report each one immediately for processing in real time. This function is allocated to Distribution Handling module <b>1424</b>, which is responsible for interactions with the Directory Clearinghouse <b>1320</b> and, to the extent allowed within a particular implementation, other Directory Engines <b>1310</b>.

0120Display Server <b>1313</b> takes care of the user interface aspects of Directory Engine <b>1310</b>. In that capacity it presents instructions and options to users, accepts their requests for information, and in turn presents the listings that result from these requests. As the general environment for this system is the modern Internet, web-based technology may be suitably applied. Therefore, the sole module of Display Server <b>1313</b> is a Standard Web Server <b>1430</b>, appropriately programmed with the specific attributes required to present and accept as described above. Because this technology is quite flexible, as is well-known to those skilled in the art, the specific style of presentation may be easily varied to suit the business, cultural, or other needs of the Directory Engine's operator.

0121In a preferred embodiment, Directory Engine <b>1310</b> is designed to operate as a network server. Its components are therefore housed in a specific Programmable Computing Platform <b>1401</b>. Platform <b>1401</b> is chosen to provide highly reliable operation and flexible scalability. Candidates satisfying such requirements are well-known to those skilled in the art, and are available from major vendors such as SUN, HP, Motorola, Intel, and many others. Platform <b>1401</b> also includes a Communication Interface <b>1402</b> for connecting to a network. This is typically implemented using two or more standard Ethernet links, which are well known to those skilled in the art. Additionally, Platform <b>1401</b> provides an Information Storage medium <b>1403</b> for holding data required by the functional components, including in particular configuration data such as Clearinghouse and Registry addresses, and listing data. This is typically implemented as a magnetic “hard disk” module. Platform <b>1401</b> and its subsystems are preferably implemented using standard components that are commonly available and well known to those skilled in the art.

0122Additional detail of Directory Clearinghouse <b>1320</b> can be seen in <figref idref="DRAWINGS">FIG. 15</figref>. Its two primary components, Distribution Processor <b>1321</b> and Account Management <b>1322</b> are shown with their respective modules. Within Distribution Processor <b>1321</b> are Transaction Forwarding module <b>1511</b> and Global Listing Database <b>1512</b>. Transaction Forwarding module <b>1511</b> is responsible for accepting attribute transactions on individual listings or groups of listings, from a Directory Engine <b>1310</b>, and forwarding these transactions to other Directory Engines <b>1310</b>. At the same time, each transaction is reflected in the Global Listing Database <b>1512</b> so that a consistent view of the data used in presentation ordering can be maintained and, if necessary restored to Directory Engines that lose it for any reason. Note that Global Listing Database <b>1512</b> may or may not store the actual listings themselves. A profile of the listing will generally suffice, so for reasons of storage economy and bandwidth optimization the detailed listing data may be omitted. Account Management component <b>1322</b> features a Peer Database module <b>1521</b>. Its role is to track the business relationships between the operator of the Clearinghouse and the various operators of Directory Engines. Peer Database <b>1521</b> may also track business relationships among operators of Directory Engines to the extent that details of those relationships affect the process of clearing transactions and distributing listings. Many different kinds of business relationship and money flow are conceivable; both Peer Database <b>1521</b> and Transaction Forwarding module <b>1511</b> are intended to provide a flexible platform to support a variety of approaches. As with other elements previously described, Directory Clearinghouse <b>1320</b> is generally operated as a network server. Its components are therefore housed in a specific Programmable Computing Platform <b>1501</b>, which is similar in structure and purpose to Platform <b>1401</b> as previously described.

0123<figref idref="DRAWINGS">FIGS. 16 and 17</figref> depict procedures used by the Dynamic Business Directory System <b>1300</b> to offer mediated communication between users and advertisers. First, in <figref idref="DRAWINGS">FIG. 16</figref> we find a process whereby a user may make an inquiry to an advertiser, and receive a response without having revealed the user's address to the advertiser. This is analogous to looking up a business in a telephone directory and calling to ask a question, such as the price of a particular item or whether it is in stock. The caller making the inquiry generally does not provide a name, nor does the advertising business generally capture the caller's phone number for future use. Similarly, in the present invention the user sending the inquiry sends it through the Directory Engine, which by the nature of Spam Prevention System <b>100</b> can assure the advertiser that the inquiring user is valid without revealing that user's address. The advertiser may answer the inquiry using the same mechanism, thereby completing the cycle. This process is termed here an interactive mediated communication. <figref idref="DRAWINGS">FIG. 17</figref> then depicts the process whereby a user may subscribe to advertising bulletins offered by a particular advertiser. Again, the user's addresses are not revealed to the advertiser in order to maintain user privacy and remove the temptation to provide the address to other advertisers for direct contact that may not be desired by the user (which would be spam). The advertiser sends the bulletin to the Directory Engine instead, which in turn forwards it to the users who have requested it. Again, by the nature of Spam Prevention System <b>100</b>, the various participants are known to be valid, verifiable entities. Therefore, should any abuse occur the abuser can be known and appropriate action may be taken.

0124The interactive mediated communication process shown in <figref idref="DRAWINGS">FIG. 16</figref> begins at step <b>1601</b> with the user logging in at the Website <b>321</b> of the appropriate Registry <b>120</b>. Numerous technologies exist for authenticating the user upon attempting to log in, including the ubiquitous username and password which may be considered as minimal. In addition, since Spam Prevention System <b>100</b> has provided a cryptographic identity certificate to each user who completes Registration, that certificate may be used for login authentication at this point. The protocols for taking advantage of this certificate are well-known to those skilled in the art, though they have been used only rarely in prior art systems because those systems do not have the thorough certificate distribution capabilities of Spam Prevention System <b>100</b>. Note also that, in an alternate embodiment, the user login may be implicitly derived from a mail server or access server to which the user authenticates for other reasons, thereby avoiding the need for a separate explicit login visible to the user. The Registry authenticates the user in step <b>1602</b>, and hands off the web session to the affiliated Directory Engine <b>1310</b>. The user's identity and authentication parameters, along with account information that may be pertinent to the services provided by Directory Engine <b>1310</b>, such as advertiser bulletin subscriptions or other advertising-related preferences, are passed to it in step <b>1603</b>. In step <b>1604</b>, the Directory Engine then presents to the user a portal page that includes search options used to choose listings the user desires to view. The format of this presentation may vary from operator to operator, but in general it would be similar to an internet search engine or online “yellow pages” directory.

0125At step <b>1605</b>, then, the user enters parameters for the search, such as a business category, a geographical region, a quality rating, or other criteria as may be made available by the Directory Engine's operator. These parameters are conveyed to Directory Engine <b>1310</b> in step <b>1606</b>, and in step <b>1607</b> it selects the matching listings and orders them for presentation according to the relative values of their order-affecting attributes. These may include the total number of viewings for each listing by users in this and other Directory Engines, the number of users subscribed to bulletins from each advertiser, the feedback ratings provided by users who have previously viewed these listings, and others that may be added to the system over its life. Thus ordered, the selected listings are presented to the requesting user in step <b>1608</b>.

0126If appropriate to the user's needs, at step <b>1609</b> the user may select one or more listings in order to make inquiries to their advertisers. Upon making such a selection, at step <b>1610</b> the user will be able to compose and send the inquiry as an ordinary electronic message via the user's accustomed messaging software, which may be a Webmail Proxy <b>324</b> provided by Registry <b>120</b>. The inquiry is addressed to the Directory Engine <b>1310</b>'s ArmorPost Agent Client <b>110</b>, with the advertiser's identity encoded in the address used. For example, if the advertiser to whom the inquiry is directed is Joe's Garage, which uses the domain name joesgarage.biz, and the Directory Engine is provided by Barking Pumpkin Records on the domain name barkingpumpkin.com, the inquiry may be addressed to joesgarage.biz@barkingpumpkin.com. This message is transmitted in step <b>1611</b> to Directory Engine <b>1310</b>, which in turn saves the inquirer's address, generates a new sender address specific to this inquiry but not revelatory of the inquirer's address, changes the recipient's address to the one specified in the listing data for the intended advertiser, and forwards the inquiry to the advertiser at that address. If the inquiring user's address is frank@barkingpumpkin.com, that address would be stored and replaced with, for example, inquiry42@barkingpumpkin.com in the subsequent message, while the recipient might become inquiries@joesgarage.biz. This transformed message is shown in transit to the advertiser's Lister Standard Client <b>130</b> in step <b>1613</b>.

0127Upon receipt of the inquiry, the advertiser at step <b>1614</b> may reply to the message, thereby creating another message containing the answer to the inquiry. This message goes back in step <b>1615</b> to the Directory Engine <b>1310</b>, which retranslates the reply address to the original user's address in step <b>1616</b>, and relays the answer message to the original sender in step <b>1617</b>. The process concludes in step <b>1618</b> when the user receives the advertiser's response.

0128Note that throughout this procedure, the participants rely upon one another's addresses to be valid. This is accomplished through the construction of Dynamic Business Directory System <b>1300</b> on the Spam Prevention System <b>100</b>, which provides the necessary assurance. Note further that, though not shown, it is also possible to overlay the Dynamic Business Directory System on the Private Email System of ArmorPost so that mediated communications may also be carried in complete privacy as appropriate.

0129<figref idref="DRAWINGS">FIG. 17</figref> depicts subscription to and reception of mediated advertising bulletins. The first few steps, <b>1701</b>-<b>1708</b>, are substantially identical to the opening steps <b>1601</b>-<b>1608</b> of <figref idref="DRAWINGS">FIG. 16</figref>; in both, a user logs in at the appropriate Registry <b>120</b>, enters search parameters, and is presented with an ordered set of listings that match those parameters. At step <b>1709</b>, the user decides that one or more of the listings is appealing, and chooses to register for additional information the advertiser may provide such as, for example, a periodic or occasional announcement of bargain prices. The bulletin request is conveyed in step <b>1710</b> to Directory Engine <b>1310</b>, which in step <b>1711</b> saves the user's address as a recipient of future bulletins from the advertiser corresponding to the selected listing. Note that, if the listing is not local to this Directory Engine <b>1310</b>, the act of subscribing a user to the bulletins of this advertiser is a state change that must be propagated to the Directory Engine <b>1310</b> at which the listing originates. Refer to <figref idref="DRAWINGS">FIG. 18</figref> for details of that procedure.

0130At some later time, an advertiser with a listing in Directory Engine <b>1310</b> composes and sends a bulletin at step <b>1712</b>, using the messaging capabilities of Spam Prevention System <b>100</b>. This message, shown in transit at step <b>1713</b>, is sent to the Directory Engine at an address reserved for such bulletins. Directory Engine <b>1310</b> receives the message and, in step <b>1714</b>, retrieves the list of addresses for users who are subscribed to receive such bulletins from this particular advertiser. Note that it is possible to have several different kinds of bulletins, and a user may have subscribed to some kinds but not others from this advertiser. It is also possible that a user may have subscribed to all or certain kinds of bulletin from all advertisers of a particular category. Each of these possible combinations is checked to form the list of users who should receive this particular bulletin. Note further that users in other Directory Engines <b>1310</b> may have subscribed to these bulletins; those users are not known here, but their Directory Engines are, the current one having been informed of subscriptions as noted in step <b>1711</b>. In step <b>1715</b>, then, Directory Engine <b>1310</b> sends a copy of the bulletin to each of these users and remote Directory Engines; the copy for the specific user in this scenario is shown in transit at step <b>1716</b>, and being received in step <b>1717</b>.

0131As users view listings, make inquiries of advertisers, subscribe to bulletins from advertisers, and provide feedback on advertisers and their listings (not depicted or described further here, as the concept and technology are reasonably well known among those skilled in the art), Directory Engine <b>1310</b> is counting these transactions so that they may be used in determining each corresponding listing's presentation order as described previously, noting as well which transactions affect local listings and which affect remote listings. As advertisers join the service and add listings, or as they leave the service and delete listings, and as they make changes to their listings, these transactions, too, are recorded in Directory Engine <b>1310</b>. Dynamic Business Directory System <b>1300</b> is a distributed, cooperative system in which every Directory Engine <b>1300</b> may present listings to its users that all Directory Engines <b>1300</b> have collected. The transactions that affect these listings, therefore, are propagated around the network as they occur. As previously noted, this may take place immediately upon completion of each transaction, or periodically in batches. Either way, <figref idref="DRAWINGS">FIG. 18</figref> depicts a propagation procedure.

0132Beginning at either step <b>1801</b> or step <b>1802</b>, a user or an advertiser takes action on a listing that is in step <b>1803</b> conveyed to the corresponding Directory Engine <b>1310</b>. For a user, such action may include subscribing to a bulletin, sending an inquiry, or even simply viewing a listing; in short, any action that may affect the value of a listing. For a lister, such action may include creating, deleting, or changing any attribute of a listing so that its state is affected. The Directory Engine in step <b>1804</b> performs the client's requested action, and in step <b>1805</b> adjusts the stored attributes of the corresponding listing or listings accordingly. After these local steps are taken, the transaction details are then formatted for propagation through the network in step <b>1806</b>, and sent to Directory Clearinghouse <b>1320</b>. This information is shown in transit as a Listing Attribute Change Notice in step <b>1807</b>. The Clearinghouse <b>1320</b> receives the Change Notice and records it in Global Listing Database <b>1512</b> in step <b>1808</b>. Note that if the change is to the content of the listing, the details of the change may be ignored by the Clearinghouse. Now at step <b>1809</b> Directory Clearinghouse <b>1320</b> forwards the Change Notice to other Directory Engines <b>1310</b> in the network, as listed in Peer Database <b>1521</b>. Step <b>1810</b> shows the Listing Attribute Change Notice in transit to another Directory Engine, which receives it and records the change in step <b>1811</b>. Care is taken when recording propagated changes not to include those changes in the next Change Notice sent out by the receiving Directory Engine, so that only the changes caused by its own users are sent out by any particular Directory Engine. Note also that the Directory Engine <b>1310</b> at which a listing originates may take additional action on receipt of a Change Notice regarding that listing; for example, certain transactions may be considered billable events that result in collecting money from the corresponding advertiser. Also, as previously mentioned, capacity concerns may drive an implementation of Dynamic Business Directory System <b>1300</b> to bypass Clearinghouse <b>1320</b> for most or all transactions, in which embodiment this procedure would use a series of direct exchanges to enmesh the data among all Directory Engines <b>1310</b>.

0133<figref idref="DRAWINGS">FIG. 19</figref> depicts Multimedia Spam Prevention System <b>1900</b>, which is similar to Messaging Spam Prevention System <b>100</b> in many respects, and rests on many of the same principles, but is designed to support authenticated multimedia session establishment rather than authenticated messaging. End-to-End Multimedia Signalling Infrastructure <b>1901</b> represents the multimedia signalling backbone to which the Spam Prevention capability is added. This Infrastructure can be any system that allows users or automatic programs to establish multimedia sessions with one another. It is preferably a Voice Over Internet Protocol (VoIP) or videoconferencing service built around the Internet-standard Session Initiation Protocol (SIP), but may also be implemented on the International Telecommunications Union (ITU) H.323 suite of standards. In either case, the standard network topology features user terminals which exchange media streams directly with one another, supported by signalling servers which handle user terminal discovery and session negotiation. It is in the signalling transactions where the potential for multimedia spam appears and can be prevented, because end to end media streams may only exist in the context of negotiated signalling sessions. The techniques applicable to messaging previously described are therefore generally applicable to multimedia signalling. Note that in the remainder of this disclosure, only the signalling protocols, procedures, and network topology are addressed. Media streams and the network topology supporting them are neither shown nor discussed, and no constraints on media stream connectivity are implied by the constraints described on signalling connectivity.

0134As in System <b>100</b>, Packet Network <b>102</b> forms the foundation for communication among elements of System <b>1900</b>, including End-to-End Multimedia Signalling Infrastructure <b>1901</b> and the signalling units exchanged thereon, but also supporting other non-signalling interactions such as web browsing. This element is preferably an Internet-based network, and may be the Internet itself, another network like it, or a composite of networks using multiple interworking technologies.

0135Connected to Packet Network <b>102</b> is at least one User Registry <b>120</b> (also referred to as simply Registry <b>120</b>); this is the same User Registry <b>120</b> that appears in System <b>100</b>, and has substantially the same functionality, omitting those functions that are specific to the messaging service provided in System <b>100</b>. In System <b>1900</b>, Registry <b>120</b> is primarily a repository and user interface for access to information about multimedia sessions offered but rejected by associated Multimedia AntiSpam Gateways <b>1950</b>. Users' interaction with System <b>1900</b> takes place via standard elements within a Protected Multimedia Signalling Infrastructure <b>1903</b>.

0136At least one Multimedia AntiSpam Gateway <b>1950</b> sits between End-to-End Multimedia Signalling Infrastructure <b>1901</b> and one or more Protected Multimedia Signalling Infrastructures <b>1903</b>. Using Interface <b>1953</b>, an AntiSpam Gateway <b>1950</b> receives signalling for sessions directed to users of a Protected Multimedia Signalling Infrastructure <b>1903</b> from End-to-End Multimedia Signalling Infrastructure <b>1901</b>, then decides whether the session signalling should be relayed into Protected Multimedia Signalling Infrastructure <b>1903</b> via Interface <b>1955</b>. Using Interface <b>1955</b>, an AntiSpam Gateway <b>1950</b> also receives session signalling sent by users of a Protected Multimedia Signalling Infrastructure <b>1903</b> to other users of End-to-End Multimedia Signalling Infrastructure <b>1901</b>. Note that Interfaces <b>1953</b> and <b>1955</b> are functionally equivalent to one another, using the same standard session signalling protocols (for example, SIP or H.225/H.245). For incoming calls, Information Security component <b>151</b> of AntiSpam Gateway <b>1950</b> (same function and therefore same label as in System <b>100</b>) makes its decision by verifying any authentication Token in the signalling unit, using the procedure described in the context of <figref idref="DRAWINGS">FIG. 6</figref> above. That procedure features communication between AntiSpam Gateway <b>1950</b> and one or more Registries <b>120</b>; Interface <b>154</b> to Packet Network <b>102</b> provides the necessary connectivity. Note that Interface <b>154</b> is functionally equivalent to Interface <b>124</b>, and is substantially the same as the element of the same name and label in System <b>100</b>. For outgoing calls, Information Security component <b>151</b> of AntiSpam Gateway <b>1950</b> authenticates the session initiator, then adds an authentication Token to each signalling unit. In both directions, if the authentication decision is affirmative, Signalling Relay component <b>1952</b> of AntiSpam Gateway <b>1950</b> effects the relaying of the signalling unit. In a preferred embodiment, Signalling Relay component <b>1952</b> is standard and commonly available VoIP switching software, such as an implementation of a SIP Proxy server.

0137As in System <b>100</b>, AntiSpam Gateways <b>1950</b> and User Registries <b>120</b> are related to one another in the sense that the users of a particular Protected Multimedia Signalling Infrastructure <b>1903</b>, served by one or more particular Multimedia AntiSpam Gateways <b>1950</b>, are registered in and provided account management services by a particular User Registry <b>120</b>. As previously described, the primary interaction supports database distribution for the purpose of offering users an interface mechanism for examining call history. Other Registry functionality related to Clients and non-Gateway Tokens in System <b>100</b> does not apply in System <b>1900</b>.

0138As in System <b>100</b>, Multimedia Spam Prevention System <b>1900</b> also uses Network Authorities <b>160</b> to control distribution of cryptographic key certificates. The functionality of a Network Authority <b>160</b> is not service-specific, so the same ones are used in both systems.

0139Further detail on Multimedia AntiSpam Gateway <b>1950</b> is shown in <figref idref="DRAWINGS">FIG. 20</figref>. Information Security component <b>151</b> is substantially identical to Information Security component <b>151</b> in Messaging AntiSpam Gateway <b>150</b>, and performs the same procedures as described previously. Similarly, Database Distribution module <b>254</b> is substantially identical here as well, except that it is used in Signalling Relay component <b>1952</b> rather than Messaging Relay component <b>152</b>. Here, it is used to convey information about call history, particularly rejected calls. Similar to the way traffic measurements are used in Messaging Spam Prevention System <b>100</b>, this call history data is used here for session rejection based on traffic levels.

0140Within Information Security component <b>151</b>, Token Handling module <b>250</b> is responsible for detecting authentication Tokens in incoming signalling units, and placing authentication Tokens in outgoing signalling units, according to the various conventions for Token inclusion described in the context of <figref idref="DRAWINGS">FIG. 4</figref>. Token Creation module <b>251</b> is responsible for generating Tokens as needed for outgoing signalling units, according to the procedures described in the context of <figref idref="DRAWINGS">FIG. 4</figref>. If a Token is present in an incoming signalling unit, Token Verification module <b>252</b> is responsible for establishing its authenticity according to the procedures described in the context of <figref idref="DRAWINGS">FIG. 6</figref>.

0141If an authentication Token is verified successfully, the signalling unit in which it arrived can be relayed to its recipient or recipients in Protected Multimedia Signalling Infrastructure <b>1903</b>. If an authentication Token is created successfully, the signalling unit into which it is placed can be relayed to its recipient or recipients in End-to-End Multimedia Signalling Infrastructure <b>1901</b>. Signalling Relay component <b>1952</b> is responsible for this activity. In a preferred embodiment the main relaying function may be implemented as any of several commonly available VoIP signalling (SIP Proxy) application programs, such as the popular sipX suite. This embodiment is shown in <figref idref="DRAWINGS">FIG. 20</figref> as Standard VoIP Server module <b>2053</b>. Signalling Relay component <b>1952</b> also encompasses Database Distribution module <b>254</b>, previously described.

0142In a preferred embodiment, Multimedia AntiSpam Gateway <b>1950</b> is designed to operate as a network element that permanently serves a particular Protected Multimedia Signalling Infrastructure <b>1903</b>. Its components are therefore housed in a specific Programmable Computing Platform <b>2001</b>. Platform <b>2001</b> is chosen to provide highly reliable operation and flexible scalability. Candidates satisfying such requirements are well-known to those skilled in the art, and are available from major vendors such as SUN, HP, Motorola, Intel, and many others. Platform <b>2001</b> also includes a Communication Interface <b>2002</b> for connecting to a network. This is typically implemented using two or more standard Ethernet links, which are well known to those skilled in the art. Additionally, Platform <b>2001</b> provides an Information Storage medium <b>2003</b> for holding data required by components Information Security <b>151</b> and Signalling Relay <b>1952</b>, including configuration data such as call routing and Token-verification routing information, and user data distributed to Database Distribution module <b>254</b>. This is typically implemented as a magnetic “hard disk” module. Platform <b>2001</b> and its subsystems are preferably implemented using standard components that are commonly available and well known to those skilled in the art.

0143<figref idref="DRAWINGS">FIG. 21</figref> depicts the Setup stage of a multimedia session establishment transaction. A separate Gateway is shown for each of calling and called user, but the scenario also applies if both are served by the same Gateway. The scenario begins in step <b>2101</b> with the caller composing and sending a Setup signalling unit to establish a new session. It traverses the sending service provider's infrastructure in step <b>2102</b>, arriving at the caller's AntiSpam Gateway <b>1950</b>. Step <b>2103</b> shows the calling Gateway authenticating the caller; note that this may be implemented in a cooperative fashion with the remainder of the caller's service provider network infrastructure, and generally uses authentication techniques that are well known by those skilled in the art. In step <b>2104</b> the session is counted against the caller's traffic allocation. This is a significant attribute of the present invention. Prior art systems generally take the step of authenticating the caller, but do not prevent callers from generating excessive traffic. Spam tends to be sent in very large quantities; enforcing a traffic limit of, for example, 50 sessions per day for each user can prevent a great deal of spam traffic. Session counting is critical in preventing spam: without it, an automatic process would be able to initiate countless sessions that are all authenticated. The session counting is intended to limit traffic for each caller to a rate that is both humanly possible and insufficient for spammers' purposes. If the session would cause the caller to exceed the allotted traffic volume, it is dropped or rejected. Traffic counts may also be made available to calling users through the appropriate Registry <b>120</b> and its External Website module <b>321</b>. Excessive traffic may indicate the presence of a zombie infection, which may otherwise go undetected.

0144If the Setup is allowed to proceed, at step <b>2105</b> the Gateway decides whether encryption is required, either on the Token to be generated, on the signal relay transaction to come, or both. If so, and no encryption key certificate is already known for the destination Gateway, an Introduction is requested by sending an Introduction Request message, Step <b>2106</b>, to the superior Network Authority <b>160</b> for this Gateway <b>1950</b>. At Step <b>2107</b>, Authority <b>160</b> retrieves the destination Gateway's certificate, either from its own database or by recursively requesting Introduction via higher level Authorities, depending on whether it is the Authority for the destination Gateway or not; for more detail on this procedure refer to the description of <figref idref="DRAWINGS">FIG. 22</figref>. The certificate is returned to the sending Gateway in Step <b>2108</b>, the Introduction Response message.

0145At Step <b>2109</b>, a Gateway Token <b>401</b>, <b>405</b>, or <b>406</b> is generated, depending on the Gateway operator's preferences as previously described, and added to the signalling unit as a header. In step <b>2110</b> the signal is relayed to the recipient's service provider. Step <b>2111</b> depicts the signal, with its Gateway Token, in transit between the two service providers' networks. This transfer operation may be encrypted or unencrypted, depending on Gateway operators' preferences and, optionally, per-user configuration data. If encryption is to be applied, the receiving Gateway's certificate retrieved during Introduction, and the sending Gateway's certificate, are used in the standard way by the Transport Layer Security (TLS) protocol, which is well known to those skilled in the art.

0146The Setup signal arrives at the AntiSpam Gateway <b>1950</b> protecting the called user's service provider's network, and at step <b>2112</b>, the incoming signal is scanned for the presence of an authentication Token. Since in this scenario one was placed in the message by the calling AntiSpam Gateway <b>1950</b>, it will be detected. The alternative scenario, in which no Token would be detected, is not shown as it represents standard behavior; a configuration option in the called Gateway may allow an operator to choose to reject all Tokenless (unauthenticated) sessions if desired. To verify the Token, a certificate noting the public key of the calling Gateway is required. If the called Gateway has previously been introduced to the calling Gateway, this certificate may be found in a local memory buffer that is used to retain introduction data. Otherwise, at step <b>2113</b> an Introduction is requested. Step <b>2114</b> shows this Introduction Request in transit to the superior Authority <b>160</b>; the request may be forwarded up the hierarchy as far as necessary, even to the Root Authority. The Authority <b>160</b> at which the calling Gateway <b>1950</b> is known retrieves its certificate in step <b>2115</b>, and sends it back to the called Gateway <b>1950</b> that requested it in step <b>2116</b>. For more detail on the Introduction protocol, refer to the description of <figref idref="DRAWINGS">FIG. 22</figref>. Back at the called AntiSpam Gateway <b>1950</b>, with the certificate for the calling AntiSpam Gateway <b>1950</b> now available, the Gateway Token may be verified in step <b>2117</b>, as previously described in Procedure <b>600</b>. At step <b>2118</b>, if the verification fails, the session may be dropped because its initiator is inauthentic. Alternatively, the session may be allowed to proceed after adding an indication that the caller is suspect. The called user's terminal may interpret this indication to produce a distinctive ringing or other alternate alerting signal to the user. Called Gateway <b>1950</b> may also record the suspect caller's identity and make it available for the called user to examine, possibly to accept future sessions offered without Token. This behavior is directly analogous to the “gray list” and “white list” processing previously described for the Messaging Antispam Gateway <b>150</b>. At step <b>2119</b>, if the verification passes, the Setup signal may be relayed to the called user. Prior to relaying, however, the Gateway Token from the calling Gateway <b>1950</b> is removed to reduce the likelihood of a replay or known-plaintext attack on the keys caused by unnecessary exposure of Tokens. Finally, at step <b>2120</b> the Setup signal, back in its original form, moves to the multimedia signalling client of the called user, which in step <b>2121</b> receives and processes it. Note that additional signals are usually needed to complete the session establishment beyond this initial signal. These are not shown, as their handling can be inferred by those skilled in the art. It will either be substantially identical to the Setup signal's handling, in either the reverse direction or the same direction depending on the direction of the signal's flow, or it will simply be the standard message handling without the processing described here, depending on whether the operators of Protected Multimedia Signalling Infrastructures <b>1903</b> desire authentication of every signal within the establishment transaction or only the initial one.

0147<figref idref="DRAWINGS">FIG. 22</figref> provides a schematic summary of various topologies in the arrangement of Network Authorities <b>160</b>, User Registries <b>120</b>, and AntiSpam Gateways <b>150</b> or <b>1950</b>, as they may relate to one another in Spam Prevention Systems <b>100</b> and <b>1900</b>.

0148This figure depicts several distinct organizational roles a Network Authority <b>160</b> or User Registry <b>120</b> might play in the network, along with three distinct inter-element relationships. The organizational roles represent different sets of constraints on certain significant behaviors, which make each particular role suitable for certain types of organization. The relationships pertain to how these elements interact with one another to form networks. Note that these relationships represent meaningful interactions, not direct communication links. All communication takes place via Packet Network <b>102</b>. Also note that the various forms of Client in System <b>100</b>, and the Protected Infrastructures <b>103</b> and <b>1903</b> of Systems <b>100</b> and <b>1900</b> respectively, are not shown in this diagram but are instead implied.

0149The Authority Network's purpose is to facilitate trustworthy communication among its members. The Introduction process described in other paragraphs uses this network to distribute encryption/authentication certificates to communicating entities so that they can both authenticate one another and protect their communications with one another from other entities. This leads directly to the purpose of Relationship <b>2201</b>, which is between an entity (Gateway, Registry, or Authority) and an Authority which certifies the authenticity of the entity by signing its encryption/authentication certificate. In order for every entity to trust Tokens, Introductions, and encrypted message/signalling relay from every other entity, there exists a network of certificate authenticity in which every Agent, Gateway, Registry, and Authority participates. This network is depicted in <figref idref="DRAWINGS">FIG. 22</figref> as a directed graph, with the certification relationships flowing generally downward. Each Gateway has exactly one Relationship <b>2201</b> superior, while an Authority or Registry may have multiple Relationship <b>2201</b> superiors and many Relationship <b>2201</b> inferiors. No peer Relationships <b>2201</b> may exist, as there is no meaning within a certification hierarchy for such peering. Thus the entities form a conventional Certificate Authority tree via their Relationships <b>2201</b> with one another. At the top of this tree is Root Authority <b>2200</b>, which acts as the root Certificate Authority for the entire network. Conventional Public-Key Infrastructure technologies and techniques, well-known to those skilled in the art, are used to form this tree.

0150One or more Alternate Root Authorities <b>2240</b> may also exist. Note how combination Registry/Authority <b>2230</b> has two Relationship <b>2201</b> superiors. This indicates that an element may actually be certified by multiple Authorities. One way to use that feature might be to arrange for a Gateway, or set of Gateways through a common Authority, to use multiple certificates and apply multiple Tokens on each message or signalling unit it authenticates. Each certificate might have different assertions associated with it, requiring different levels or types of scrutiny and verification to obtain. For example, a certificate signed by Root Authority <b>2200</b> might guarantee good behavior as a messaging or multimedia service provider, while one signed by Alternate Root Authority <b>2240</b> might certify specific off-network business practices. Thus, multi-Authority capability may support multiple reputation services that certify different aspects or attributes of the organizations operating Gateways, Registries, and Authorities. Another usage of this capability might be to provide for redundancy. For example, if a particular Authority were to go out of business or suffer a network failure, a service provider with a Registry could protect its own ability to continue operating by having established a Relationship <b>2201</b> with an additional Authority.

0151Public Authority <b>2210</b> and Private Authority <b>2220</b> represent Authorities <b>160</b> that are operated by different classes of organization, and which have different constraints on their service domain. A Public Authority is permitted to serve any domain (user, enterprise, ISP, etc.) without constraints, while a Private Authority is permitted to serve only those Authorities, Registries, and Gateways that are within its domain namespace. Public combination Registry/Authority <b>2211</b> and Private Registry <b>2221</b> exhibit similar restraints on their ability to Invite users who may or may not be registered in another Registry (see <figref idref="DRAWINGS">FIG. 9</figref>, <figref idref="DRAWINGS">FIG. 12</figref>, and their descriptions). For example, a Private Registry in a particular Internet Domain Name would only serve Users whose addresses are also in that same Internet Domain Name. Typically, a Public node would be operated by a major ISP or carrier, while a Private node would be operated by an Enterprise or small ISP. For example, Public Authority <b>2210</b> might belong to a major ISP serving numerous users and enterprises in multiple domains, while Private Registry <b>2212</b>, which subtends it in the CA hierarchy, might be a particular Enterprise that is a customer of that ISP but operates its own Registry for security reasons. As another example, Private Authority <b>2220</b> might belong to a very large enterprise that requires multiple Registries and Gateways for effective coverage of its network. Note that Root Authority <b>2200</b> is a Public Authority; a particular Alternate Root Authority <b>2240</b> may be Public or Private. Additional constraints are possible as well. For example, during Introduction as previously described, a particular Authority may choose to ignore or reject queries from arbitrary entities, accepting them only from a set of entities with whose operators the Authority's operators have a pre-existing business relationship. Such a constraint set would create something akin to a closed user group, reflecting in the technology a particular coalition that exists in the business. Gateways, Registries, and Authorities may participate in zero, one, or more such constraint sets. Constraint sets may also be either static or dynamic.

0152Also depicted in <figref idref="DRAWINGS">FIG. 22</figref> is the relationship among a Registry <b>120</b> and those Gateways <b>150</b>/<b>1950</b> that are bound to it as protectors of a particular Protected Infrastructure <b>103</b>/<b>1903</b>. These entities share data via their respective Database Distribution modules <b>254</b> (Gateway) and <b>323</b> (Registry). This relationship has been described previously, but is shown here as Relationship <b>2202</b> for completeness. Note how Gateways <b>2231</b>, <b>2232</b>, and <b>2213</b> have both <b>2201</b> and <b>2202</b> Relationships to combined Registry/Authority nodes <b>2231</b> and <b>2211</b>, while Gateway <b>2222</b> is linked by Relationship <b>2201</b> to Authority <b>2220</b> and separately by Relationship <b>2202</b> to Registry <b>2221</b>. This shows how the Registry and Authority elements may be combined with one another or left distinct depending on operator convenience. Also note that Registry <b>2212</b> is shown with no Gateways in its purview. Such a Registry would support only Agents, which are not shown here.

0153While the Relationship <b>2201</b> hierarchy is appropriate for certificate authentication, it is not necessarily optimal for message flow and multimedia signalling flow. Relationship <b>2204</b> represents the opportunity for direct inter-Gateway flow of Tokens attached to messages and multimedia signalling, as well as direct inter-Gateway encrypted relays. For such traffic to flow, the entities involved should have exchanged encryption/authentication certificates with one another so that information privacy and authenticity are ensured. These certificates are governed by the certificate authenticity hierarchy formed of Relationships <b>2201</b>, so every participating node may be assured of the others by validating the certificates up to a common Authority (if necessary, as high as the Root Authority <b>2200</b>). The certificate exchange process is called Introduction, and its dynamic form was briefly described in the context of <figref idref="DRAWINGS">FIG. 7</figref> and others. Similarly, Token Verification transactions and even Introduction itself are not necessarily optimally conveyed only between Relationship <b>2201</b> pairs. Relationship <b>2203</b> represents the opportunity for direct inter-node communication for Token Verification and Introduction. Initial Relationships <b>2203</b> are automatically formed in parallel with every Relationship <b>2201</b> as a corollary to the initial certificate authentication process, as well as in parallel with every Relationship <b>2202</b> as a corollary to the establishment of a Registry and its Gateways. Additional Relationships <b>2203</b> and <b>2204</b> form through Introduction as demanded by the traffic flow, and may appear anywhere. Any node may be Introduced to any other node, forming a traffic mesh according to the demand. Thus an optimal network is formed dynamically.

0154Introduction is the process of acquiring an encryption/authentication certificate for another node at a node that needs it. Relationships <b>2203</b>/<b>2204</b> (they're really the same thing) are established through this process. Introduction takes one of three forms. The first, Manual Introduction, takes place through configuration procedures upon installation of a node. It is normally used only when establishing a Gateway's relationship to a Registry that is not also an Authority. Manual configuration techniques are well-known to those skilled in the art, and are not further detailed here. The second Introduction form is called Registration, and takes place as an automatic process when installing a Gateway, Registry, or Authority. This process is substantially the same as the ArmorPost Agent Registration process described in ArmorPost, and is not repeated here. The new node's administrator acts as the Agent's user in that procedure. The new node itself contains the registering Agent, while the pertinent Authority runs the Courier side of the procedure. Both of these Introduction forms provide the initial Relationship <b>2203</b> between a new node and its parent.

0155Dynamic Introductions, depicted in brief in <figref idref="DRAWINGS">FIG. 7</figref> and in detail in <figref idref="DRAWINGS">FIG. 23</figref>, are the third type. They occur after the initial Relationships <b>2203</b> are established, and are usually simply called Introductions without the qualifier. These Introductions use an inter-node query protocol to retrieve a certificate from the database of its issuer. That is, rather than trusting a node to share its correct certificate, the certificate is obtained from its Authority instead. Further, Dynamic Introduction can take place only via existing Relationships <b>2203</b>, so the first query from a node goes to its own Authority, which is initially the only one it trusts. As trusted nodes provide Introductions, additional nodes become trusted, and over time an optimal network of Relationships <b>2203</b> forms on demand.

0156In a preferred embodiment, each Authority keeps the certificates of its subordinate Authorities, Registries, and Gateways in a domain name server (refer to the description of <figref idref="DRAWINGS">FIG. 24</figref> for structural detail of an Authority). The naming hierarchy is separate from the Internet's Domain Name hierarchy for hostname to IP address translation. This one is rooted in the Root Authority <b>2200</b>, used only for representing the Authority Network, and not exposed publicly to Internet hosts outside the Authority Network. Note that a public form of a Gateway's Authority Network name, rooted in the public name of the Root Authority but providing the same information about placement in the Authority Network hierarchy, may in general be made available in the routing data for that Gateway's Protected Infrastructure <b>103</b>/<b>1903</b>, to provide for interoperability between End-to-End Infrastructure <b>101</b>/<b>1901</b> and the AntiSpam Gateway <b>150</b>/<b>1950</b>. For example, the MX record in DNS for a Protected Messaging Infrastructure <b>103</b> may name the public form of Messaging AntiSpam Gateway <b>150</b>'s Authority Network name so that other Gateways <b>150</b> can know that they are dealing with a Gateway.

0157Each Authority stores in its name server a record of subordinate Authorities, which are implemented in the preferred embodiment as ordinary sub-domain delegations, and certificates of subordinate nodes, which can use the standard CERT record. Additional hierarchies may exist as well, rooted in corresponding Alternate Root Authorities <b>2240</b>. The Introduction protocol itself is prefereably a secured implementation of the DNS query protocol. Security may be provided by IPSec or SSL tunneling between Introduced nodes, such that queries on this separate DNS hierarchy are only permitted over encrypted sessions from authenticated nodes via tunnels established by certificate exchange.

0158An example Dynamic Introduction sequence is depicted in <figref idref="DRAWINGS">FIG. 23</figref>. Suppose Registry <b>2212</b> requires Introduction to Registry <b>2221</b> (see <figref idref="DRAWINGS">FIG. 22</figref> for the entities involved in this example) in order to request verification of a Token issued by one of its Agents (see <figref idref="DRAWINGS">FIG. 11</figref> for the overall scenario). Having made this determination in Step <b>2301</b>, Registry <b>2212</b> would in Step <b>2302</b> securely query Authority <b>2210</b> for the certificate of Registry <b>2221</b>'s Authority, Authority <b>2220</b>. Step <b>2303</b> shows the query in transit securely; as previously noted, well-known secure tunnel technologies such IPSec or SSL may be used here. At Step <b>2304</b>, if Authority <b>2210</b> also has not yet established a Relationship <b>2203</b> with Authority <b>2220</b>, it may in turn securely query Root Authority <b>2200</b> for that certificate via Step <b>2305</b>. Since in this example Authority <b>2220</b> is directly subordinate to Root Authority <b>2200</b>, the cert will be in its database, retrieved at Step <b>2306</b>, and returned in the response shown as Step <b>2307</b>. In the preferred embodiment this is a DNS query, so the result is cached for future use at Step <b>2308</b>, thus establishing half of a Relationship <b>2203</b> between Authorities <b>2210</b> and <b>2220</b>. Authority <b>2210</b> may then at Step <b>2309</b> return the certificate of Authority <b>2220</b> to Registry <b>2212</b> in the response shown as Step <b>2310</b>. Again, the result is cached at Step <b>2311</b>. Now, Registry <b>2212</b> can attempt at Step <b>2312</b> to query Authority <b>2220</b> for the certificate of Registry <b>2221</b>, using the secure query shown as Step <b>2313</b>. However, upon receiving the query Authority <b>2220</b> decides at Step <b>2314</b> that it should first authenticate Registry <b>2212</b>, so at Step <b>2315</b> it queries Root Authority <b>2200</b> for the certificate of Authority <b>2210</b> using the secure query shown as Step <b>2316</b>. Since in this example Authority <b>2210</b> is directly subordinate to Root Authority <b>2200</b>, the requested cert will be in its database, retrieved at Step <b>2317</b>, and returned in the response shown as Step <b>2318</b>. At Step <b>2319</b>, Authority <b>2220</b> caches the cert of Authority <b>2210</b> for future use. At Step <b>2320</b> Authority <b>2220</b> queries Authority <b>2210</b> for the certificate of Registry <b>2212</b>, using the secure query shown as Step <b>2321</b>. Since Authority <b>2210</b> already knows the certificate of Authority <b>2220</b> from its previous query, it can authenticate Authority <b>2220</b> at Step <b>2322</b>, retrieve the requested certificate from its database at Step <b>2323</b>, and provide it to the requester in the response shown as Step <b>2324</b>. Upon receiving and caching it at Step <b>2325</b>, Authority <b>2220</b> can authenticate the query from Registry <b>2212</b> at Step <b>2326</b>, and give it the certificate of Registry <b>2221</b> retrieved from its database in Step <b>2327</b>, using the response shown as Step <b>2328</b>. Now Registry <b>2212</b> can request the Token Verification from Registry <b>2221</b>, shown generically at Step <b>2329</b> and in transit at Step <b>2330</b>. However, at Step <b>2331</b> Registry <b>2221</b> should first authenticate Registry <b>2212</b>, and so at Step <b>2332</b> queries Authority <b>2220</b> for the appropriate certificate using the secure query shown as Step <b>2333</b>. Since the previous Introduction stages have populated caches everywhere, Authority <b>2220</b> can at Step <b>2334</b> retrieve the correct certificate from its database and return it to Registry <b>2221</b> in the response shown as Step <b>2335</b>. Now at Step <b>2336</b>, Registry <b>2221</b> can cache the received certificate, and at Step <b>2337</b> it can authenticate Registry <b>2212</b>. Finally, Step <b>2338</b> shows Registry <b>2221</b> handling the communication from Registry <b>2221</b>. This elaborate sequence establishes trust among all participating parties. Having been Introduced once, the sequence is not required for subsequent communications until cache expiry forces a repeat. Note that choosing cache lifetime is a matter for network engineering, and requires a balance between system performance and the risk of certificate revocation, a practice well known by those skilled in the art.

0159Detail of a Network Authority <b>160</b> can be found in <figref idref="DRAWINGS">FIG. 24</figref>. Structurally, it is substantially similar to a User Registry <b>120</b>. In particular, Information Security component <b>161</b> contains essentially the same modules as Information Security component <b>121</b> of Registry <b>120</b>, with Key Handling module <b>2411</b>, Message Handling module <b>2412</b>, Background Web Server <b>2413</b>, and Background Mail Server <b>2414</b> providing substantially the same functions as the like-named modules <b>311</b>, <b>312</b>, <b>313</b>, and <b>314</b> of Registry <b>120</b>; recall that those are in turn substantially the same as corresponding modules in Trusted Courier <b>120</b> of ArmorPost. This reflects the usage of the same Registration protocol in all three network elements; in the case of the Network Authority, it is registering Gateways, Registries, and other Authorities that are subordinate to it. Message Handling module <b>2412</b> is also charged here with securing inter-node communication that occurs during Introduction, as described above. Note also that the Registry's Account Management component is replaced here by the Authority's Introduction Management component <b>162</b>. This component is responsible for storing certificates of Registered subordinate nodes and sharing them during Introductions. It also maintains the hierarchy of subordinate nodes, particularly the delegations to subordinate Authorities. To that end, two different but related databases, and a database distribution module are provided. Subordinate Node Database module <b>2421</b> identifies subordinate nodes and delegation to subordinate Authorities. Certificate Database module <b>2422</b> securely stores issued certificates. Database Distribution module <b>2423</b> is responsible for serving those delegations and certificates in response to the Introduction protocol. In a preferred embodiment, this is an ordinary DNS server implementation, such as BIND or djbdns.

0160As usual, in a preferred embodiment Network Authority <b>160</b> is designed to operate as a network server. Its components are therefore housed in a specific Programmable Computing Platform <b>2401</b>. Platform <b>2401</b> is chosen to provide highly reliable operation and flexible scalability. Candidates satisfying such requirements are well-known to those skilled in the art, and are available from major vendors such as SUN, HP, Motorola, Intel, and many others. Platform <b>2401</b> also includes a Communication Interface <b>2402</b> for connecting to a network. This is typically implemented using two or more standard Ethernet links, which are well known to those skilled in the art. Additionally, Platform <b>2401</b> provides an Information Storage medium <b>2403</b> for holding data required by the functional components. This is typically implemented as a magnetic “hard disk” module. Platform <b>2401</b> and its subsystems are preferably implemented using standard components that are commonly available and well known to those skilled in the art.

0161While much of the foregoing text describes Registry <b>120</b> and Network Authority <b>160</b> as distinct elements, in many instances it may be appropriate to deploy them side by side. In particular, large and mid-sized service provider or enterprise networks with multiple Gateways are likely to want both, and combining them may provide sufficient performance economically. The structure of such an embodiment would be readily evident to those skilled in the art by combining the modules and components shown in <figref idref="DRAWINGS">FIG. 24</figref> and <figref idref="DRAWINGS">FIG. 3</figref>, and so is not shown separately.

0162<figref idref="DRAWINGS">FIG. 25</figref> depicts Application Layer Denial of Service (DoS) Prevention System <b>2500</b>. Several major elements make up this system. First, Packet Network <b>102</b> forms the foundation for all communication among elements. This element is preferably an Internet-based network, and may be the Internet itself, another network like it, or a composite of networks using multiple interworking technologies. Connected to Packet Network <b>102</b> is at least one Network Authority <b>160</b>. This entity is substantially the same, with substantially the same role, as the Network Authority <b>160</b> already described in previous paragraphs. Network Authority <b>160</b> attaches to Packet Network <b>102</b> via a packet transfer interface <b>164</b>, which may take any available form as is well known to those skilled in the art.

0163The applications contemplated for protection by the elements of System <b>2500</b> are traditionally provided by a variety of clients, servers, and network arrangements that are well known to those skilled in the art. These arrangements are represented in System <b>2500</b> by Unprotected Application Infrastructure <b>2504</b>, which in turn attaches to Packet Network <b>102</b> via a packet transfer interface <b>2544</b> that is substantially similar to other packet transfer interfaces already described. Included in Unprotected Infrastructure <b>2504</b> may be, for example, mail servers for messaging, SIP proxies for multimedia communications such as VoIP, and web servers for transaction-oriented services and hypertextual information services.

0164System <b>2500</b> includes one or more Protected Application Infrastructures <b>2503</b>, and one or more Secure Application Gateways <b>2550</b>, each pair of which is connected via a packet transfer interface <b>2555</b> that is substantially similar to other packet transfer interfaces already described. Protected Infrastructures <b>2503</b> comprise well-known clients, servers, and network arrangements for providing the contemplated applications, and may be substantially identical to Unprotected Infrastructure <b>2504</b>. They are, however, shown as separate entities because instead of attaching directly to Packet Network <b>102</b>, where Unprotected Infrastructure <b>2504</b> is exposed to both desirable and potentially damaging network traffic, each one is protected by a Secure Application Gateway <b>2550</b>, which provides mechanisms whereby its Protected Infrastructure <b>2503</b> handles only desirable traffic and is protected from Denial of Service attacks.

0165Each Secure Application Gateway <b>2550</b> attaches to Packet Network <b>102</b> via two distinct packet transfer interfaces <b>154</b> and <b>2554</b>. Though distinct from one another, they are substantially similar both to one another and to other packet transfer interfaces previously described, excepting obviously their network addresses. Interface <b>154</b> is intended to carry the packet traffic to which Protected Infrastructure <b>2503</b> would be exposed if it were unprotected; that is, standard network application traffic and malicious DoS traffic as would be experienced by Unprotected Infrastructure <b>2504</b> via interface <b>2544</b>. Interface <b>2554</b> is intended to carry only secured network application traffic among Protected Infrastructures <b>2503</b> via Gateways <b>2550</b>. However, in general interface <b>2554</b> will be presented with malicious traffic by nefarious entities in Packet Network <b>102</b>, just as interface <b>154</b> is. The aforementioned intent is therefore strictly enforced via the DoS-prevention methods described in the paragraphs which follow.

0166Secure Application Gateway <b>2550</b> comprises three primary modules, which are outlined here and described in detail below. Interface <b>154</b> attaches within Gateway <b>2550</b> to an Exposed Application Proxy module <b>2551</b>. This module presents to Packet Network <b>102</b> as if it were the corresponding application entity or entities in Protected Infrastructure <b>2503</b>. For example, if a Gateway <b>2550</b> is added to the network in front of an existing Infrastructure <b>2503</b>, it may use exactly the same network addresses as Infrastructure <b>2503</b> had been using. Thus, peer application infrastructures across Packet Network <b>102</b> may continue to interact with said Infrastructure <b>2503</b> without change. Similarly, interface <b>2555</b> attaches within Gateway <b>2550</b> to a Secured Application Proxy <b>2552</b>. This module presents to Protected Infrastructure <b>2503</b> as if it were Packet Network <b>102</b>, again allowing a Gateway <b>2550</b> to be added to the network in front of an existing Infrastructure <b>2503</b>, which in turn can continue interacting with peers across Packet Network <b>102</b> without change. Finally, interface <b>2554</b> attaches within Gateway <b>2550</b> to Information Security module <b>2553</b>, which is designed to provide encrypted communication with other Gateways <b>2550</b> and to ignore incoming packets that are not from other Gateways <b>2550</b>. These three modules interact with one another in restricted ways to ensure that traffic flowing through Information Security module <b>2553</b> is given priority over traffic flowing through Exposed Application Proxy <b>2551</b> when passing it back to Protected Infrastructure <b>2503</b> via Secured Application Proxy <b>2552</b>. These controlled interactions take place on interface <b>2556</b> between Secured Application Proxy <b>2552</b> and Exposed Application Proxy <b>2551</b>, and on interface <b>2557</b> between Secured Application Proxy <b>2552</b> and Information Security module <b>2553</b>. Note how Exposed Application Proxy <b>2551</b> and Information Security module <b>2553</b> do not interact directly; Secured Application Proxy <b>2552</b> controls the flow of traffic.

0167Further detail on Secure Application Gateway <b>2550</b> is found in <figref idref="DRAWINGS">FIG. 26</figref>. Gateway <b>2550</b> is designed to operate as a network element that permanently serves a particular Protected Application Infrastructure <b>2503</b>, so its functional modules operate in the context of a computing platform. In a preferred embodiment, two such platforms are used, so that the processing of protected traffic is not affected by the potential load from arbitrary traffic. Programmable Computing Platform A <b>2601</b> is assigned the arbitrary traffic handled by Exposed Application Proxy <b>2551</b>, while Programmable Computing Platform B <b>2604</b> handles the protected traffic running through Secured Application Proxy <b>2552</b> and Information Security module <b>2553</b>. Platforms <b>2601</b> and <b>2604</b> are chosen to provide highly reliable operation and flexible scalability, and are preferably integrated into a single package. They may be implemented as two or more general-purpose processors, or as a combination of general-purpose processors and specialized network processors depending on performance requirements at a particular installation. Candidates satisfying such requirements are well-known to those skilled in the art, and are available from many vendors. Each platform includes its own Data Storage and Communication Interface components as shown in the figure. Communication Interfaces <b>2602</b> and <b>2605</b> may be implemented using two or more standard Ethernet links, which are well known to those skilled in the art. Communication Interface <b>2605</b> may also include an Ethernet switch, another well-known technology, to facilitate the transfer of application signalling between Exposed Application Proxy <b>2551</b> and Protected Application Infrastructure <b>2503</b> as appropriate via interface <b>2556</b>. Data Storages <b>2603</b> and <b>2606</b> are typically implemented as magnetic “hard disk” modules, but may be implemented using any appropriate storage medium. Platforms <b>2601</b> and <b>2604</b>, and their components, are preferably implemented using standard products that are commonly available and well known to those skilled in the art.

0168Exposed Application Proxy <b>2551</b> comprises a Standard Application Proxy <b>2611</b> and a Traffic Governor <b>2612</b>. Standard Application Proxy <b>2611</b> provides the usual capabilities of such software, well known to those skilled in the art, as appropriate for the application being handled. For example, for the messaging application this would be an Internet-facing mail server (messaging transport agent, or MTA) whose job is to screen incoming mail and provide a controlled source for outgoing mail according to the needs of Protected Infrastructure <b>2503</b>. In the preferred embodiment this is a Messaging AntiSpam Gateway <b>150</b>, but other popular and well-known MTAs with typical features such as spam filtering and authentication may also be used. Similarly, for a multimedia application this could be an ordinary SIP Proxy, but the preferred embodiment is a Multimedia AntiSpam Gateway <b>1950</b>. Suitable well-known proxies are also available for other applications.

0169Traffic Governor <b>2612</b> serves to throttle the flow of arbitrary incoming traffic into Protected Infrastructure <b>2503</b>. It cooperates with Traffic Governor <b>2623</b> (described below) to ensure that incoming traffic allowed through by Standard Application Proxy <b>2611</b> is queued whenever necessary so that protected traffic flowing through Secured Application Proxy <b>2552</b> has precedence on interface <b>2555</b>. Any of several known mechanisms may be used to effect this flow control. In a preferred embodiment, Standard Application Proxy <b>2611</b> may be configured such that incoming messages are queued after being approved, and the queue is only transmitted on interface <b>2556</b> to Protected Infrastructure <b>2503</b> when explicitly commanded by Secured Application Proxy <b>2552</b>. The explicit command may be implemented using the SMTP ETRN protocol, or any other suitable mechanism. In an alternate embodiment, Secured Proxy <b>2552</b> may keep interface <b>2556</b>, through which arbitrary traffic must flow if it is to reach Protected Infrastructure <b>2503</b>, disabled except when such traffic is permitted. A combination of these two techniques may also be used. A predetermined schedule, a lack of protected traffic at any time, or some combination of these may be used to trigger the enabling of interface <b>2556</b> and/or the processing of the queue.

0170Secured Application Proxy <b>2552</b> comprises a Standard Application Proxy <b>2621</b>, a Traffic Distributor <b>2622</b>, and a Traffic Governor <b>2623</b>. Standard Application Proxy <b>2621</b> is similar to Standard Application Proxy <b>2611</b>, in that it draws upon existing or previously described technology. However, where Proxy <b>2611</b> provides screening of what may be considered “wild” incoming transactions against plainly malicious intent, Proxy <b>2621</b> instead screens outgoing transactions from Protected Infrastructure <b>2503</b>, ensuring, for example, that they do not exceed allowable per-user numbers or that they interact only with permitted correspondents. No screening is required on incoming messages here, because they are protected by Information Security module <b>2553</b>, both at this Gateway <b>2550</b> and its correspondent Gateways <b>2550</b>, as will be described later. Here again, in the preferred embodiment this is a Messaging AntiSpam Gateway <b>150</b> or Multimedia AntiSpam Gateway <b>1950</b>, or another suitable well-known proxy, according to the application being transacted.

0171Traffic Distributor <b>2622</b> exists to route transaction signalling among the various entities within Gateway <b>2550</b>. Incoming protected traffic arriving from Information Security module <b>2553</b> on interface <b>2557</b> is given to Proxy <b>2621</b> for processing, as is outgoing traffic from Protected Infrastructure <b>2503</b>. Incoming traffic already processed by Proxy <b>2621</b> is passed out interface <b>2555</b> to Protected Infrastructure <b>2503</b>. Outgoing traffic from Proxy <b>2621</b> is offered first to Information Security module <b>2553</b>, via interface <b>2557</b>, so that it may determine whether a particular destination is protected by another Gateway <b>2550</b>. If there is no Gateway <b>2550</b> at the other end, Traffic Distributor <b>2622</b> passes the traffic instead to Exposed Application Proxy <b>2551</b> via interface <b>2556</b> for transmission into Packet Network <b>102</b> via interface <b>154</b>.

0172Traffic Governor <b>2623</b> is the secure-side counterpart to Traffic Governor <b>2612</b>. Its job is to decide when the level of protected traffic is low enough that approved incoming arbitrary traffic can be released into Protected Infrastructure <b>2503</b>. As previously described, this decision may be based on a predetermined schedule, a lack of protected traffic at any time, or some combination of these. Lack of traffic may be detected by tracking the length of any traffic queues managed by Proxy <b>2621</b>, or by monitoring the bandwidth utilization on interface <b>2555</b>, or by any of several other means which are well known to those skilled in the art. Also as previously described, in a preferred embodiment the arbitrary traffic is commanded to be released using an explicit command via interface <b>2556</b>, or in an alternate embodiment Traffic Governor <b>2623</b> may keep interface <b>2556</b> disabled except when such traffic is permitted. A combination of these two techniques may also be used.

0173Information Security module <b>2553</b> provides the cryptographic functions required to protect outgoing application traffic and to guard Secured Application Proxy <b>2552</b> from “wild” incoming traffic. It comprises an Introduction component <b>2631</b>, a Port Randomizer <b>2632</b>, and a Tunneling component <b>2633</b>.

0174Introduction component <b>2631</b> manages the Introduction protocol, described in the context of <figref idref="DRAWINGS">FIG. 23</figref> above, by which Network Authorities <b>160</b> deliver cryptographic key certificates to Gateways <b>2550</b>. Key certificates are used for transaction data encryption, correspondent authentication, and transport layer port selection as described below. Note that, due to synchronization requirements driven by the needs of Port Randomizer <b>2632</b>, for System <b>2500</b> the Authority Network described in the context of <figref idref="DRAWINGS">FIG. 22</figref> above is enhanced, using standard capabilities well known to those skilled in the art, to provide Network Time Protocol services down through the tree. This way every Gateway <b>2550</b> is operating with the same view of the time.

0175Port Randomizer <b>2632</b> is responsible for dynamically selecting the incoming port to which Gateway <b>2550</b> listens for incoming protected traffic, as well as identifying the port at a destination Gateway <b>2550</b> to which outgoing protected traffic should be sent. The procedure Port Randomizer <b>2632</b> follows is described below in the context of <figref idref="DRAWINGS">FIG. 27</figref>. Because this process effectively blocks all incoming packets, of any application or protocol, which are not synchronized to the sequence chosen by Port Randomizer <b>2632</b>, it is in essence a firewall process. In an alternate embodiment, Port Randomizer <b>2632</b> may be duplicated in or delegated to a separate firewall router network element, such as are well known to those skilled in the art, thereby further improving the protection provided by the total network beyond that offered by Gateway <b>2550</b> alone.

0176Finally, Tunneling component <b>2633</b> provides encryption and authentication of application data flowing between instances of Gateway <b>2550</b>. It uses the cryptographic key certificates provided by Introduction component <b>2631</b> in standard fashion, well known to those skilled in the art.

0177Turning now to <figref idref="DRAWINGS">FIG. 27</figref>, the procedure by which Port Randomizer <b>2632</b> operates is shown as a series of actions. The procedure begins at step <b>2700</b>, in which a Gateway's administrator chooses, either specifically or through default values, a port range, a dwell time for each port to be selected while listening for incoming traffic, and an algorithm identifier for selecting the port that should be open at any given time. These parameters are chosen for optimal balance between several measures: computation intensity at both the listening Gateway <b>2550</b> and any other Gateway <b>2550</b> offering traffic to the listener; the probability of an attack finding the currently open port at any given time and thereby being able to inject “wild” traffic to the Secured Application Proxy <b>2552</b>; the probability of a legitimate transaction initiation missing the correct open port due to latency in Packet Network <b>102</b>; the number of applications being supported at the same Gateway <b>2550</b>; and the planned balance between incoming and outgoing traffic. An optimal port range will generally be, simply, as wide as possible. Of the 2{circumflex over ( )}16 values in the TCP port number, the lowest <b>2000</b> or so should be avoided simply because the standard ports for most applications are in that range, and DoS attackers may attempt to hit them without regard for whether any service is actually deployed there. Some range should also be reserved for the incoming side of outgoing transactions. The port range for incoming transactions does not have to be contiguous. A total of at least 50,000 ports will generally provide satisfactory performance. The dwell time is chosen to accommodate the expected latency of Packet Network <b>102</b>; the usual expected Internet performance, which drives the standard timeouts in TCP and other protocols, will drive a fairly long dwell time on the order of 5-10 minutes. Shorter dwell times provide better attack avoidance, and the Internet's packet latency is generally much shorter than the worst case to which TCP is designed. Therefore, a dwell time as short as 15 seconds offers a reasonable default; other values may be chosen in implementations with different performance expectations. The algorithm is chosen from among several cryptographic hash functions that are widely known to those skilled in the art. Combining the 15 second default dwell time with the 50,000 default ports and a hash function with high entropy yields an average time between repeated ports of more than 8 days. It is this behavior that ensures no illegitimate traffic will reach the Secured Application Proxy <b>2552</b>.

0178After choosing randomization parameters, the process moves forward at step <b>2701</b> to register the Gateway <b>2550</b> to which those parameters apply in the appropriate Network Authority <b>160</b>. Registration is already described above in the context of <figref idref="DRAWINGS">FIG. 22</figref> and <figref idref="DRAWINGS">FIG. 24</figref>; to summarize again, the approach includes generating an asymmetric encryption key pair for the Gateway, certifying it at the Authority, and entering the Gateway in the Authority's private DNS in support of future Introductions. This process enhances that one slightly by encoding the randomization parameters in the certificate. That allows a transaction initiator, properly Introduced, to find the correct port number. The resulting certificate is called an Introduction Certificate in the remainder of this specification.

0179The next two steps prepare the Gateway <b>2550</b> for incoming and outgoing transactions. Step <b>2702</b> initializes the listening process, whereby Gateway <b>2550</b> opens a port for incoming transactions, closes it after the dwell time, and repeats endlessly; the loop is detailed below as sequence <b>2710</b>. Step <b>2703</b> creates support for selecting the correct port at another Gateway <b>2550</b> when initiating outgoing transactions; the subroutine is detailed below as sequence <b>2720</b>.

0180Sequence <b>2710</b> is the loop in which Gateway <b>2550</b>, and specifically Port Randomizer component <b>2632</b>, listens for incoming transactions from other Gateways <b>2550</b>, while ignoring offered transactions from unauthorized sources. It begins at step <b>2711</b> with the selection of a port number from the configured port range. Port selection uses the configured encryption algorithm, one of several available one-way hash functions with high entropy, into which is fed the public key from the Gateway's certificate and the current time. Specifically, the time is truncated to a resolution matching the configured dwell time, then interleaved with the public key, and the result is hashed. The hash value, modulo the total size of the port range, becomes an index into the list of candidate port numbers (remember that the entire port range need not be contiguous), and the port number at that index is chosen. This algorithm is designed to produce a new port number in constant time, so that the performance of Port Randomizer <b>2632</b> is consistent. A true pseudo-random number generator is not used specifically because synchronizing to its current value at a transaction initiator generally requires computation time proportional to the amount of time that has elapsed since the sequence began; such behavior would not be conducive to high-performance networking.

0181The security of this algorithm depends on two factors. First, the Authority network and the Introduction process are designed to ensure that only certified network members, such as Gateways <b>2550</b>, are permitted to receive certificates; at the same time, the usage of those certificates is constrained so that they do not leak into the normal public SSL space. Thus the public key, a major input to the algorithm, is maintained as a shared secret within the network. Second, the allowable hash functions are those with high entropy, so that for a particular sequence of timestamps input to the algorithm, the resulting port number sequence appears random and is well distributed.

0182With a port number selected, at step <b>2712</b> the Gateway <b>2550</b> then opens that port to listen for incoming transaction requests from Packet Network <b>102</b>; in a preferred embodiment this network is the Internet, and the incoming transaction request is a TCP SYN packet. Step <b>2713</b> indicates a timeout operation; Gateway <b>2550</b> listens on the current port for the duration of the configured dwell time. If transaction requests arrive they are handled according to the correct protocol; if none arrive no work is done. At the end of the dwell time, at step <b>2714</b>, the current port is closed, such that further transaction requests addressed to that port are ignored. Transactions that have commenced on an incoming port during the dwell period for that port may be handled according to one of two approaches. The port may remain open for continuing transactions only, or the continuing transactions will change port number along with the listener. In a preferred embodiment, one of these approaches is chosen prior to implementation of all Gateways <b>2550</b>. In an alternate embodiment, either approach may be used as long as the one configured at a particular Gateway <b>2550</b> is encoded in its Introduction Certificate as an additional randomization parameter so its correspondents can know to behave accordingly.

0183Finally, the loop continues at step <b>2715</b>, in which the process returns to step <b>2711</b> and repeats indefinitely from there.

0184Sequence <b>2720</b> is the subroutine used when opening an outgoing transaction, to select the correct destination port at the destination Gateway <b>2550</b>. First, at step <b>2721</b> the originating Gateway <b>2550</b> acquires the Introduction Certificate of the destination Gateway <b>2550</b>. It does this by asking its Network Authority <b>160</b> using the Introduction procedure. Recall that that procedure allows Introduction Certificates to be cached locally, so the query may go through the local cache on the way and find it there. Once obtained, at step <b>2722</b> the randomization parameters are extracted from the certificate, and at step <b>2723</b> those parameters and the current time are run through the same algorithm described above to produce a destination port number. In implementations that expect significant and reasonably consistent packet latency across Packet Network <b>102</b>, the time fed into the port selection algorithm may be incremented by the anticipated latency prior to truncation, to reduce the probability of missing the open port at the other end. Note that for this to work, all Gateways <b>2550</b> require a synchronized sense of the current time, which is easily accomplished by distributing the standard Network Time Protocol (NTP) through the Authority Network.

0185Step <b>2724</b> launches the transaction request toward the destination Gateway at the selected port; in the preferred Internet-based Packet Network <b>102</b>, this would be a TCP SYN packet. In prior art systems, if no response is received to this transaction request, the transaction may be abandoned or deferred. In the present invention, there is a non-zero probability that unanticipated network latency may cause the selected port to have been closed by the time the transaction request arrives at the destination Gateway. Therefore, step <b>2725</b> calls for the originating Gateway to delay a fraction of the dwell time if the timeout is an integer multiple of the dwell time, then recompute the destination port and retry the transaction request. If the transaction request times out a second time it is safe to assume the destination Gateway is down. Therefore in step <b>2726</b> standard TCP processing is used to complete the transaction, either successful or not.

0186The next two figures are message sequence charts depicting the flow of a transaction in System <b>2500</b>. They are distinguished by whether or not the destination server is protected by a Gateway <b>2550</b>. In both cases, the transaction originator is so protected. Two omitted cases exist as well. If neither the originator nor the destination has a Gateway <b>2550</b>, the present invention has no effect and therefore no description is required. If the destination has a Gateway <b>2550</b> but the originator does not, the transaction enters the destination Gateway <b>2550</b> through its Exposed Application Proxy <b>2551</b>. As has been described previously, the transaction is handled according to the capabilities of the implemented Application Proxy <b>2611</b>, then if allowed to proceed it is forwarded through to the Protected Infrastructure <b>2503</b> at the discretion of Traffic Governors <b>2623</b> and <b>2612</b>. No other depiction is necessary.

0187<figref idref="DRAWINGS">FIG. 28</figref> shows the flow for a transaction between two Gateways <b>2550</b>. In step <b>2801</b>, the originator decides a transaction is required and builds the protocol element that will be carried as the initial signalling data unit (or SDU) for the transaction. This initial SDU may contain a setup or other request structured according to the protocol of the application at hand. The originator may be a mail server relaying a message, a SIP proxy initiating a call, a web server requesting information from another web server, some other kind of server, or some kind of client. At the appropriate time, the originator will in step <b>2802</b> take action to open a transaction to the destination server, generally identifying the destination by name and application by name or port number to a networking module in the platform executing the originator's function. Note that if the application has a standard port number, it is used at this stage; the originator's behavior is not altered by the presence of the Gateway <b>2550</b>. That networking module will in step <b>2803</b> route the transaction request and initial SDU toward the destination server. The originator may be explicitly configured to route through the originating Gateway <b>2550</b>, or the Protected Infrastructure <b>2503</b> in which the originator exists may be configured to do so regardless of requested destinations. In any case, the transaction request and initial SDU are in step <b>2804</b> transmitted to the originating Gateway <b>2550</b>. Referring back to <figref idref="DRAWINGS">FIG. 25</figref> and <figref idref="DRAWINGS">FIG. 26</figref>, the request arrives over packet transfer interface <b>2555</b> at Secured Application Proxy <b>2552</b>, which at step <b>2805</b> receives it and begins to process it. Generally, its first act will be to acknowledge the transaction request according to the transport protocol, shown as the bidirectional transfer of acknowledgments in step <b>2806</b>. In the Internet-based preferred embodiment of Packet Network <b>102</b>, these are the SYN/ACK and ACK used in TCP.

0188At this point the transaction is open between the originator and the originating Gateway <b>2550</b>. That Gateway will at step <b>2807</b> perform any authentication that may be required either by the application protocol or the Gateway policy. For example, mail clients may be identified using the SMTP AUTH protocol, or a web server may be authenticated using SSL. This establishes that the originator is valid. Also in step <b>2807</b>, the transaction may be tracked against the originator's traffic accounting, according to the principles previously described. This accounting serves two purposes. First, it allows the Gateway <b>2550</b> to establish a baseline normal traffic pattern for the particular originator. Second, it allows the Gateway <b>2550</b> to compare that originator's recent traffic against the baseline and determine whether the transaction at hand represents normal traffic or something that may indicate misuse such as spam or participation in a distributed denial of service attack. If misuse is detected, whether intentional or driven by a zombie infection, the originator's transaction may be abandoned at this point to prevent further damage.

0189Assuming the transaction is allowed to proceed from here, though, at step <b>2808</b> the Introduction component <b>2631</b> of originating Gateway <b>2550</b> will attempt to determine whether the true destination is protected by its own terminating Gateway <b>2550</b>. If no record of the destination is found in its cache, Introduction component <b>2631</b> will request an Introduction from its superior Network Authority <b>160</b>. The Introduction Request is shown in transit in step <b>2809</b>. In step <b>2810</b>, since in this scenario there is a terminating Gateway <b>2550</b>, the appropriate Network Authority <b>160</b> retrieves its address and Introduction Certificate. Those are returned to the originating Gateway in an Introduction Response, which is shown in transit at step <b>2811</b>. Note that only the simplest Introduction is depicted here. Refer to the descriptions of <figref idref="DRAWINGS">FIG. 22</figref> and <figref idref="DRAWINGS">FIG. 23</figref> for complete details on this protocol and the variety of Authority arrangements that are possible.

0190Upon receiving the Introduction certificate of the terminating Gateway <b>2550</b>, originating Gateway <b>2550</b> at step <b>2812</b> selects the timely destination port as previously covered in <figref idref="DRAWINGS">FIG. 27</figref>. In step <b>2813</b>, it initializes the encryption tunnel used to communicate with terminating Gateway <b>2550</b>, which also uses the information in the Introduction certificate along with well-known secure tunnel technology as provided by Tunneling module <b>2633</b>. Now the encrypted transaction can be opened between originating and terminating Gateways <b>2550</b> at step <b>2814</b>. Step <b>2815</b> shows an encrypted transaction request in transit from one to the other; this request also carries information so that the terminating Gateway <b>2550</b> can know the identity of the originating Gateway <b>2550</b>. When the request arrives at terminating Gateway <b>2550</b>, its first action at step <b>2816</b> is to determine whether an Introduction certificate is available for originating Gateway <b>2550</b>, and if not to request on Introduction from its own Network Authority <b>160</b>. This Introduction is shown as steps <b>2817</b>, <b>2818</b>, and <b>2819</b>, and is substantially similar to the Introduction in steps <b>2809</b>, <b>2810</b>, and <b>2811</b>.

0191With the originating Gateway's Introduction certificate now known, the terminating Gateway's Introduction module <b>2631</b> can at step <b>2820</b> verify the other's identity and allow its networking module to accept the transaction request. Acknowledgements are exchanged in the encrypted tunnel at step <b>2821</b>. The originating Gateway's Secured Application Proxy <b>2552</b> and Tunneling component <b>2633</b> can now, as step <b>2822</b>, encrypt and send the initial SDU of the application protocol; this SDU is shown in transit in step <b>2823</b>.

0192Upon the initial SDU's arrival at terminating Gateway <b>2550</b>, the Secured Application Proxy <b>2552</b> at that end handles it in step <b>2824</b> by performing any authentication of the originator that may be appropriate in the application's protocol, and tracking the transaction against the destination's traffic records. As previously described for messaging and multimedia signalling traffic, or using similar techniques that fit whatever other application is being handled here, excess or inappropriate traffic may be blocked and reported to users and administrators. If the traffic pattern indicates that the destination is the target of a Distributed Denial of Service (DDoS) attack in which the sender may be participating, this observation may also be reported back to the originating Gateway <b>2550</b> for further action by an administrator or user there. Though this action is not shown in <figref idref="DRAWINGS">FIG. 28</figref>, it is implied by the reference to tracking in step <b>2824</b>.

0193Assuming the transaction is allowed to proceed, at step <b>2825</b> the Secured Application Proxy <b>2552</b> of terminating Gateway <b>2550</b> opens the transaction through to the actual destination server. The standard port for the application at hand is used, so that the destination server does not have to be modified in any way due to the presence of terminating Gateway <b>2550</b>. The transaction request, along with the same initial application SDU constructed at the originator and passed along throughout this flow, is transmitted to the destination server in step <b>2826</b>. There, it is received at step <b>2827</b>, the transaction request is acknowledged in step <b>2828</b>, and the application transaction is processed normally in step <b>2829</b>.

0194In many applications, additional data may flow between the originator and the destination server. Steps <b>2830</b> through <b>2835</b> depict the flow of transaction data back from the destination server to the originator. Since the Gateways act as proxies, even though the originator and the destination server think they are in direct communication with one another, in actuality they are in direct communication only with their respective Gateways. Thus, the Gateways relay transaction data as well as transaction requests on behalf of their protected infrastructures. This is actually a good thing, because the inter-Gateway flow is shielded from tampering and interception by the use of an encrypted tunnel, and the protected infrastructures are shielded from wild traffic, whereas a direct flow between originator and destination server would not be so protected. In the figure, steps <b>2830</b>, <b>2832</b>, and <b>2834</b> show the transaction data in transit on each leg of the path in turn, while steps <b>2831</b> and <b>2833</b> show the Gateways relaying the data through their respective Secured Proxies. Finally, step <b>2835</b> is shown processing the transaction data at the originator. Similar steps, not shown but readily apparent in light of those that are shown, would occur in the opposite order for flow in the opposite direction.

0195<figref idref="DRAWINGS">FIG. 29</figref> depicts the scenario in which the originator is protected by an Originating Gateway <b>2550</b>, but the destination server is not. The flow in this case is a strict subset of the flow in <figref idref="DRAWINGS">FIG. 28</figref>. Steps <b>2901</b> through <b>2909</b> are substantially the same as steps <b>2801</b> through <b>2809</b>. At step <b>2910</b>, however, the Network Authority determines that the destination is not protected by a Gateway. It is also possible that the Network Authority is configured to prevent secure communication between the particular originating and destination Gateway pair, after the fashion of the Authority network constraint sets described in the context of <figref idref="DRAWINGS">FIG. 22</figref>. In either case, the Network Authority therefore replies to the Introduction Request with a negative result; no Introduction occurs. This response is shown in transit in step <b>2911</b>, and upon its arrival originating Gateway <b>2550</b> recognizes that it will interact directly with the destination server itself. Therefore, no counterparts to steps <b>2812</b> through <b>2824</b> occur in this scenario, and at step <b>2925</b> the originating Gateway opens an unencrypted transaction to the destination server. A subtle but significant difference between step <b>2925</b> and step <b>2825</b> is that in this case, Secured Application Proxy <b>2552</b> hands the transaction over to Exposed Application Proxy <b>2551</b> inside originating Gateway <b>2550</b>, so that the latter handles unprotected transactions with destination servers across Packet Network <b>102</b>. This further protects Secured Application Proxy <b>2552</b> by avoiding exposure of its address to insecure servers. It also prevents unintended establishment of SSL sessions (secure tunnels) with non-Gateway entities, which could risk revealing the Gateway's Introduction certificate to non-Gateway entities. But for that difference, steps <b>2926</b> through <b>2929</b> are then substantially similar to steps <b>2826</b> through <b>2829</b> in the previous figure. Here, too, transaction data may flow subsequent to the transaction establishment and initial application SDU, and steps <b>2930</b> through <b>2935</b> show the flow back to the originator from the destination server and imply the opposite direction. As with the transaction request flow, and for the same reasons, the relay action at step <b>2933</b> is subtly different from the corresponding action at step <b>2831</b> and <b>2833</b>. In step <b>2933</b>, the data is handed from Exposed Application Proxy <b>2551</b> to Secured Application Proxy <b>2552</b> in the direction shown, or from Secured Application Proxy <b>2552</b> to Exposed Application Proxy <b>2551</b> in the opposite direction, whereas in steps <b>2831</b> and <b>2833</b> the data is handled entirely by a Secured Application Proxy <b>2552</b>.

0196The invention has been described above with reference to preferred embodiments and specific applications. It is not intended that the invention be limited to the specific embodiments and applications shown and described, but that the invention be limited in scope only by the claims appended hereto. In particular, while the Messaging Spam Prevention System <b>100</b> is described as pertaining primarily to end-user messaging applications such as email and IM, and Multimedia Spam Prevention System <b>1900</b> is described as pertaining primarily to end-user media sessions such as VoIP and videoconferencing, other applications may be built upon them as well. For example, machine-to-machine automatic messaging or data streaming may take advantage of the secure communication provided by System <b>100</b> or System <b>1900</b>, respectively. The various Clients described may be augmented by adaptor functions to provide service for other protocols as well, such as HTTP-based web services protocols, localized data-recording protocols, proprietary EDI protocols, and so forth. It will be evident to those skilled in the art that various substitutions, modifications, and extensions may be made to the embodiments as well as to various technologies which are utilized in the embodiments. It will also be appreciated by those skilled in the art that such substitutions, modifications, and extensions fall within the spirit and scope of the invention, and it is intended that the invention as set forth in the claims appended hereto includes all such substitutions, modifications, and extensions.