WO2004046992A2 - Expedition de messages electroniques utilisant des techniques d'estimation - Google Patents

Expedition de messages electroniques utilisant des techniques d'estimation Download PDF

Info

Publication number
WO2004046992A2
WO2004046992A2 PCT/US2003/037417 US0337417W WO2004046992A2 WO 2004046992 A2 WO2004046992 A2 WO 2004046992A2 US 0337417 W US0337417 W US 0337417W WO 2004046992 A2 WO2004046992 A2 WO 2004046992A2
Authority
WO
WIPO (PCT)
Prior art keywords
message
sender
penalty
recited
value
Prior art date
Application number
PCT/US2003/037417
Other languages
English (en)
Other versions
WO2004046992A3 (fr
Inventor
Scott Banister
Patrick Peterson
James Moore
Original Assignee
Return Path, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/717,414 external-priority patent/US7230228B2/en
Application filed by Return Path, Inc. filed Critical Return Path, Inc.
Priority to EP03787031A priority Critical patent/EP1563435A2/fr
Priority to AU2003295821A priority patent/AU2003295821A1/en
Priority to JP2004570648A priority patent/JP2006508477A/ja
Publication of WO2004046992A2 publication Critical patent/WO2004046992A2/fr
Publication of WO2004046992A3 publication Critical patent/WO2004046992A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Information and communication technology [ICT] specially adapted for implementation of business processes of specific business sectors, e.g. utilities or tourism
    • G06Q50/40—Business processes related to the transportation industry
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/107—Computer-aided management of electronic mailing [e-mailing]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/21—Monitoring or handling of messages
    • H04L51/212—Monitoring or handling of messages using filtering or selective blocking

Definitions

  • the present invention generally relates to electronic message delivery with estimation approaches.
  • the invention relates more specifically to methods and systems for ensuring that electronic messages are delivered.
  • senders marketing commercial products or services would acquire or develop lists of e-mail addresses and then periodically send mass unsolicited e-mail messages ("spam") to all addresses in the lists.
  • spam mass unsolicited e-mail messages
  • the cost of sending millions of such messages has been negligible, and a response rate of even less than one percent has been considered worthwhile.
  • successful delivery of unsolicited messages to valid in-boxes of recipients normally translates into income for the sender.
  • receivers use filtering or blocking technologies that search for keywords in the message subject line and reject or quarantine messages that contain keywords matching a list of prohibited words.
  • receivers use "black lists” to identify and prohibit display of messages from suspect senders of unsolicited messages. Some receivers augment these technologies with personal "white lists” of friends or other acceptable senders; only messages from senders in the "white list” are admitted.
  • the "white lists” and “black lists” also may come from networked sources.
  • receivers continue to receive large volumes of unwanted messages that are not properly trapped by the "spam” filter.
  • many receivers now refuse to disclose their address except under limited circumstances.
  • many legitimate senders such as reputable commercial enterprises, have developed "opt-in” procedures in which the addresses of receivers, such as customers, are not used at all unless the receiver affirmatively agrees to receive messages.
  • the filtering or blocking technologies may delete or quarantine even those messages from legitimate senders that are directed to receivers who have "opted in.”
  • ISPs also incur costs associated with processing messages directed to recipients who do not hold an account with the ISP.
  • the ISPs mail system typically generates an automatic "bounce" message that states that the recipient is unknown. Indeed, a "double bounce” may occur when a message bears an invalid sender address, and is sent to an invalid recipient. Costs are associated with maintaining the equipment and software that generates the bounce messages, and for dispatching the bounce messages back into the network to the sender.
  • costs are associated with maintaining the equipment and software that generates the bounce messages, and for dispatching the bounce messages back into the network to the sender.
  • ISPs ISPs, business enterprises, and end users all suffer inconvenience, costs, and annoyances.
  • high-value e-mail messages regularly may be blocked or placed into a
  • FIG. 1 A is a block diagram that illustrates an overview of a system for delivering electronic messages
  • FIG. IB is a block diagram that illustrates additional elements of the system of FIG. IB;
  • FIG. 2 A is a flow diagram of a process of electronic message delivery, according to one embodiment
  • FIG. 2B is a flow diagram of a method of processing received electronic messages
  • FIG. 3 is a flow diagram of a method of reporting an unwanted message
  • FIG. 4 is a block diagram of a message
  • FIG. 5 A is a flow diagram of a message verification approach
  • FIG. 5B is a flow diagram showing additional steps in the method of FIG. 5 A;
  • FIG. 5C is a flow diagram of a generating a validation message
  • FIG. 6 is a flow diagram of validating a message
  • FIG. 7 A is a flow diagram of verifying a report of an unwanted message
  • FIG. 7B is a flow diagram showing additional steps in the method of FIG. 7 A;
  • FIG. 8 is a block diagram of a banking network and related elements in relation to the system of FIG. 1 A;
  • FIG. 9 is a block diagram that illustrates a computer system upon which an embodiment may be implemented.
  • FIG. 10A is a flow diagram of a first process for messaging processing using an estimation approach.
  • FIG. 10B is a flow diagram of a second process for messaging processing using an estimation approach.
  • the present invention comprises, in one aspect, a method for delivering an electronic message.
  • the invention encompasses a computer apparatus and a computer readable medium configured for delivering an electronic message.
  • methods and systems described herein provide techniques by which message senders can guarantee that their messages are delivered to their intended Recipients, and are not blocked by the "spam" filters that are presently used by many network service providers.
  • a Sender enters into a contract with a Bonded SenderTM Service Operator, in which the Sender agrees to pay a fine for each message that is reported as an unwanted or "spam" e-mail by its intended Recipient.
  • the Sender establishes the amount of the fine that it is willing to pay, per e-mail.
  • the Sender may be subject to a credit check or to a requirement to place funds into escrow. Alternatively, the Sender may promise to pay a particular fine amount rather than actually providing funds in advance.
  • BONDED SENDER is a trademark of IronPort Systems, Inc., the assignee of this application.
  • a Sender then identifies a message as "bonded" at the time the message is sent.
  • an encrypted token in a message identifies the message as bonded.
  • bonded messages are sent from a specified network address that is provided to the Service Operator when the contract is negotiated. In this way, the Service Operator knows that all messages having a particular source network address in the message header are bonded.
  • a Receiver upon receiving a bonded message, performs conventional anti-"spam" checks and filters. If the Receiver determines that the message is not “spam,” the Receiver forwards the message to its intended Recipient. If the Receiver determines that the message is "spam,” the Receiver checks to determine whether the sender of the message is a Bonded Sender. Such a check may be performed by issuing a query from the Receiver to the Service Operator, in which the query includes a network address of the Sender. The Service Operator determines whether the Sender is identified in a database that is maintained by the Service Operator. If so, the Service Operator sends a response to the Receiver identifying the Sender as bonded. Optionally, the response may include the amount of the fine to which the Sender agreed in the contract, or another amount.
  • the Receiver determines whether it will accept the message.
  • the decision to accept can be based upon whether the fine exceeds a specified amount or threshold.
  • the threshold value may be set as a matter of policy by the Receiver, or set in advance by or for each individual end user account-holder associated with the Receiver. For example, a user profile at the Receiver associated with User X may specify that X will not accept any potential "spam" messages from Senders that have committed to any fine less than $2.50 per message; however, a profile for User Y may specify that Y will accept messages committing any amount greater than $1 per message.
  • the Receiver determines that it will accept the message, the Receiver notifies the Service Operator. In response, the Service Operator attempts to reserve the amount of the fine or penalty. If the reservation is successful, the Service Operator sends an acknowledgment to the Receiver.
  • Use of reservations and tracking the aggregate number of reservations enables the Service Operator to determine whether the Sender is likely to exceed a credit limit established by the Service Operator, or whether the Sender needs to deposit additional bond funds with the Service Operator. Further, the Service Operator may refuse, as a matter of policy, to acknowledge the bonded status of any Sender that has aggregate reserved fine amounts that exceed its credit limit with the Service Operator by a specified threshold. In one embodiment, each reservation automatically expires after a specified time.
  • the Receiver In response to receiving a reservation acknowledgment, the Receiver forwards the message to the intended Recipient.
  • the Receiver also provides, to associated Recipients, a way of signaling the Receiver that the user has identified a message as "spam.” For example, a graphical user interface display may have a button designated as "Report Message As Unwanted.” If the Receiver receives signals that identify messages as unwanted, the Receiver stores information about the signals and messages. Periodically, the Receiver sends reports to the Service Operator that identify which messages have been reported as "spam.” In response, the Service Operator penalizes the Senders.
  • penalties comprise fines that variously are capped, tiered, or timed.
  • the messages variously comprise e-mail messages, instant messages, chat-room posts, Web message board posts, telephone calls, or pager messages.
  • various revenue models are used with respect to the fines, such as sharing fines with Receivers, sharing fines with non-profit organizations, charging Receivers or Senders to participate, etc.
  • “Bond” means a quantity of value that is transferred by the Sender to the Service Operator before the Sender dispatches one or more bulk messages.
  • a bond may comprise money, resources of any kind, goods, services, or promises.
  • “Enterprise” means a business entity that is not primarily in the business of sending bulk messages; its employees are often Recipients.
  • Receiveiver means a business entity, hardware device, software element, or combination of the foregoing that receives messages and distributes the messages to Recipients.
  • Receivers include business enterprises, Internet Service Providers (ISPs), Web-based e-mail services, etc.
  • Recipient means an individual account, computer, or end user that reads, uses or otherwise consumes a message sent by a Sender. Recipients often are end users who hold accounts with Receivers.
  • Sender means an individual or business entity that regularly sends large numbers of messages to actual or prospective customers, subscribers, members, or other Recipients.
  • Examples of Senders include retail businesses include online businesses and brick-and-mortar businesses, advertising service firms, electronic mailing list providers, etc.
  • a Sender also comprises an individual who registers and manages Bonded Sender network addresses for a separate end user or system that sends messages or causes messages to be sent.
  • Service Operator means a trusted third party that acts as a provider of the functions and services defined herein.
  • Spam means an unwanted e-mail message, which is typically a mass unsolicited message.
  • Submitter means an individual or business entity that reports to the Service Operator that one or more received messages are or were unwanted.
  • a Submitter may be a Receiver or a Recipient.
  • a party that makes or sells anti-"spam” filters, software or other technology may act as a Submitter to reduce the number of "false positives" generated by its technology.
  • FIG. 1A is a block diagram that illustrates an overview of a system for delivering electronic messages.
  • a Sender 102 which owns, operates or is associated with an outbound messaging gateway 104, is communicatively coupled directly or indirectly through one or more networks to a Message Processing System 106 that is owned or operated by a Service Operator.
  • a Receiver 108 is communicatively coupled to the Message Processing System 106. The Receiver owns, operates, or is associated with an inbound messaging gateway 110.
  • a Recipient is communicatively coupled to gateway 110.
  • Each Gateway 104, 110 may comprise a general-purpose messaging gateway, also known as a Message Transfer Agent (MTA), mail relay, email relay, email router, Simple Mail Transfer Protocol (SMTP) server, or email gateway, which is specially programmed to perform the functions described herein.
  • MTA Message Transfer Agent
  • SMTP Simple Mail Transfer Protocol
  • FIG. 1 A shows one of each element identified above.
  • Message Processing System 106 may be replicated in one or more instances or sites for scalability or load-balancing purposes.
  • certain embodiments are described herein in the context of processing e-mail messages; however, in other embodiments the messages comprise telephone calls, or pager messages.
  • Sender 102 registers with Message Processing System 106 and obtains an account with the Service Operator.
  • Receiver 108 also registers and obtains an account.
  • the Sender 102 may select a dedicated source network address that is used for bonded messages, and provides the selected address to Message Processing System 106.
  • Sender 102 causes its outbound messaging gateway 104 to send one or more messages, which contain information identifying an offered or promised penalty amount, and are directed to Recipient 112.
  • the messages are received at the inbound messaging gateway 110 of the Receiver 108.
  • Gateway 110 determines that the messages are bonded.
  • Gateway 110 queries Message Processing System 106 to determine whether the messages originate from a party that is registered in the Message Processing System as a Bonded Sender.
  • Message Processing System 106 and gateway 110 apply one or more validation tests to information in the message or derived from packets that transport the message.
  • the message is delivered to the Recipient 112, or a score value is provided to a filter, or the message is discarded, or the message is marked as Bulk, or other actions are taken.
  • FIG. IB is a block diagram that illustrates additional elements of the system of FIG. IB.
  • Message Processing System 106 may be implemented as one or more server- class computer systems that host a Web server 122, database 124, and DNS server 126.
  • Web server 122 may comprise a combination of an HTTP server, such as the Apache HTTP server, and an application server such as the WebLogic application server.
  • Database 124 provides a repository for storing information about registered Senders, Receivers, Recipients, bonds, messages, and other metadata, and may comprise a relational database server such as Oracle 8i, Microsoft SQL Server, etc. Database 124 also may contain log information such as a history of network addresses that have been added or deleted by Senders.
  • DNS server 126 is accessible using Internet Domain Name System ("DNS”) protocol requests and can perform resolution of domain names to Internet Protocol ("IP”) addresses, provide information about specified IP addresses, etc.
  • DNS and IP are described herein for certain embodiments; however, embodiments are not limited to the use of DNS and IP for address processing, and the invention is applicable to any network addressing mechanisms or protocols that may be developed in the future.
  • DNS server 126 has high capacity. For example, an appropriate DNS server 126 can process on the order of fifty million queries per day. Further, a DNS server that has nearly 100% availability and does not impose unreasonable message latency should be provided.
  • FIG. IB shows a JSP implementation in which functions are organized as Sender Pages 120A and Administrative ("Admin") Pages 120B.
  • ASP Active Server Pages
  • FIG. IB shows a JSP implementation in which functions are organized as Sender Pages 120A and Administrative ("Admin") Pages 120B.
  • Receiver (“Recv'r") Pages 120C provider receiver functions.
  • Sender 102 and Receiver 108 may access functions of system 106 using a conventional
  • gateway 1 10 may access functions of system 106 by directing HTTP requests to system 106.
  • Sender 102 interacts with Sender Pages 120A to register with the system and obtain information about bond amounts offered or promised, credit exposure, complaints received, message volume sent and fines incurred.
  • An administrator associated with the Service Operator interacts with Admin Pages 120B to perform administrative functions such as user registration and validation, providing registered
  • a Receiver or Recipient interacts with Receiver Pages 120C to register with the system, report unwanted messages, investigate credit and bond status, etc.
  • Message Processing System 106 also may comprise one or more other software elements, hardware elements, or manual operations that perform the functions described herein.
  • FIG. 2A is a flow diagram of a process of electronic message delivery, according to one embodiment.
  • one or more Senders enter into contracts with the Service Operator.
  • the Senders agree to pay fines for sending unwanted messages, subject to a dispute resolution process that addresses fraudulent reports of unwanted messages, and false reports from Recipients who did not actually receive the messages.
  • Block 201 may include engaging in a registration process in which the Senders provide contact information and credit information to the Service Operator.
  • the Registration process an administrator or other authorized representative of a Sender or
  • Receiver may establish a password-protected account at the Service Operator for the purpose of entering, updating, and viewing information relating to their interaction with the Service Operator.
  • a Sender provides, to the Service
  • the terms and conditions of the contract specify that: the Service Operator will review the address information that is provided, to verify ownership of the IP addresses and proper configuration of the DNS records; the Sender may use the system to send only messages that conform to a set of standards; and other terms and conditions relating to legal liability, confirmation of registration, fees, etc.
  • the contract may be implemented as a "click-to-accept" online form.
  • any or all of the steps in the registration process described above are performed using non-online communication methods, such as by telephone, fax, etc.
  • a representative of the Sender contacts an administrator associated with the Service Operator, who creates records in the system that capture the above-described information.
  • the contract terms outlined above may be negotiated and agreed to using fax communications.
  • Block 201 also may involve the Service Operator performing a validation of the network addresses and other information provided by a Sender. For example, an administrator of the Service Operator performs a reverse (PTR) DNS lookup for each LP address provided by the Sender, and records information about each domain that is returned by the DNS system. The Service Operator performs a "whois" lookup to verify that the domain name ownership of record matches the Sender. Other tests may be performed to verify that the Sender is not a "spammer" or to verify that the Sender segregates its bulk mailing lists to ensure that only non-"spam" messages are directed to bonded addresses.
  • PTR reverse
  • a Sender places a bond with the Service Operator. Placing the bond may form part of entering a contract in block 201.
  • the Service Operator performs a credit check on the Sender and does not require a bond.
  • a Sender lacking adequate credit or payment history is required to deposit funds with the Service Operator.
  • the deposited funds may be placed in an escrow account, trust account, or similar account from which the Service Operator may withdraw funds only upon determining that an unwanted message has been sent.
  • the Sender indicates that a particular communication is bonded and subject to fines. Such an indication may be provided in several ways.
  • the Sender advertises a particular network address, selected by the Sender as its "Bonded Sender" address.
  • IP Internet Protocol
  • the Sender registers a specified Bonded Sender source IP address with the Service Operator, and then sends bonded messages only from that address.
  • a cryptographic approach is used. Methods of advertising a message source are described further in other sections hereof.
  • the Sender indicates what amount of fine it agrees to pay if a particular message or communication is unwanted.
  • the Sender registers a proposed fine amount with the Service Operator before sending messages.
  • the Sender issues a promise to the Service Operator that the Sender will pay a particular fine amount for unsolicited messages; an actual transfer of funds in advance of sending messages is not required.
  • fixed or variable penalty values are imposed, based on a complaint rate or other metric. For example, a Sender may be debited $20 for every complaint in excess of one per million. Any other suitable complaint rate or penalty value may be used.
  • all fines may be a single specified amount that does not vary, such as $1 per unwanted message. Minimum fines, maximum fines, or fines that vary for particular messages or Recipients also may be used.
  • the Sender sends the message.
  • Block 205B may involve causing a messaging gateway to dispatch one or more messages into a network.
  • FIG. 2B is a flow diagram of a method of processing received electronic messages. Referring first to block 206, a Receiver, who may be an individual end user, an ISP, a business enterprise, or any other person or institution, receives a message from the Sender.
  • a Receiver who may be an individual end user, an ISP, a business enterprise, or any other person or institution, receives a message from the Sender.
  • Receivers and Recipients register with the Service Operator before receiving messages in order to obtain a right to use the services of the Service Operator.
  • Receivers and Recipients register as part of block 201 of FIG. 2 A.
  • Registration of a Receiver or Recipient may involve providing contact information, domain name and e-mail address information, gateway information, information about anti-"spam" technologies then in use by the Receiver, etc.
  • the Service Operator may provide Bonded Sender DNS information to the Receiver or Recipient to enable them to configure their gateways to interoperate with the system.
  • Block 206 may involve performing conventional anti-"spam” checks using commercial anti-"spam” filtering or blocking technology.
  • the Receiver proceeds with the remaining steps of FIG. 2B only if a message is identified as "spam.” If the message passes the "spam” checks, then it is forwarded to the Recipient. In an alternate embodiment, the remaining steps of FIG. 2B are performed regardless of the results of the anti-"spam” filtering technology.
  • the Receiver checks the communication for bonded status. This may involve several tests.
  • the Receiver verifies the source address of the received message against the database of advertised Bonded Sender addresses. For example, the Receiver issues a query in an agreed-upon protocol to the Service Operator, and provides the source address of a message that the Receiver has received.
  • block 208 involves gateway 110 issuing a DNS lookup request to DNS server 126 that includes the source address of the received message. If DNS server 126 locates the source address in its database, then a first specified response value is returned. If the source address is not in the DNS database, then a second specified response value is returned. In one embodiment, the first response value is "127.0.0.2" and the second response value is "127.0.0.3.”
  • the Service Operator creates a response message that identifies whether the source address is a registered Bonded Sender address, and sends the response message to the Receiver, as shown by block 212.
  • the foregoing tests also may involve determining the fine amount proposed by the Sender for the message. Further, the Receiver may undertake more or fewer tests, or different tests, depending on the amount of bond or penalty that has been offered or promised by a Sender for a particular message.
  • the Receiver can take responsive action. For example, in block 218, if the source address is not a registered Bonded Sender address, as tested in block 214, the Receiver may elect to block the message, or deliver it to a bulk e-mail folder, or perform any other message filtering step.
  • the Receiver may reserve a fine amount by sending a message to the Service Operator in an agreed-upon protocol, as shown by block 215.
  • the Service Operator creates a record of a fee reservation in its database, determines an expiration date for the reservation, and issues a response message to the Receiver.
  • reserving a fine may constitute an agreement by the Receiver to deliver the message to the Recipient's In-box without any special marking or processing, that is, without labeling the message as Bulk, storing the message in a Bulk folder, etc.
  • the Service Operator and Receivers enter into a contract providing and enforcing such terms.
  • a fee reservation may comprise agreements by the Service Operator to pay a portion of any fine to the Receiver in the event that a Recipient reports the message as unwanted before the reservation expires.
  • Each reservation is associated with an expiration date, after which the reservation expires. The expiration date may occur at any time after the issuance of a reservation. In one embodiment, the reservation is typically one to four days after issuance of the reservation.
  • Use of reservations enables the Service Operator to evaluate and measure the scope of its current credit risk with respect to each Sender. For example, issuing more reservations means that more opportunities for junk reports are created. Further, based on reservation volume, the Service Operator may demand a deposit of additional funds by the Sender, or may perform additional credit checks to verify that its exposure to Recipients is acceptable.
  • the Receiver could elect to deliver the message to the in-box of the Recipient, as shown by block 216.
  • a gateway associated with the Receiver may deliver the message to an outbound address that is selected from among a plurality of outbound addresses.
  • a particular Sender may register a plurality of authorized outbound Bonded Sender addresses. Each such address may have a unique name.
  • One or more routing rules determine how to select an outbound message address based on a Sender address.
  • the Service Operator determines that a Bonded Sender has sent a particular message, the service provider applies the rules, or an injection filter mechanism, to map the source address specified in the message to one of the multiple registered addresses.
  • the Service Operator provides the mapped outbound address to the gateway, which delivers the message to that address.
  • the Receiver by advance agreement between the Receiver and the Service Operator, the Receiver is required to deliver all messages having registered Bonded Sender addresses to the in-boxes of the Recipients of the messages.
  • the Receiver marks the message as originating from a registered Bonded Sender. For example, a graphical user interface that displays a message in-box of an account-holder could display a distinctive icon that identifies messages originating from a registered Bonded Sender.
  • the Receiver may modify the subject line of the message to indicate that it originates from a registered Bonded Sender.
  • the specific action taken by the Receiver may vary depending upon the amount of bond that is offered or promised by the Sender.
  • the mail delivery approaches herein provide a system and process with which a Receiver of unwanted e-mail can indicate, to the Service Operator, that a message is unwanted, implicitly requesting enforcement of the bond or issuance of a penalty.
  • a third party server or system may collect such complaints from Receivers.
  • the complaint collector can forward complaints to the Service Operator or perform any responsive action described herein that the Service Provider could perform, as proxy for the Service Operator.
  • An example of a third party that could be used as a complaint collector is the SPAMCOPTM service available from SpamCop.net, Inc. at the domain spamcop.net.
  • a zone transfer function is provided. Using the zone transfer function, an authorized individual associated with a Receiver can inform the Service Operator, in a single operation, that a plurality of servers or other facilities associated with the Receiver have moved to a different range of addresses.
  • An administrator of the Service Operator also may generate reports for Senders and Receivers. For example, reports may specify the number of queries issued by a Receiver, number of entities performing queries, which IP addresses were queried, etc.
  • FIG. 3 is a flow diagram of a process of reporting an unwanted message. In block 302, a Receiver determines that a received message is unwanted. A Receiver may not want a received message for several reasons.
  • the unwanted message may be a "spam" message, or the message may have resulted from failure of the Sender to honor a request to "unsubscribe" from a mailing list, failure of the Sender to comply with principles of the Direct Marketing Association, failure of the Sender to provide an "unsubscribe" link in a Web site, etc. Determining that a message is unwanted also may involve generating reports of messages that bounced or double-bounced. [0096] In block 304, the Receiver reports, to the Service Operator, that the message is unwanted. Block 304 may involve use of any of several reporting mechanisms.
  • an enterprise Recipient or ISP may provide, in a graphical user interface that is used to view an e-mail in-box, a graphical button, clickable logo, clickable hyperlink, another selectable user interface widget for reporting unwanted messages.
  • the widget may be labeled, e.g., "Report As 'Spam' To Bonding Organization.”
  • the Receiver may provide a specified address for a Recipient to forward unwanted messages, reports of bounced or double-bounced messages, messages sent to accounts that have not opted-in to receive commercial e-mail, etc.
  • a Receiver may accumulate or collect such reports and submit the reports in a batch to the Service Operator.
  • a report that a message is unwanted comprises a source address value, sender identification, Recipient identification, and information identifying the claimant of a fine, or the reporting party.
  • the source address value, sender identification, and Recipient identification may be obtained by the reporting party from the message.
  • the information that identifies the claimant of a fine may comprise a Receiver identifier that the Receiver obtained from the Service Operator as part of registering with the Service Operator.
  • a verification step is provided, as indicated by block 306.
  • block 306 may involve displaying a dialog box to the user that states, "You indicated that a message is unwanted. Please click below to verify.”
  • a message may be provided in an e-mail message that is directed to the Receiver and that is automatically generated in response to receiving a report of an unwanted message.
  • block 306 involves message gateway 102 performing one or more statistical tests on each message that is reported to be unwanted.
  • the statistical tests seek to identify signature text in the messages that indicate that the messages are unwanted.
  • users may be classified in one of a plurality of trust levels. The trust level associated with a user may determine what tests are applied to determine if a message is actually unwanted.
  • use of an encrypted token provides non-repudiation of a message, and prevents a malicious party from falsely contending that it is entitled to a fine for a message that was never sent.
  • other security approaches may be used to promote non- repudiation.
  • SMTP authentication messages may be used to verify the sender of a message, headers with TXT white list record data included, etc.
  • the Service Operator determines whether to impose a penalty.
  • determining whether to impose a penalty involves determining that a report of an unwanted message has been received, and that the sender of the unwanted message is associated with one or more instances of failure to conform to Bonded Sender principles.
  • the sender may have previously sent undeliverable mail, undeliverable mail that generated a bounce message, or may fail to provide an unsubscribe mechanism for its users.
  • determining whether to impose a penalty involves determining whether the Sender has exceeded an allowable complaint rate from all receivers or a particular Receiver. For example, an allowable complaint rate may be one complaint per million messages sent by a Sender, but two or more complaints would exceed the allowed rate.
  • Block 308 may involve penalizing the Sender using any of the approaches described in Section 2.6 hereof, including debiting the Sender by a fixed amount for every complaint in excess of the complaint rate, debiting a variable amount according to message volume, etc.
  • Senders may elect to use bonded message sending for all messages, or for selected messages based upon internal criteria, economies of scale, etc. If a Sender elects not to send a bonded message, then such messages are subject to the problems outlined in the Background section hereof. Enterprises can bond outbound enterprise messages to reduce the likelihood that legitimate messages are inadvertently blocked. [0104] Thus, embodiments herein provide a means for Senders to financially bond selected e-mail to ensure that it is delivered to the Recipient's In-box, and not blocked or stored in a Bulk folder by an anti-"spam" filter or similar technology.
  • Embodiments also enable e-mail Receivers to ensure that messages desired by Recipients are not blocked or stored in Bulk folders as a result of a "false positive" determination by an anti-"spam” filter or similar technology. Embodiments also provide a mechanism for Receivers to ensure that financial penalties are enforced against Senders who post a bond and then send unwanted messages.
  • a Sender advertises one or more network addresses from which it sends bonded messages.
  • "advertisement” may consist of registering the Bonded Sender source address in a database that is maintained by the Service Operator.
  • each Sender includes, in each bonded message, a specified message header that identifies the message as a bonded message.
  • FIG. 4 is a block diagram of an electronic message that uses an encrypted message header approach.
  • Message 400 generally comprises a message header 402 and a message body 418.
  • the message header 402 may be specially designated.
  • a Sender may include a header designated as an "X-BSP" header in the message.
  • message 400 is illustrated as having only the message header 402 and message body 418.
  • the message may include any number of other headers for appropriate purposes, such as
  • message header 402 comprises a sender identifier ("LD") value 404 and an encrypted token 406.
  • the sender ID value uniquely identifies the Sender of the message 400 from among all Senders.
  • a plaintext version of encrypted token 406 comprises a sender ID field 408, token ID 410, expiration time value
  • Token 406 also includes a Recipient address value 416.
  • Sender ID field 408 is the same value as sender ID value 404, and is provided for non-repudiation purposes.
  • Token ID value 410 uniquely identifies the current token from among all tokens that have been issued with the same sender ID value and the same expiration time value.
  • Expiration time value 412 specifies a maximum time during which a Receiver may report the associated message as unwanted and thereby attempt to penalize the Sender for sending an unwanted message.
  • the bond amount offered 414 is an amount of value that is offered or promised by the Sender as a penalty against the Sender if the message is identified as unwanted by a Recipient.
  • token 406 is encrypted using public key cryptography principles.
  • token 406 is encrypted with a private key that is associated with a corresponding public key that is registered with the Service Operator.
  • a Receiver of an e-mail message in the format of FIG. 4 obtains the sender ID and token from the message header. The Receiver then verifies the message according to one of several approaches.
  • FIG. 5 A is a flow diagram of a message verification approach
  • FIG. 5B is a flow diagram showing additional steps in the method of FIG. 5 A.
  • block 502 the
  • Receiver creates a validation message comprising the sender ID and token and submits the message to the Service Operator for validation.
  • the token is decrypted.
  • the Service Operator performs a series of tests on values obtained from the decrypted token, and places result indicators in a validation response message that is ultimately sent back to the Sender.
  • block 506 the Service Operator tests whether the sender ID is valid. For example, block 506 involves testing whether sender ID value 408, obtained from the decrypted token, matches the sender ID that the Receiver provided in its validation message. If so, then in block 508 the Service Operator places an affirmative sender ID validation flag, or similar value, in the response message. If there is no match, then in block 509 a negative sender ID validation flag is placed in the response message. Alternatively, different flagging or signaling operations may be performed such that the Service Operator provides verification that the token was indeed created by the Sender. [0115] In block 510, the Service Operator determines whether it has previously processed the same token.
  • block 510 may involve looking up token ID value 410 in a table or mapping that is maintained by the Service Operator.
  • the table or mapping stores previously processed token identifiers, in association with corresponding sender ID values and expiration time value. If no matching token ID value is found, then the test of block 510 has a negative result. If a matching token LD value is found, then the test of block 510 has a positive result.
  • a negative replay verification flag is placed in the validation response message. If a positive result occurs, then in block 511 an affirmative replay verification flag is placed in the validation response message. Alternatively, other methods of signaling the result of block 510 may be used.
  • the validation message provides a verification that the Service Operator has not seen the then- current token ID from the then-current Sender in any prior token having the same expiration time value.
  • a test is performed to determine whether the Sender of the message has sufficient credit, or funds on deposit, with the Service Operator to satisfy or cover all its outstanding obligations. For example, the Sender is required to have sufficient credit or funds on deposit to cover the full value of all bond amounts offered 414 associated with all messages 400 sent by that Sender for which the expiration time value 412 is unexpired, including the then-current message.
  • the test of block 514 may be facilitated by querying a data table, maintained by the Service Operator, which tracks the total then-current potential penalty liability for each Sender.
  • Block 518 the validation response message is completed by the Service Operator.
  • Block 518 may involve, for example, placing the expiration time value 412, the bond amount offered 414, and the Recipient address 416, all obtained from the decrypted token 406, in the validation response message.
  • FIG. 5B is a flow diagram of an alternative approach for validating a message.
  • FIG. 5B represents process steps that are performed by a Receiver of a message in the format of FIG. 4.
  • Such a Receiver may be an ISP, an enterprise, an individual end user, etc.
  • FIG. 5C is a flow diagram of a generating a validation message.
  • the Receiver extracts the sender LD value 404 from the message header 402 of a message 400.
  • the Receiver submits the sender ID value 404 to the Service Operator in a request to provide the public key of the Sender.
  • the Service Operator looks up the public key of the Sender in a table, mapping or database maintained by the Service Operator, for example, using the sender ID value 404 as a lookup key or index.
  • the Receiver receives the public key of the Sender, in a response message from the Service Operator. Using the public key, the Receiver can decrypt the token 406 in the message header 402, as shown by block 534.
  • the Receiver tests whether the sender ID is valid. For example, block 536 involves testing whether sender LD value 408, obtained from the decrypted token, matches the Sender ID that the Receiver provided in its validation message. If so, then in block 538 the Receiver records data representing an affirmative determination. If there is no match, then in block 539 a negative determination is recorded by the Receiver. No specific data or recordation mechanism is required if the Receiver has a way to remember that it verified whether the token was indeed created by the Sender. [0125] In block 540, the Receiver extracts the expiration time value, bond amount offered, and Recipient address from the decrypted token. In block 542, the Receiver creates a validation request message that includes the sender ID value, token LD value, and expiration time value from the decrypted token. In block 544, the Receiver sends the validation request message to the Service Operator.
  • the Service Operator determines whether it has processed the same token before and whether the Sender has sufficient credit or funds on deposit to cover its then-current potential penalty liability, including any liability under the then- current message. Such responsive processing may involve the Service Operator performing the steps of blocks 510-520 of FIG. 5A.
  • the message Receiver receives a validation response message from the Service Operator.
  • the validation response message contains data indicating whether the Service Operator has seen the then-current token ID from the then-current Sender in any prior token having the same expiration time value, and whether the Sender of the message has sufficient credit, or funds on deposit, with the Service Operator to satisfy or cover all its outstanding obligations.
  • the Receiver may parse the validation response message, and based on the values contained in it, the Receiver may determine whether to forward the message to its named Recipient, to store the message in a bulk mail folder, to discard the message, etc.
  • Different Receivers may establish, by policy, different responses for various values in the validation response message.
  • FIG. 6 is a flow diagram of an example process for determining whether a received message is acceptable.
  • FIG. 6 represents example process steps that are performed by a Receiver of a message after performing one of the approaches of FIG. 5 A or FIG. 5B.
  • Different Receivers may elect to perform fewer than all the steps shown in FIG. 6, or may elect to perform an entirely different process.
  • the steps of FIG. 6 may be performed in any order.
  • a Receiver determines whether the expiration time of a received message is with a specified range. For example, a Receiver may require that the expiration time value 412 of the then-current message is at least N days in the future, so that sufficient time is available to permit evaluation of the message, and possibly reporting of the message as unwanted, by the end-user or Recipient of the message.
  • the value of N may vary widely depending on whether the Receiver is an individual end user, ISP, enterprise mail server, or other device or individual. For example, N could range from 1 to 120.
  • the Receiver determines whether the bond amount offered or promised by the Sender is greater than a specified amount. For example, the Receiver may require that bond amount offered 414 is at least D, where D is a specified value.
  • D may vary widely depending on whether the Receiver is an individual end user, ISP, enterprise mail server, or other device or individual. For example, D could range from $1 to $100, or equivalent amounts in other currencies. If the bond amount offered or promised is not within the specified range, then control transfers to block 612 in which the message is rejected.
  • the Receiver determines whether the Recipient address matches the destination address of the message. For example, the Receiver compares the Recipient address value 416 to a destination network address found elsewhere in message header 402 or in another header, such as an LP packet header. If no match exists, then control transfers to block 612 in which the message is rejected.
  • the Receiver determines whether the validation response message it received, as part of participating in either the approach of FIG. 5 A or FIG. 5B, contains any indication of a validation failure. For example, the Receiver examines various flag values in the validation response message and determines whether a particular test of FIG. 5 A, FIG. 5B failed validation. If so, then control transfers to block 612 in which the message is rejected.
  • FIG. 7 A is a flow diagram of verifying a report of an unwanted message
  • FIG. 7B is a flow diagram showing additional steps in the method of FIG. 7A.
  • Such a report also may be termed a "complaint.”
  • a Recipient determines that a message is unwanted, the Recipient forwards the message token to the Service Operator and requests the Sender to forfeit the bond.
  • the Recipient may perform such a determination, for example, after receiving a message passed to it by a Receiver that has performed the process of FIG. 6.
  • the Service Operator examines the token and other values to verify the request, and then determines whether to forfeit the bond.
  • the report comprises a message from the Recipient to the Service Operator that includes sender ID value 404, encrypted token 406, and a request to forfeit the bond.
  • the report or complaint also includes a network address of the Recipient, either within the complaint message or within a header of a packet that carries the message. For example, the conventional IP packet header carries the address of the sender of a packet.
  • the Service Operator decrypts the token, as shown in block 704. The Service Operator then performs a series of tests on values in the token and relating to the Submitter.
  • the Service Operator determines whether the token was actually created by the original message Sender. For example, the Service Operator compares sender ID value 408 from the decrypted token to sender ID value 404. If there is a match, then the identified Sender is known to have created the encrypted token. An encryption approach for encrypting token 406 is selected so that it is impractical for a malicious Sender to create a false token, or to decrypt a token and learn the sender LD value 408 therein.
  • sending an error message may include sending an advisory message to the Submitter indicating that the bond will not be forfeited. It may also include sending a warning message to the Sender of the message and recording these actions in a log or other database.
  • the Service Operator determines whether the token is unexpired. Block 708 may involve examining expiration time value 412 and comparing it to a master clock or time value. The time values may be expressed in Greenwich Mean Time, or Service Operator optionally may perform one or more time zone conversion operations. If expiration time value 412 has passed, then control passes to block 718. [0141] Otherwise, in block 710, the Service Operator determines whether the Submitter of the forfeiture request is a valid owner of the address to which the message is directed. For example, the Service Operator examines Recipient address value 416 in the decrypted message token 406 and determines whether the Submitter owns the address.
  • the Service Operator may determine valid ownership by comparing the recipient address value 416 to the known network address of the recipient, based on an address value in the complaint message or a header of the complaint message.
  • determining ownership includes determining whether a party is a valid proxy for an address.
  • the use of a recipient address identifier in token 406 of message 400 prevents a malicious user from spoofing complaints about unsolicited messages by essentially requiring a complaining party to prove that a sender identified in a complaint actually sent the message to the complaining party. For example, a malicious user could prepare software that would automatically generate a large number of identical complaints.
  • the test of block 710 determines that recipient address value 416 does not match an actual address of the recipient, then a fraudulent complaint may be suspected, and control passes to part A of FIG. 7B, which performs error processing.
  • block 712 the Service Operator determines whether the bond amount for the then-current message is not already forfeited. For example, block 712 involves determining whether the bond represented by the then-current token 706 has been forfeited, by checking looking up the token based on its expiration time value and token ID value in a database of forfeited bonds that is maintained by the Service Operator. If the bond associated with the token has been forfeited previously, then control passes to block 718 (FIG. 7B).
  • the tests shown in FIG. 7 may be performed in any order. Further, a Service Operator may elect, as a matter of policy, to perform other tests. [0145] In addition, the process of FIG. 7 may be supplemented with a dispute resolution process that addresses allegedly fraudulent reports of unwanted messages, or reports issued by allegedly fraudulent Recipients.
  • FIG. 8 is a block diagram of a banking network and related elements in relation to the system of FIG. 1A that may be used in certain approaches. The elements of FIG. 8 are not required for any particular embodiment.
  • Message Processing System 106 is communicatively coupled directly or indirectly to a banking network 802.
  • One or more depository institutions such as a Sender's depository institution 804A, Service Operator's depository institution 804B, and other depository institution 804C, are coupled to network 802.
  • Each depository institution 804A, 804B, 804C comprises a bank, thrift, or other institution that receives and holds private funds in designated accounts, such as a securities brokerage, etc.
  • Sender's depository institution 804A holds an account owned by a Sender
  • Service Operator's depository institution 804B holds an account owned by the Service Operator
  • the other depository institution 804C holds one or more accounts that are owned by a Receiver, or a Recipient, or a third party beneficiary 806.
  • penalizing a Sender involves causing the Sender to forfeit all or a portion of a bond that the Sender has posted with the Service Operator. If the Sender has posted a bond with the Service Operator, then forfeiture may comprise performing an electronic funds transfer. For example, the Service Operator causes the Sender to forfeit an amount of value equal to the bond amount that was offered by the Sender in the message token. This may involve transferring funds from an account in Service Operator's depository institution 804B, owned by the service provider and containing funds placed on deposit by the Sender, to an account at the other depository institution 804B or to a designated party.
  • the Sender may involve the Service Operator issuing an invoice to the Sender.
  • the Sender may issue, to the Service Operator, a check or draft drawn on an account in Sender's depository institution 804A. Thereafter, or concurrently, the Service Operator may transfer funds to a Receiver, Recipient, or beneficiary.
  • the penalty amount imposed on a particular Sender for a plurality of identical "spam” messages is capped at a specified maximum penalty value.
  • the Service Operator may penalize the Sender a maximum of $10,000, or some other specified amount, even if millions of identical "spam” messages are sent and only a few "spam” reports are received from Recipients.
  • the penalty amount is tiered, such that the penalty amount increases as specified numbers of "spam” reports are received, or tiered based on the number of "spam” messages that were sent.
  • Penalizing a Sender also may involve determining how to split the fine among one or more parties and distributing funds to such parties, manually or using electronic funds transfers or similar mechanisms. For example, funds, monetary value, or other elements of value representing a penalty against the Sender may be transferred from the Sender, or an account associated with the Sender, to the Service Operator, to a network administrator, to the Receiver, to the Recipient, to the Receiver as a credit for the benefit of an account held at the Receiver by the Recipient (e.g., an end user account with an ISP), to a third party beneficiary such as charitable entity, etc.
  • funds, monetary value, or other elements of value representing a penalty against the Sender may be transferred from the Sender, or an account associated with the Sender, to the Service Operator, to a network administrator, to the Receiver, to the Recipient, to the Receiver as a credit for the benefit of an account held at the Receiver by the Recipient (e.g., an end user account with an ISP), to
  • an amount of the bond that is placed in block 202 of FIG. 2 A, or an amount of the fine that is reserved in block 215 of FIG. 2B, or an amount of a penalize applied to a sender at block 310 of FIG. 3, may be automatically determined using estimation approaches that take into account a number of receiver complaints that are likely to be received for the then-current sender.
  • FIG. 10A is a flow diagram of a first process for messaging processing using an estimation approach.
  • the process of FIG. 10A may be performed by message processing system 106 of FIG. 1 A in response to a query from inbound messaging gateway 110.
  • a receiver such as a message gateway receives a message directed to a recipient.
  • the receiver requests a message processing system to issue an advisory about the received message.
  • the message processing system determines an amount of a bond that has been offered by a sender of the message for all messages that it sends. For example, block 1006 may involve decrypting an encrypted token prepared by the sender of the message that contains a proposed bond amount. In this approach, the offered amount is a total bond amount rather than an amount for a single message. [0155] In block 1008, the message processing system computes a maximum penalty amount that could be applied to the sender if many or all of its messages are reported as unwanted by receivers.
  • the maximum penalty is computed as a base penalty amount multiplied by the sum of (a) a number of complaints about unsolicited messages that are actually received from senders and (b) an estimate of a number of complaints that are not yet made or never made by receivers ("un-filed complaints").
  • the message processing system 106 compares the offered bond amount from the message to the maximum penalty that was computed in block 1008. If the message processing system determines that the difference of the bond amount and the penalty amount so computed is greater than zero, then the message processing system informs the inbound messaging gateway 110 that the sender can satisfy the maximum possible penalty, i.e., that the sender remains bonded, as shown in block 1014. In response, the inbound messaging gateway 110 forwards a received message to recipient 112. Alternatively, if the difference is zero or less, then in block 1012 message processing system 106 may inform the gateway 110 that the sender could not satisfy the maximum anticipated penalty.
  • FIG. 10B is a flow diagram of a first process for messaging processing using an estimation approach.
  • block 1002, 1004, and 1006 involve the same steps as in FIG. 10A.
  • the message processing system computes a bond ratio value as the bond amount offered or posted by a sender, divided by a sum of a number of complaints about unwanted messages that are actually received from senders and an estimate of a number of complaints that are not yet filed or never filed by receivers.
  • Each inbound messaging gateway 110 that accesses message processing system 106 is assumed to establish and store a specified minimum bond ratio amount.
  • the message processing system informs receiver, such as the inbound messaging gateway 110, of the computed bond ratio value.
  • the inbound messaging gateway 110 determines whether the computed bond value is equal to or greater than the specified minimum bond ratio amount of that gateway. If so, then the gateway 110 accepts and forwards the received message to the recipient 112, at block 1028. If not, then at block 1026 the gateway may refuse the message, request message processing system 106 to penalize the sender, block forwarding of the message to the recipient 112, etc.
  • the bond ratio value approach provides added flexibility to receivers, because each inbound messaging gateway 110 among a number of gateways associated with different receivers can set its own specified minimum bond ratio value. For example, one ISP may require that all senders have a bond ratio value of at least 10, and another ISP could require a minimum ratio of 20. Therefore, receivers can customize, to an extent, the operation of message processing system 106.
  • the bond ratio value approach enables a receiver to determine how a first Sender compares in relative terms to a second Sender with respect to actual complaints, rather than simply knowing whether the first Sender can withstand a particular penalty amount as in the approach of FIG. 10 A.
  • a receiver could derive a rating for a particular Sender based on the bond ratio values that are determined.
  • the bond ratio value may be viewed as a sender experience value or rating.
  • the bond ratio value does not incorporate a penalty amount.
  • a bond ratio value provides a way to apply a negative experience rating to a Sender, without actually requiring the Sender to post a bond in advance and without actually debiting funds from or imposing a specific financial penalty on the Sender.
  • a bond ratio value of the Sender is re-computed and stored.
  • the bond ratio value of the Sender may be re-computed to reflect a negative experience with the Sender.
  • penalizing a Sender at block 310 of FIG. 3 may involve re-computing and storing the bond ratio for the Sender without actually imposing a financial penalty on the Sender.
  • the re-computation of a bond ratio also may be performed at block 520 of FIG. 5B to take into account the values of the sender, reply, and credit validation flags; or at block 610, 612 of FIG. 6; or at block 714 of FIG. 7 As the bond ratio worsens, the Sender loses the ability to send messages through gateways that are in contact with message processing system 106.
  • a computation of an estimate of a number of complaints that are not yet filed or never filed by receivers is performed.
  • the computation may be performed using several mechanisms. For example, an estimate may be determined based on volume of messages sent, by selecting an estimate value from a mapping of estimate values to volume levels. Using that mechanism, a Sender who sends 1,000,000 messages in a specified window of time, e.g., 24 hours, could be assigned an estimated number of complaints of 100. Alternatively, if a Sender sends 10,000,000 messages in a 24-hour period, the message processing system 106 may assume that a 1,500 complaints will be received in the future.
  • a specified time window is used because recipients need a certain amount of time to receive, read and evaluate received messages, so a delay of at least several hours to several days could elapse between sending a message and receiving a complaint.
  • the estimated number of complaints could be scaled according to a length of the time window. For example, if the time window is 3 days, then one complaint rate might be applied to the first 24 hours, a second different rate to the second 24 hours, and a third different rate to the third 24 hours, and these three rates may be blended to arrive at an average complaint rate that is multiplied by the message volume to result in a final estimate of complaint volume.
  • These approaches address the potential problem of how to process a Sender that is newly bonded and immediately sends a large volume of messages. Since such a Sender has no historical actual complaint rate, better operation of message processing system 106 and better satisfaction of receivers is expected if some number of complaints is assumed or estimated for a given volume of sent messages.
  • an estimate may be provided by counting an actual number of complaints over a specified window of time, resulting in a historical complaint rate.
  • the estimate may apply a scaling value to the historical complaint rate in order to correlate the complaint rate to the actual number of messages sent by a sender.
  • FIG. 9 is a block diagram that illustrates a computer system 900 upon which an embodiment of the invention may be implemented.
  • Computer system 900 includes a bus 902 or other communication mechanism for communicating information, and a processor 904 coupled with bus 902 for processing information.
  • Computer system 900 also includes a main memory 906, such as a random access memory (“RAM”) or other dynamic storage device, coupled to bus 902 for storing information and instmctions to be executed by processor 904.
  • Main memory 906 also may be used for storing temporary variables or other intermediate information during execution of instmctions to be executed by processor 904.
  • Computer system 900 further includes a read only memory (“ROM”) 908 or other static storage device coupled to bus 902 for storing static information and instmctions for processor 904.
  • ROM read only memory
  • a storage device 910 such as a magnetic disk or optical disk, is provided and coupled to bus 902 for storing information and instmctions.
  • Computer system 900 may be coupled via bus 902 to a display 912, such as a cathode ray tube ("CRT"), for displaying information to a computer user.
  • a display 912 such as a cathode ray tube ("CRT")
  • An input device 914 is coupled to bus 902 for communicating information and command selections to processor 904.
  • cursor control 916 is Another type of user input device
  • cursor control 916 such as a mouse, trackball, stylus, or cursor direction keys for communicating direction information and command selections to processor 904 and for controlling cursor movement on display 912.
  • This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
  • the invention is related to the use of computer system 900 for electronic message delivery approaches.
  • electronic message delivery approaches are provided by computer system 900 in response to processor 904 executing one or more sequences of one or more instmctions contained in main memory 906.
  • Such instructions may be read into main memory 906 from another computer-readable medium, such as storage device 910.
  • Execution of the sequences of instmctions contained in main memory 906 causes processor 904 to perform the process steps described herein.
  • hard-wired circuitry may be used in place of or in combination with software instmctions to implement the invention.
  • embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
  • Non- volatile media includes, for example, optical or magnetic disks, such as storage device 910.
  • Volatile media includes dynamic memory, such as main memory 906.
  • Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 902. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.
  • Computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD- ROM, any other optical medium, punchcards, papertape, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave as described hereinafter, or any other medium from which a computer can read.
  • Various forms of computer readable media may be involved in carrying one or more sequences of one or more instmctions to processor 904 for execution.
  • the instmctions may initially be carried on a magnetic disk of a remote computer.
  • the remote computer can load the instmctions into its dynamic memory and send the instmctions over a telephone line using a modem.
  • a modem local to computer system 900 can receive the data on the telephone line and use an infrared transmitter to convert the data to an infrared signal.
  • An infrared detector can receive the data carried in the infrared signal and appropriate circuitry can place the data on bus 902.
  • Computer system 900 also includes a communication interface 918 coupled to bus 902.
  • Communication interface 918 provides a two-way data communication coupling to a network link 920 that is connected to a local network 922.
  • communication interface 918 may be an integrated services digital network ("ISDN") card or a modem to provide a data communication connection to a corresponding type of telephone line.
  • ISDN integrated services digital network
  • communication interface 918 may be a local area network (“LAN”) card to provide a data communication connection to a compatible LAN.
  • LAN local area network
  • Network link 920 typically provides data communication through one or more networks to other data devices.
  • network link 920 may provide a connection through local network 922 to a host computer 924 or to data equipment operated by an Internet Service Provider ("ISP") 926.
  • ISP 926 in turn provides data communication services through the worldwide packet data communication network now commonly referred to as the "Internet" 928.
  • Internet 928 uses electrical, electromagnetic or optical signals that carry digital data streams.
  • the signals through the various networks and the signals on network link 920 and through communication interface 918, which carry the digital data to and from computer system 900, are exemplary forms of carrier waves transporting the information.
  • Computer system 900 can send messages and receive data, including program code, through the network(s), network link 920 and communication interface 918.
  • a server 930 might transmit a requested code for an application program through Internet 928, ISP 926, local network 922 and communication interface 918.
  • one such downloaded application provides for electronic message delivery approaches as described herein.
  • the received code may be executed by processor 904 as it is received, and/or stored in storage device 910, or other non- volatile storage for later execution.
  • computer system 900 may obtain application code in the form of a carrier wave.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Marketing (AREA)
  • Tourism & Hospitality (AREA)
  • Theoretical Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Operations Research (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Information Transfer Between Computers (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'invention concerne des techniques d'expédition de messages qui permettent aux expéditeurs de garantir le fait que leurs messages soient désirés par les destinataires présumés. Dans un mode de réalisation, un Expéditeur se met d'accord avec un Opérateur de Services pour payer une amende pour chaque message qui aura été indiqué comme non désirable par son Destinataire. Les Opérateurs de Services peuvent offrir aux expéditeurs qui acceptent d'avance de payer une amende des routages de messages préférentiels contournant les filtres anti-spam sur la base de la connaissance qu'une garantie existe. Si le Destinataire indique que le message est non désirable, l'Opérateur de Services peut pénaliser l'expéditeur en lui infligeant une amende pour un montant convenu, ou en modifiant une valeur de notation ou de classement ou une autre estimation d'expérience associée à l'Expéditeur. Les estimations des réclamations attendues pour un Expéditeur donné peuvent servir à déterminer les dénouements des tests appliqués par le Récepteur.
PCT/US2003/037417 2002-11-20 2003-11-20 Expedition de messages electroniques utilisant des techniques d'estimation WO2004046992A2 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP03787031A EP1563435A2 (fr) 2002-11-20 2003-11-20 Expedition de messages electroniques utilisant des techniques d'estimation
AU2003295821A AU2003295821A1 (en) 2002-11-20 2003-11-20 Electronic message delivery with estimation approaches
JP2004570648A JP2006508477A (ja) 2002-11-20 2003-11-20 評価アプローチによる電子メッセージ送付

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US42813402P 2002-11-20 2002-11-20
US60/428,134 2002-11-20
US48288303P 2003-06-25 2003-06-25
US60/482,883 2003-06-25
US10/717,414 2003-11-18
US10/717,414 US7230228B2 (en) 2003-11-18 2003-11-18 Tunable temporal dispersion and compensated angular dispersion in optical switching systems

Publications (2)

Publication Number Publication Date
WO2004046992A2 true WO2004046992A2 (fr) 2004-06-03
WO2004046992A3 WO2004046992A3 (fr) 2004-07-08

Family

ID=32329869

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2003/037417 WO2004046992A2 (fr) 2002-11-20 2003-11-20 Expedition de messages electroniques utilisant des techniques d'estimation

Country Status (5)

Country Link
EP (1) EP1563435A2 (fr)
JP (1) JP2006508477A (fr)
KR (1) KR20060079138A (fr)
AU (1) AU2003295821A1 (fr)
WO (1) WO2004046992A2 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9990464B1 (en) 2012-10-09 2018-06-05 Pall Corporation Label-free biomolecular interaction analysis using a rapid analyte dispersion injection method

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5999967A (en) * 1997-08-17 1999-12-07 Sundsted; Todd Electronic mail filtering by electronic stamp
US6192114B1 (en) * 1998-09-02 2001-02-20 Cbt Flint Partners Method and apparatus for billing a fee to a party initiating an electronic mail communication when the party is not on an authorization list associated with the party to whom the communication is directed
WO2001067330A1 (fr) * 2000-03-09 2001-09-13 Etamp.Com Incorporation Systeme avec tampon electronique pour message publicitaire en ligne et procede d'utilisation de ce systeme
WO2002025464A1 (fr) * 2000-09-21 2002-03-28 Omega Web Inc. Procede et systeme d'elimination d'inondation de courrier electronique
WO2002039356A1 (fr) * 2000-11-01 2002-05-16 Mark Landesmann Systeme et procede destines a octroyer des droits de messagerie electronique subordonnes au versement d'un depot
US6421709B1 (en) * 1997-12-22 2002-07-16 Accepted Marketing, Inc. E-mail filter and method thereof
US20020133469A1 (en) * 2001-03-19 2002-09-19 Patton Charles M. Electronic mail filtering system

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5999967A (en) * 1997-08-17 1999-12-07 Sundsted; Todd Electronic mail filtering by electronic stamp
US6421709B1 (en) * 1997-12-22 2002-07-16 Accepted Marketing, Inc. E-mail filter and method thereof
US6192114B1 (en) * 1998-09-02 2001-02-20 Cbt Flint Partners Method and apparatus for billing a fee to a party initiating an electronic mail communication when the party is not on an authorization list associated with the party to whom the communication is directed
WO2001067330A1 (fr) * 2000-03-09 2001-09-13 Etamp.Com Incorporation Systeme avec tampon electronique pour message publicitaire en ligne et procede d'utilisation de ce systeme
WO2002025464A1 (fr) * 2000-09-21 2002-03-28 Omega Web Inc. Procede et systeme d'elimination d'inondation de courrier electronique
WO2002039356A1 (fr) * 2000-11-01 2002-05-16 Mark Landesmann Systeme et procede destines a octroyer des droits de messagerie electronique subordonnes au versement d'un depot
US20020133469A1 (en) * 2001-03-19 2002-09-19 Patton Charles M. Electronic mail filtering system

Also Published As

Publication number Publication date
AU2003295821A1 (en) 2004-06-15
WO2004046992A3 (fr) 2004-07-08
KR20060079138A (ko) 2006-07-05
JP2006508477A (ja) 2006-03-09
EP1563435A2 (fr) 2005-08-17

Similar Documents

Publication Publication Date Title
US7293065B2 (en) Method of electronic message delivery with penalties for unsolicited messages
US7970832B2 (en) Electronic message delivery with estimation approaches and complaint, bond, and statistics panels
JP4717886B2 (ja) 電子メールを規制する方法及びシステム
US7085745B2 (en) Method and apparatus for identifying, managing, and controlling communications
US9015263B2 (en) Domain name searching with reputation rating
US8126971B2 (en) E-mail authentication
US7970858B2 (en) Presenting search engine results based on domain name related reputation
US20150213131A1 (en) Domain name searching with reputation rating
US20030236847A1 (en) Technology enhanced communication authorization system
US20080235766A1 (en) Apparatus and method for document certification
US20100174795A1 (en) Tracking domain name related reputation
US20090013375A1 (en) Permissions management platform
US20140215571A1 (en) E-mail authentication
US20020133469A1 (en) Electronic mail filtering system
US20140317211A1 (en) Messaging stamp authority
US8069118B2 (en) Mediated electronic messaging with value-added services
EP1563435A2 (fr) Expedition de messages electroniques utilisant des techniques d'estimation
AU2004216700B2 (en) Method and apparatus for identifying, managing, and controlling communications
Loder et al. The spam and attention bond mechanism faq
Yuan Fight For Spam
KR20050098452A (ko) 스팸 방지 방법과, 프로그램, 기록매체, 장치
Schryen Preventing E-mail Spam: The Conceptualization and the Analysis of an Infrastructure Framework
KR20030060829A (ko) 스펨 보상 인증, 저당, 보상 처리를 하는 방법과프로그램과 매체와 장치
NZ548629A (en) Spam prevention

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2004570648

Country of ref document: JP

Ref document number: 1020057009227

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2003295821

Country of ref document: AU

WWE Wipo information: entry into national phase

Ref document number: 2003787031

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 20038A88217

Country of ref document: CN

WWP Wipo information: published in national office

Ref document number: 2003787031

Country of ref document: EP

WWR Wipo information: refused in national office

Ref document number: 2003787031

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2003787031

Country of ref document: EP