1. PROJECT PENNY BLACK SUBMITTED BY AJENDRA SAKLANI 29404

2. Anyone who addresses the issue of spam, those unwanted e-mails offering cheap credit and better sex, immediately runs up against the two factors that make spam so prevalent: millions of copies made by computers at high speed and virtually zero cost. As processing speeds rises, computers can do things quicker and quicker. As the cost drops to zero, people will consume more of a good or service. To attack the problem, one must slow down the computer or raise the cost. INTRODUCTION

3. Penny Black named after the postage stamp that changed Britain's mail system in the 1830s, merely makes the sender pay, not in money, but in computing resources. The introduction of the Penny Black stamp played an important role in the reform of the British Postal System during the 1830's. Before this time, postage fees were based on weight and on distance involved. Postage had to be calculated for each letter, and was typically paid by the addressee. The introduction of the Penny Black shifted the cost of postage to the sender and eliminated the complexity of postage computation by requiring a uniform, low rate.

4. DEVILS OF THE NICKNAMED MONSTER, SPAM Industry: cost in worker attention, infrastructure individuals: increased ISP fees hotmail: huge storage cost ruining email, devaluing internet One figure: $7 in lost productivity per spam, probably due to interruption in worker attention. Another figure: estimated $2-3 increase in ISP costs per user per month, just for the infrastructure

5. Internet Welfare Community has two Weapons in its Arsenal: Filtering Everyone: text-based Brightmail: decoys; rules updates Microsoft Research: (seeded) trainable filters SpamCloud: collaborative filtering SpamCop, Osirusoft, etc: IP addresses, proxies. Make Sender Pay Computation [Dwork-Naor’92; Back’97] Human Attention [Naor’96, SRC patent] Money [Gates’96] and Bonds [Vanquish]

6. The approach requires a sender's computer to solve a cryptographic puzzle before it puts the e-mail through, something it can do in 10 or 20 seconds. For the sender of a single e-mail, this is a negligible delay. For someone who sends millions, this is crippling. With 80,000 seconds in a day, the 10-second delay caps the number of e-mails that a single machine can send at 8,000. Spammers send far more than that now. In a nutshell, the idea is this: "If I don't know you, and you want to send me mail, then you must prove to me that you have expended a certain amount of effort, just for me and just for this message." THE PENNY BLACK PROJECT

7. The Penny Black project has investigated several techniques to reduce spam by making the sender pay. currencies for payment: CPU cycles Memory cycles Turing tests (proof that a human was involved) There are multiple system organizations that can support this: senders can pre-compute the appropriate function, tied to a particular message. senders can come up with the payment in response to a challenge after they've submitted their message. senders can acquire a ticket pre-authorizing the message. Recipients would aggressively safe-list good senders.

8. COMPUTATIONAL SPAM-FIGHTING Proposed by Dwork and Naor over a decade ago. Computational spam-fighting is a practical but frequently misunderstood way to reduce unwanted electronic mail without significant changes to the existing email infrastructure. The sender attaches to a message a computational proof of effort specific to the message, sender, receiver, and date, and the receiver verifies that the required computation has been performed.

9. In particular: (1)No money is charged under the computational approach. (2) No challenge-response mechanism( additional communication between the sender and the receiver) is required. (3) No third party is required for electronic mail communication. (4) Control of mail servers remains as it is now, with users and their delegates. (5) Once in place, virtually no maintenance is needed (unlike spam filters that need constant updates).

10. TICKET SERVICE We might use a function that’s designed to incur delays based on the latency of memory systems. We might hope to force the sender to consult a human for each message by using a Turing test. We might also rely on real money, and use a proof-of-purchase receipt as the proof. In all these cases, after the cost has been incurred the sender can assemble proof that it has been incurred. In this paper we call any such proof a “ticket”. In all these schemes, it is critical that the sender can’t use the same ticket for lots of messages.

11. Unfortunately, this means that the sender must incur the cost after composing the message and before committing the message to the email delivery system. The sending human must wait for the cost to be incurred before knowing that the message has been sent. By introducing a stateful server, we allow the sender to acquire tickets independently of a particular email message. Instead, the ticket server maintains a database of tickets issued. When a recipient receives the email, he calls the ticket server to verify that the ticket is not being reused, and to update the ticket server’s database to prevent subsequent reuse. The operation of the ticket server is reminiscent of how postage stamps work.

12. Introduction of a stateful server allow us to provide three key benefits: (1) Asynchrony: senders can incur the cost well before composing or sending the email. (2) Stockpiles: users can maintain a stockpile of tickets for future use. (3) Refunds: having a stateful server allows us to introduce the notion of an “account” for a user. This provides a small convenience for the sender, as a way for managing the user’s stockpile of tickets. But it also enables a new feature: if a recipient receives a ticket with an email from a sender, and the recipient decides that the email didn’t need to be paid for, then the recipient can refund the ticket to the sender, by telling the ticket server to do so.

13. Application to Spam Reduction To use the ticket server for spam reduction, an email recipient (or his ISP) arranges that he will see only messages that either have a valid ticket attached, or are from a “trusted sender”.

14. Variation 1: Trusted Sender, but No Ticket When a message arrives with no ticket attached, but from a trusted sender, the message appears in the recipient’s inbox in the usual way. The ticker server is not involved at all. Variation 2: Trusted Sender with a Ticket Attached When a message arrives with a ticket attached from a trusted sender, it appears in the recipient’s inbox in the usual way. Additionally, the ticket server is told that it should refund the ticket, crediting the sender’s account. Variations of the Basic Scenario

15. Variation 3: Untrusted Sender with a Ticket Attached When a message arrives with a ticket attached from an untrusted sender, the recipient’s ISP calls the ticket server’s “Cancel Ticket” operation, to verify and cancel the ticket. If the ticket is invalid or previously cancelled, the message is silently discarded. Otherwise, it appears in the recipient’s inbox. If the recipient decides that the sender should indeed pay for the message, he need do nothing more. However, if the recipient decides that this message wasn’t spam, the recipient can choose to call the ticket server’s “Refund Ticket” operation, to refund the ticket’s value to the sender.

16. Variation 4: Untrusted Sender and No Ticket When a message arrives without a ticket attached and from an untrusted sender, the ISP might choose to respond in one of two ways.  First, the ISP might treat the message as suspicious, and flag it but nevertheless deliver it to the recipient. Here the sender chooses to use a previously acquired ticket, he simply provides it to the ISP by passing it over HTTP to the ISP (perhaps through an HTML form provided as part of the bounce message). On receipt of this, the ISP calls the “Cancel Ticket” operation to verify and cancel the ticket, and provided this succeeds, makes the message available to the recipient’s inbox.

17.  The ISP could hold the message (but invisibly to the recipient) and send a bounce email to the sender. The bounce email would offer the sender two choices: he can provide some previously acquired ticket, or he can acquire a new ticket by interacting with the ticket server. Here he must call the ticket server. To simplify doing so, the bounce email contains a link (URL) to the ticket server. Clicking on the link performs a “Request Ticket” operation at the ticket server. The result appears to the sender as a web page describing the available challenges. If a message remains in the “held” state too long without the sender responding to the bounce message, it is silently discarded by the ISP. The same happens if the sender failed to provide an appropriate return address, or if the sender responds to the bounce message with an invalid ticket.

18. THANK YOU