An Automation of Mail Channels Nicholas M. Boers and Pawel Gburzynski Department of Computing Science University of Alberta Edmonton, AB T6G 2E8 E-mail: {boers,pawel}@cs.ualberta.ca Abstract— Mail channels allow an electronic mail (e-mail) user to have multiple points of contact, each with a potentially different policy. For example, a user may have two channels, one for personal use and one for business use. The former channel’s policy may accept all senders and the latter channel’s may restrict senders to those within a given company. By extending this example, an e-mail user can have a channel unique to each contact. Each of these channels may have a policy that limits its use to the particular contact. Traditionally, this scenario requires substantial administrative overhead, making it impractical. The system proposed here, the Spam Free Mail (SFM) service, 1 automates the creation of mail channels. SFM’s restrictive mail channels effectively eliminate a considerable part of e-mail abuse, such as spam and phishing. I. I NTRODUCTION The term channel can describe a medium through which information travels. For example, radio and television have multiple channels (i.e., stations). Consumers isolate informa- tion of interest by selecting appropriate stations. A simple extension of the same concept creates channels for electronic mail (e-mail). They are known as mail channels. Many of the existing mail channel implementations [1]– [4] require substantial administrative overhead. Users must create channels manually. The system proposed here supports the automatic creation of mail channels in two instances. Users implicitly create them when they send mail to new correspondents. External users initiate their creation when they first send mail to users of our system. We use Completely Automated Public Turing Tests to Tell Computers and Hu- mans Apart (CAPTCHAs), also known as Human Interaction Proofs (HIPs), to limit their creation. Consequently, our system prevents much e-mail abuse. Section II describes key components in the evolution of mail channels. Given that background information, Section III introduces the Spam Free e-Mail (SFM) service, our solution to mail channels. Section IV describes related work and its similarities with SFM. In Section V, we indicate our direction for future work. Finally, Section VI provides a summary of this paper. II. PREVIOUS WORK In 1982, Denning [5] described a “tidal wave of electronic junk mail” entering his mailbox. To solve the problem, he envisioned multiple e-mail paths (or mail channels), each for a specific type of e-mail. The mail system would always deliver 1 See http://sfm.cs.ualberta.ca. messages arriving on some paths (e.g., urgent, certified, and personal). It would filter messages arriving on all other paths. He observed that existing organizations already meet these requirements for (non-electronic) communications paths. He suggested that the research community should study these traditional paths when developing a solution to the junk mail problem. Borenstein and Thyberg [1] address the creation of a mail channel in the context of the Andrew Messaging System (AMS). The system received a large number of e-mails asking for end-user support, prompting the creation of the Advisor service to help manage the volume. An early version of Advisor (II) searched a message’s subject for keywords in an attempt to channel e-mail to the appropriate support staff. Unfortunately, users rarely included appropriate key- words and messages were seldom channeled correctly. A later version, Advisor III, replaced subject keywords with extensions to the recipient e-mail address. An address’s form became user+extension, where extension specified a mail channel. Hall [2], [3] extends the mail channel idea to pre- vent unwanted e-mail. In his system, an address’s form is user-extension-@host. Extensions are pseudo-random text (cryptographically secure BlumBlumShub [6]) to reduce the probability of guessing an open channel. To manage the complexity of many channels, he developed a Personal Channel Agent (PCA), which essentially acts as an e-mail proxy. Sitting between the user’s mail client and the mail server, the PCA’s primary function is rewriting addresses (i.e., ensuring that an incoming or outgoing message uses an appropriate extension). His system uses three channel classes (i.e., policies): (1) send only, (2) private, and (3) public, with the possibility for additional classes. Send only channels support only outgoing e-mail, as their name suggests. Private channels maintain, and only accept mail from, a set of known correspondents. Public channels are accessible to anyone, much like a traditional e-mail address. We see three fundamental weaknesses in Hall’s system. First, users must manage channels through the PCA’s ad- ministrative interface. The manual opening, closing, creating, deleting, or switching of channels can be time consuming, particularly for a large number of channels. Second, messages rejected on a channel (e.g., an unauthorized sender on a private channel) result in a bounced “no permission” message. Suppose User a uses Hall’s system and regularly communicates