An architecture for spam regulation.

• Author: Dickinson, David

1. INTRODUCTION II. BACKGROUND A. The Spammers' Tools B. The Case for Spam Regulation III. LEGAL HISTORY A. Common Law Remedies B. Legislative Responses C. First Amendment Concerns D. Industry's Response IV. ARGUMENT A. Governing Principles B. A Different Approach 1. Technical Overview 2. Extending the Authentication-Based Framework 3. Proposed Regulatory Framework 4. Defining "Bulk" 5. Enforcement Procedures and Penalties 6. Global Implementation C. Scrutiny of Proposed Architecture 1. Narrowly Tailored to Spam 2. Privacy Preserving 3. Transparency 4. A Functional Opt-out System 5. Enforceability 6. Cost-Effectiveness D. Avoiding the Pitfalls of ICANN V. CONCLUSION "Architecture becomes the tool of law when the direct action of the law alone would not be as effective."--Lawrence Lessig (1)

1. INTRODUCTION

   Both legal and technical attempts to regulate spam (2) have proliferated in recent years. As the problem of spam has grown to 12.4 billion messages per day, (3) legislatures, Internet service providers ("ISPs"), and software developers have all tried various responses. Legislative responses have culminated in the Controlling the Assault of Non-Solicited Pornography and Marketing Act ("CAN-SPAM Act") of 2003. (4) Numerous e-mail clients now include spam filters, and ISPs are using both technical and legal means to strike back at spammers. Indeed, the Online community appears quite united in its contempt for spam.

   In spite of the numerous attempts to regulate spam, the problem has not diminished. The spammers continue to win the war in spite of the Internet community's best efforts. The recent CAN-SPAM Act has had little effect. (5) Legislative responses are limited by jurisdictional obstacles to enforcement and the technical measures taken by spammers to disguise their source and identity. Technical approaches to dealing with spam, such as spam filters and blacklists, have probably been more successful, but have also faced their share of problems. Spam filters often struggle with filtering too much or too little. (6) Furthermore, filters fail to deter future attempts, and spammers often find ways to circumvent the filters. Blacklists and similar approaches represent an Online form of vigilantism with many side effects. (7) Innocent parties often have their messages blocked, (8) and there are few safeguards to make sure that parties are only being blacklisted for good cause. (9) David Sorkin has suggested that the "[c]oordination of technical and legal mechanisms seems to be the most promising approach to the spam problem." (10) Despite the fact that many people would agree with Sorkin, legislative and technical approaches to stopping spam have yet to be coordinated. Sorkin suggests that this is because the consensus required for such coordination is unlikely to be achieved. (11)

   This Note argues that the universal low regard for spam makes such coordination possible. Instead of making architectural changes that enforce a particular legislative approach to spam, the focus should be an architectural approach that enables both ISPs and end-users to more effectively identify and filter unwanted spam. The law is not excluded from this solution, rather it has an important role to play in enabling it.

   This Note begins by outlining the techniques employed by spammers to evade both technical and legal countermeasures, then goes on to explore the costs spam shifts from mailers to recipients. The First Amendment constraints placed upon any regulatory model are outlined, followed by a suggested regulatory and architectural framework that could enable a substantial reduction in spam while leaving filtering decisions in the hands of individual e-mail users. The suggested architectural framework builds upon several authentication-based systems being proposed by private industry, but suggests key changes that can be made to afford more First Amendment protection to e-mail and to allow individuals greater autonomy in determining what e-mail they will receive.

2. BACKGROUND

   1. The Spammers' Tools

      In order to understand the problem of spam, it is helpful to understand the methods employed by spammers to exploit the e-mail medium. E-mail operates on the Simple Mail Transfer Protocol ("SMTP"). (12) The protocol was written in 1982, (13) well before the problem of spam was a concern. As a result, SMTP was not designed with the problem of spam in mind. No allowances were made for the need to authenticate users, verify identity, and guarantee message privacy or integrity. The only way recipients can determine the source of spam is to rely upon the "From:" field and "Received:" headers. (14) A sample, excerpted from Stopping Spam, is shown below:

      From you@earth.solar.net Sat May 9 12:40:45 1998

      Received: from jupiter.solar.net (jupiter.solar.net [1.4.4.7]) by pluto.solar.net (8.8.7/8.8.7) with SMTP id KAB00332 for ; Sat, 9 May 1998 12:40:45 -0600

      Received: from earth.solar.net (earth.solar.net [1.4.4.4]) by jupiter.solar.net (8.8.8/8.8.8) with SMTP id MAA00395 for ; Sat, 9 May 1998 12:40:40 -0600

      Date: Sat, 9 May 1998 12:40:30 -0600

      From: you@earth.solar.net

      To: Chris

      Subject: Steel Pulse concert date

      Message-ID:

      X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0

      X-UIDL: 179c97f481a77a5da1a8109409a00afe

      Hi Chris! (15)

      The "From:" field is the most obvious method of identifying the sender, but it is also a very unreliable way. It can be easily forged by the message sender. (16) Spammers rarely use an address they can be reached at in the "From:" field, and quite often, the address has either been made up or is the e-mail address of some innocent party. The "Received:" headers are a more useful method of identifying spammers. A "Received:" header is added by each host that relays the message from its source to its eventual destination. Each of these headers lists the name and address of a system that relayed the message, as well as the name and address of the system that just passed it the message. Spammers cannot prevent intermediary systems from adding these headers. The headers still provide only minimal protection because a thorough examination of the "Received:" header will be required to identify the real source of the message.

      Two well-known techniques utilized by spammers to confuse message recipients are using open relay sites (17) to send their messages (18) and adding "Received:" headers of their own creation when sending a message. Open relay sites are servers that allow themselves to be used by unknown computers to send e-mail messages. Mail can be traced back to these relays, but it is unlikely that the relay operator will be able to identify the system that passed it the message. While servers that allow relaying are becoming less common as a result of the spam problem, they still exist and are well-known by spammers. These relay sites are often blacklisted, meaning that certain ISPs will not accept messages from them. (19) While this is helpful, it has the effect of blocking not only spam, but also legitimate messages by other senders that may depend on the relay for mail transport. (20)

      The second technique is the adding of bogus "Received:" headers. However, this technique is less effective. The bogus headers add erroneous information, but are not able to prevent the addition of accurate "Received:" headers. This means a recipient can rely on the header that his own server added (jupiter.solar.net in the example) and work back from one header to the next, identifying whether the server is one he trusts at each step. (21) The message "id" can be used to verify the authenticity with the administrator at each intermediary. Eventually, the false headers can be identified.

      Unfortunately, identifying the source mail server does not identify the person and computer that actually authored and sent the message. In some instances, the administrator of the source server will be able and willing to identify the culprit, but in others, an administrator will be unwilling or unable to do so. Regardless of how many ISPs are now actively disabling the accounts of their customers who are sending spam, there are still ISPs and open relays in the United States and abroad that are unwilling to cooperate.

      Spammers have been growing increasingly bold in their attempts to send spam. A new technique being relied upon is to create spam zombies. Spam zombies are computers owned by innocent third parties that are hacked and used by spammers to send spam. (22) The owners of these spam zombies are typically unaware that their machines have been taken over until their ISP terminates their account. (23) The hacker who exploits these third-party computers may be difficult or impossible to identify.

      The architecture underlying e-mail has not been conducive to effective spam regulation. Spam can often be filtered or blocked, but the underlying architecture of e-mail provides an effective barrier between law enforcement and the perpetrators of spam. Before spam can be effectively regulated, there must first be changes to the architecture underlying e-mail. The architecture must be adapted to provide the ability to identify and authenticate the senders of spam.

   2. The Case for Spam Regulation

      The magnitude of the spam problem has grown steadily since the emergence of the World Wide Web. During the one year from the summer of 2001 to the summer of 2002, spam increased by 450 percent. (24) Spam is highly problematic because it frequently features pornographic content; unsolicited, commercial advertisements; and fraudulent, get-rich-quick schemes; all sent from a carefully disguised source. Spam also represents a computer security risk. (25) Mass e-mails are a frequent source of computer viruses. (26) Increasingly, these viruses then turn infected computers into spammers. (27) Legitimate businesses have avoided the use of unsolicited spam to a large extent. They are motivated by the fear of generating ill will among potential customers or...