Email licensing

Email licensing

ARTICLE IN PRESS Journal of Network and Computer Applications 32 (2009) 538–549 Contents lists available at ScienceDirect Journal of Network and Com...

1013KB Sizes 1 Downloads 111 Views

ARTICLE IN PRESS Journal of Network and Computer Applications 32 (2009) 538–549

Contents lists available at ScienceDirect

Journal of Network and Computer Applications journal homepage: www.elsevier.com/locate/jnca

Email licensing Yuh-Jzer Joung , Chu-Jui Yang Department of Information Management, National Taiwan University, Taipei, Taiwan

a r t i c l e in f o

a b s t r a c t

Article history: Received 22 October 2007 Received in revised form 21 August 2008 Accepted 6 November 2008

We propose a framework, email licensing, that allows email users to determine whose messages and in what content and conditions are authorized to come into their inboxes. The idea is to treat email address as a data owned by the addressee, and any use of the data (that is, to send messages to the addressee) must be authorized by the person through the issue of licenses. Subject to laws, an email license (EL) represents a legal agreement between the sender and the recipient upon what type of messages can be delivered, and in what restrictions. EL also enables commercial email senders to adopt a more constructive and legitimate approach to deliver their emails by negotiating with and crediting their customers in reading their emails. & 2008 Elsevier Ltd. All rights reserved.

Keywords: Unsolicited emails Spam Email licensing Personal data licensing

1. Introduction Unsolicited emails or spams used to be thought of as just a nuisance, but the problem has now reached epidemic proportions, a nightmare for every email user. According to MessageLabs, May 2003 marked the first time that unsolicited emails surpassed legitimate emails in volume (Olsen, 2003). The spam rate continued to rise, and it reached 72.9% in October 2006 (MessageLabs, 2006). MAAWG (Messaging Anti-Abuse Working Group) also reported that about four emails were blocked or tagged as abusive for every unaffected email that was delivered to customers in major Internet Service Providers (ISPs) and network operators, representing 80% of their traffic (MAAWG, 2006). This is in concord with IronPort’s study that global email is currently made up of only about 20% legitimate messages (Miller, 2006). Thus, the entire email infrastructure is clearly overwhelmed by the spam deluge. Email abuse is not only an annoying problem. Ferris Research estimated that corporations around the world in 2005 incurred $50 billion in spam-related costs (Ferris Research, 2005), which included lost productivity, network system upgrades, unrecoverable data, and increased personnel costs. The costs could go over $113 billion by 2007, taking a serious economic impact to the world. Email abuse has also posed considerable threats to security and privacy. For example, computer viruses like Sobig.F (Musil, 2003) can create an enormous number of emails to paralyze the system; ‘‘password harvesting fishing (phishing)’’ mimics com-

 Corresponding author.

E-mail addresses: [email protected], [email protected] (Y.-J. Joung), [email protected] (C.-J. Yang). 1084-8045/$ - see front matter & 2008 Elsevier Ltd. All rights reserved. doi:10.1016/j.jnca.2008.11.003

mon and accepted Web sites, luring unwary consumers to enter confidential information to defraud them (McMillan, 2006); and pornographic and harmful message contents are delivered to the youths (DelConte, 2006). Several measures have been taken to stop email abuse, but so far none of them is very effective, suggesting that a significant shift of approaching the problem might be worth a trial (Pfleeger and Bloom, 2005; Cerf, 2005). We believe that a right solution must tackle the problem from all the three perspectives: technological, legislative, and economic. This is because the fundamental problem in email abuse is that anyone who knows your email address can send an email to you. So technologies are needed to filter out unwanted mails. However, technologies alone are more or less a defensive approach. There is an undeniable huge business potential in online marketing.1 A more constructive approach thus is to incorporate some business model into current email system so that both the email marketers and recipients can benefit from their email communications. Moreover, the appropriateness of message content and its value is subject to individuals, and so any solution to curb email abuse must reflect this diversity. This means that some consent must be established between the sender and the recipient about what messages can be delivered. Such consent is practically effective only if it can be enforced by laws. Finally, we notice that one of the main reasons for email being so successful and effective is its simplicity. Therefore, any measure to stop email abuse must not alter this, or

1 See ‘‘Email Marketing Stats, Facts and Metrics—Metrics 2.0 Quick Pack’’, http://www.metrics2.com/blog/2006/11/07/email_marketing_stats_facts_and_metrics_ metrics_20.html.

ARTICLE IN PRESS Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

else it may jeopardize the popularity of email usage or dooms to fail. In this paper we propose a framework called email licensing that allows email users to determine whose messages and in what content and conditions are authorized to come into their inboxes. Email licensing is based on Online Personal Data Licensing (OPDL) (Cha and Joung 2002, 2003; Joung and Cha, 2008). The idea is to treat email address as a data owned by the addressee, and any use of the data—that is, to send messages to the addressee—must be authorized by the person through the issue of licenses. An email license (EL) represents a legal agreement between the sender and the recipient upon what type of messages can be delivered, and in what restrictions. It can be issued only by the email addressee. Therefore, the email addressee can have complete control on what to receive and when to receive from a sender. For example, an EL may specify that commercial emails can be sent only during the weekend, and no more than three messages per week. It can further classify what type of product information a message may contain. Email licensing allows an email sender and the recipient to negotiate a license both parties can accept. The negotiation provides an ‘‘opt-in’’ mechanism for the recipient to decide whether or not to receive messages from email marketers before the messages can bother him. In the negotiation, email marketers can provide some incentives in their proposals such as credits, coupon, or even e-cash to attract the recipient. They can also customize their proposals according to the recipients’ preferences and background. As such, email marketers can better find their customers and make their marketing more cost effective without violating anti-spam laws. Finally, email licensing can be easily implemented as an add-in on users’ mail clients without changing the fundamental structure of current email system, thereby increasing the possibility of its successful deployment. The rest of the paper is organized as follows: Section 2 reviews current approaches for coping with email abuse; Section 3 presents our email licensing architecture and the detailed design; Section 4 presents an implementation of email licensing in Microsoft Outlook mail client; and finally Section 5 concludes and provides some directions for future work.

2. Related work Existing measures for curbing email abuse can be classified into technological, legislative, and economic. In the following we briefly survey them and compare their pros and cons. 2.1. Technological measures Technological measures rely on software or hardware to stop spam or help users distinguish spam from legitimate emails. By functioning at different stages of email processing, technological approach can further be categorized into blocking and filtering. Blocking rejects a message before it is transmitted to the recipient’s mail server. It is often based on from where the message originates or claims to be. Filtering tends to be more thorough as it can examine every detail of a message. To begin with, we first observe that the standard Internet protocol for transmitting emails—Simple Mail Transfer Protocol (SMTP)—was designed more than two decades ago during which the Internet environment was quite simple. So the protocol lacks a comprehensive way to verify a sender’s identity. Spammers now use this weakness to forge their domains and email addresses, known as ‘‘domain spoofing’’. Several approaches have been proposed to enhance sender authentication for SMTP, among which Sender Policy Framework (SPF) (Wong and Schlitt, 2006),

539

Sender ID (Lyon and Wong, 2006), and Yahoo’s Domain Keys (Yahoo; Allman et al., 2007) are popular ones. SPF and Sender ID require domain owners to publish their legitimate mail servers in their DNS records. Email receivers can then use the information to verify if an email comes from a legitimate mail server it claims. DomainKeys (Yahoo) uses the public-key authorization scheme to certify email senders and their contents. Each email is hashed and digitally signed by the private key associated with the domain it originates. The digital signature is attached in the email so that the receiving SMTP server can use it to verify if the email comes from the purported domain and remains intact in transit. The public key of the domain can be obtained from the DNS record the domain publishes. One may recall that the idea of using digital signature to authenticate emails has also been used in Pretty Good Privacy (PGP). Note that both techniques prevent forged emails from claiming where they are from, but they do not prevent abusive behaviors. In fact, it was reported that in a recent collection of 400,000 spams, 16% of them were from spammers who had complied with Sender ID like approaches (Claburn, 2004). Some ‘‘blacklists’’ may therefore be consulted to block notorious spam sources (Cole, 2007). The technology is typically built on top of DNS (henceforth the term ‘‘DNSBL’’) to block the delivery of messages coming from a listed site. SpamHaus BlackHole List (SBL) and Mail Abuse Prevention Real-time BlackHole List (MAPS RBL) are two wellknown spam source report lists. A common problem of the approach is the lack of a standard policy for listing sites, and the lists are usually maintained manually, and so may not be up-todate as spammers can change their addresses or apply a new domain. For example, a statistic shows that the average length that a domain was advertised in a ‘‘spam’’ URL was 48 h in June 2005, but the duration dropped to less than 4 h a year after (IronPort, 2006).2 As blacklists may not be able to block new spam servers in time, ‘‘greylisting’’ has been proposed to temporarily reject emails sent from unrecognized addresses (Harris, 2003). This is based on the observation that most spam servers will not bother to resend undeliverable emails. In contrast, legitimate servers will most likely to resend later, at which time the emails will be accepted by the destination employing greylisting technology. Even if spam servers do resend, the delay between the two delivery attempts allows DNSBLs to list them in blacklists. The main disadvantage of this technique, however, is that email communication may not be near-instant and reliable. This can be a particular nuisance when emails are used by a web site to verify its new users, where they must activate their accounts through the links sent by the web site before they can use the site’s service. Filtering distinguishes spam from legitimate messages by identifying some common characteristics of spam. It is by far the most popular approach to combat spam.3 Several techniques have been developed, including checksum, rule-based, and content filtering. Checksum filtering (e.g., Rhyolite Software; Prakash) is based on the fact that all messages sent by the same spammer will be almost identical and so can produce the same checksum. Checksums are stored at some central database servers to let email receivers compare with what they have received. Email recipients can also nominate a message as being spam to the servers. A countermeasure of this approach, however, is to insert

2 Worse yet, due to a grace period, applying a domain could cost spammer nothing. In April 2006, over the 35 million domains registered, 32 million of them were never paid for before they expired after five days (IronPort, 2006). 3 See ‘‘Tips and help for regular users,’’ http://spam.abuse.net/userhelp/, for a rich list of available tools and products.

ARTICLE IN PRESS 540

Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

different gibberish in spam messages to produce different checksums. Rule-based filtering (e.g., SpamAssassin) discovers spam features based on a wide range of heuristic tests. By assigning a numerical score to each rule, every incoming message is scanned according to the rules to get the total score, and some threshold is given to determine if the message is spam. An appropriate setting of the threshold requires some experiences, or otherwise false positive or false negative conditions may occur. Content filtering is the most basic and typical filtering measure against spam. It examines all the details of an email message, and searches for specific words (e.g., Viagra) to decide whether it is spam. Email server administrators can also list possible spam-like words in the filter configuration. However, some terms like ‘‘mortgage’’ may mislead the system to filter out legitimate financing information, and spammers can also deliberately misspell some keywords to bypass the filter. The above filtering techniques are sort of ‘‘static’’ (Yoke and Tan, 2004) because they rely on humans to set up the filtering conditions beforehand and to continually maintain them. A more sophisticated approach is to make filters ‘‘adaptive’’ and ‘‘automatic’’. For this, techniques developed in document classification and machine learning have been borrowed to design a Bayesian-based statistical filter (Sahami et al., 1998). Following (Graham’s (2002)) influential article, statistical filtering has now become a very popular filtering technique. Recipients need to train their statistical filters by telling them which received messages are spam and which are not. Software programs that implement statistical filtering include Bogofilter, SpamByes, CRM114, Mozilla Thunderbird, and later revisions of SpamAssassin. The advantage of statistical filtering is that, once set up, it requires no further maintenance per se; instead, users mark messages as spam or non-spam and the filtering software learns from these judgments automatically. Even though spammers change email content constantly, statistical filters will learn and respond quickly. Moreover, statistical filtering is totally based upon its user’s feedback and preference, thereby reflecting the end user’s biases for email content. The countermeasure to statistical filtering is to invisibly insert many random but valid words into the messages, making them easily classifiable as legitimate emails. Spammers can also make their messages so short that statistical filters do not have sufficient words to determine if they are spam. For example, spammers use some symbols such as ‘‘*’’ to constitute a Viagra pattern in their message and append a URL link to bypass the statistical filters. A new strain to circumvent filtering techniques is to use images. According to IronPort (2006), image-based spam has jumped from about 1% of all spam messages in June 2005 to around 12% today. In addition to the above blocking and filtering technologies, systems like IM2000 (Bernstein, 2000) and DiffMail (Duan et al., 2005) attempt to curb spam by altering the ‘‘push’’ nature of email communication to ‘‘pull’’. The motivation is that spam consumes a lot of costs on the receiving side to process and store the emails. The burden can be shifted to spammers if we let senders’ mail servers maintain their outgoing messages. The receiver gets only a short notification about an incoming message, and can retrieve the complete message body if and when he wishes to do so. In this way, the servers must also be kept online in order for the recipients to be able to retrieve their emails, thereby increasing the chance for spamers to be blacklisted. However, some may argue that in today’s technology, the hardware cost to store and process spams is really insignificant compared to the annoyance factor of having to manually scan through and delete spams just to find the useful messages in one’s inbox (Candler, 2005). Note that

this approach is also related to the economic measures we shall be discussing shortly in Section 2.3. Other, but less popular, techniques include challenge-response (C/R) (Mastaler; Seigneur et al., 2004) or relying on a third-party to certify their messages. In C/R systems, senders not on the whitelist are required to respond to an automatically generated reply to prove their validity, or to carry out some computation that would cost a spammer nontrivial efforts to deal with its challenges (Denny et al., 2006) (see also the economic solutions in Section 2.3). Care must be taken to the use of C/R systems, for otherwise they could lead to, e.g., deadlock, denial of service to an innocent third party, and excessive burden to mailing list (Templeton; Self, 2004). For third-party solutions, Habeas Inc. uses a copyrightable haiku in message headers to certify legitimate senders. IronPort’s Bonded Sender program guarantees the quality of commercial emails by requiring bulk senders to follow some guidelines, or else a charge will be made against the financial bond they post. Note that different techniques may be combined to increase their effectiveness, as no filtering or blocking technique is perfect, whitelist can be incorporated to ensure that messages from a precompiled list of addresses or domains will arrive at the receiver. Whitelist, in turn, needs some authentication mechanism to prove that a message is sent from where it claims to be. Still, all of the above measures lack an interactive mechanism for email recipients to regulate the practice of sending emails. Kaushik et al. (2005) propose a policy-based approach to control whether a message is delivered. For example, a recipient may specify a policy to its mail server that a message is delivered only if the sender is authenticated, has a low score on a Bayesian filter, and is trustworthy. A feedback message can also be sent to allow a sender to refine his rejected message. This approach is very general, and can even be combined with the economic approach to allow a policy to express, say, the need of a monetary bond in a message. Our email licensing scheme shares with this promising approach in that both allow end users to gain complete control on their mailbox in determining what messages they wish to receive. The main difference is that a policy is a general rule expressing what a recipient wants, while a license is an agreement between two communication parties in how they wish to communicate. A license is also a legal document that can be enforced by laws.

2.2. Legislative approach In addition to technological approaches, legal measures have been taken to outlaw email abuse. In America, the CAN-SPAM Act of 2003 (Controlling the Assault of Non-Solicited Pornography and Marketing Act) (The U.S. Government, 2003), effective in January 2004, establishes the first federal standards for the sending of commercial emails. Basically, the bill permits email marketers to send unsolicited commercial emails so long as the messages have true sender information, a clear indication of sexually oriented content, and an ‘‘opt-out’’ mechanism for receivers to reject further messages. As a result, the bill is often criticized as ‘‘You CAN SPAM’’ because it legalizes sending bulk commercial messages as long as the receivers do not explicitly say no. Privacy advocates insist on a person’s basic right to be left alone. Unsolicited commercial emails should not be allowed unless the person is willing to receive them. In contrast, the European Union Directive on Privacy and Electronic Communications (The European Parliament and the Council, 2002), enacted in December 2003, adopts an ‘‘opt-in’’ principle. It requires that businesses must acquire individuals’ prior consent before sending commercial emails to them, unless

ARTICLE IN PRESS Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

an existing customer relationship exists. Email licensing is more close to the opt-in approach, where an email message cannot be sent to the receiver without his consent. It should be noted that the effectiveness of legal controls requires cooperation between international community. Otherwise, one could use off-shore email domains to transmit spam—deliberately beyond the reach of more enlightened jurisdictions.

2.3. Economic approach From an economic point of view, sending bulk commercial emails costs the sender almost nothing in current email systems, but ISPs and receivers have to spend considerable efforts in dealing with them. Economic approach attempts to alter this overwhelmingly unbalanced business model by increasing the cost of sending emails, e.g., by requiring a user’s machine to do little computation with their CPU while sending their emails (Dwork and Naor, 1992; Abadi et al., 2003; Microsoft). The cost can be neglected for a regular email sender, but huge computation would be needed for sending bulk emails. A major problem with the approach is that just because someone has gone to some degree of effort to send an email does not necessarily mean that the recipient wants to receive it. Moreover, neither ISPs nor recipients are directly benefited from the cost the sender spent. A more constructive way would be asking commercial email senders to pay some fees to their receivers for viewing their messages. (Fahlman, 2002 considers this as an ‘‘interrupt fee’’ as it diverts a recipient’s attention.) A laboratory experiment conducted in Kraut et al. (2002) shows that charging a price for sending messages causes the sender more selective and to send fewer messages, although the recipients did not use the postage paid by the senders as a signal of importance. Moreover, variable usage rate reduces communication volume more than flat rate. Some theoretical results based on principles of information economics have also been established. Van Zandt (2004) shows that increasing communication costs will benefit most receivers and all senders if either surcharges are rebated to the community, or the senders target their receivers more accurately. Loder et al. (2004) develop a model for pricing emails so that facilitating communication rather than blocking it will improve social welfare, and that people who knowingly misuse communication will incur higher costs than those who do not. Dai and Li (2004) combine the techniques of pricing and filtering, and develop a model to calculate optimal surcharges, provided that an aggregated filter can correctly determine how useful a bulk message is to the recipients. Note that all these models need a framework to translate them into the SMTP. Our email licensing mechanism not

only provides such a framework, but also allows versatile criteria to be taken into account in pricing and in negotiation.

3. Email licensing In this section we present our email licensing framework. As discussed in Section 1, email licensing is based on OPDL (Cha and Joung 2002, 2003), where email address is considered as a data owned by the addressee. To send messages to the addressee one must obtain a license from the addressee. A license represents an agreement between the sender and the recipient upon what types of messages can be delivered, and in what restrictions. By examining licenses, the recipient’s mail agent/server can check if an incoming email is authorized, and then takes appropriate actions on it. Fig. 1 outlines the EL scheme. Each user’s Mail User Agent (MUA) is associated with an ‘‘EL’’ agent. When a user wishes to send a message to a recipient, if the user does not have a valid license from the recipient to send it an email, the user’s EL agent will interact with the recipient’s EL agent to request a license. Then the license will be attached to the message and delivered to the recipient via the Main Transfer Agents (MTAs) between the sender and the recipient. The interaction between the two EL agents is illustrated in Fig. 2. To obtain an EL, the sender’s EL agent must propose a request stating how the sender would like to use the email address. The recipient’s EL agent then evaluates the proposal based on the recipient’s preferences, and decides if a license can be issued to the requester. If the sender’s proposal does not match the recipient’s preference, a negotiation process may be triggered to let the two parties resolve their difference. Note that the EL scheme concerns communication between only two parties—the sender and the recipient. Thus, if a sender wishes to send a message to a number of recipients, it must acquire license from each of the recipients. In the following sections we present details of the scheme. 3.1. EL design Basically, an EL describes what the sender and the email recipient has agreed upon the use of the recipient’s email address, 1. Make a license proposal 3. email License 3’. counter-proposal

Fig. 2. Interaction between EL agents.

Recipient’s MTA Sender’s MTA email license negotiation EL Agent Email License Recipient’s MUA Sender’s MUA Inbox Fig. 1. Email license scheme.

2. evaluate proposal

4’.negotiation

EL agent

licensed email

EL Agent

541

EL agent

ARTICLE IN PRESS 542

Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

including, for example, what kind of messages to send, and when and how often the sender can send messages to the recipient. The data model of EL is shown in Fig. 3. An EL consists of four entities: Party, Agreement, Purpose, and Constraint. Overall, they represent that two parties in the model have reached an agreement in the purposes of using an email address (the subject of the license) and constraints on the usage. The two parties refer to the sender (the licensee) and the recipient (the licenser) of a message to the email address. Note that the target of an email address is considered as the owner of the address, and so only he can issue licenses to the use of the email address. A license can be implemented by the logical structure shown in Fig. 4. It consists of a header and a number of agreements. The license header contains general information about the license, such as identification number, issued time, the licenser, the licensee, and their digital signatures. Agreements are the core of an EL. Each agreement represents an authorization for the licensee to legitimately send messages to the licenser. An agreement Ai contains the purpose P i of sending messages and constraint C i to the practice. In addition, each agreement is signed by the licenser’s private key SK to prevent the agreement from being forged. The signature of each agreement is encoded in BASE64 format and is attached to the agreement for verification. We comment here that an EL requires digital signature for authentication. This is important as licenses can constitute legal evidence for resolving possible disputes of email violations. Digital signature has been widely used for securing message delivery (Linn, 1993; Callas et al., 1998; Santesson, 2005), and it is also believed that digital signature is needed for end users to gain complete control of unsolicited emails (Tompkins and Handley, 2003; Loder et al., 2004). The use of digital signature accompanies with the problem of key management. As there is already rich literature on this subject (see, e.g., CCITT, 1988; Kent, 1993; Chokhani, 1994; Menezes et al., 1997), we omit details of this in the paper. The purpose entity in an EL helps the licenser know why the licensee wishes to send messages to the recipient. We define several kinds of purposes for the licensee to specify his intention:

 Business Communications are formal emails that are used







  Personal Communications are used to communicate with families, friends, and acquaintances.

Reach

LICENSER

LICENSEE

AGREEMENT

to communicate with colleagues, employers, and clients. Generally, emails sent for this purpose are used to discuss official affairs and the message content entity can be scheduling appointments, work delegation, task tracing, and document delivery/archiving. Customer Services are based on the CAN-SPAM Act (The U.S. Government, 2003), which defines ‘‘transactional or relationship’’ emails as those messages that facilitate an agreed-upon transaction or update a customer in an existing business relationship. Online shopping sites can use messages of this purpose to request ELs of its customers. If necessary, a subelement called ‘‘Message Content’’ can be added to further classify different types of customer services (Nielsen, 2003), including order and service confirmations, shipment notifications, reservation confirmations and e-tickets, available-now notices, billing and payment notices, cancellations, returns, refunds, rebates, and bonuses, information-request responses, government responses, customer service messages, failure notices, and registration and account information. Unsolicited Commercials are also based on the definition of commercial emails in CAN-SPAM Act (The U.S. Government, 2003). The ‘‘Commercial’’ purpose means that the message is used to advertise or promote a product or service. The message content entity can be filled in the selling products or services. Like ‘‘Customer Services’’, we can further refine the category by adding a sub-element to describe the type of commercial products, e.g., Electronics, Computers, Clothing and Accessories, etc. There are several ways to choose product classification, e.g., by Yahoo category, yellow pages, etc. Subscriptions are emails that are initiated from the licenser. The licenser may register to a mailing list for receiving emails about his interests. For example, one may subscribe various email newspapers. Therefore, the message content entity can be filled in the materials of the requested newsletter. Again, this category can be further classified into different subcategories. Others are used to include the types of purposes that are not specified by the above categories. They may be charitable messages from non-profit organizations or advocacy of religions or politics.

The constraint entity is used to regulate the practice of sending emails. We define the following constraints:

 Interval describes a period of time during which the license is valid.

 Frequency specifies the (maximum) number of messages

Consist of PURPOSE

CONSTRAINT

 Fig. 3. Email license data model.

Header A1

P1

C1

SIGNSK(H,P1,C1)

... Ak

 Pk

Ck

SIGNSK(H,Pk,Ck)

Fig. 4. Email license logical view.

within an interval the licensee can send. For example, the licenser can ask the licensee not to send more than three commercial messages a day. Allowing Weekdays states that messages can be sent during weekdays. Note that although this option looks more like a permission than a constraint, disabling this option leaves a license valid only in weekend. Such a restriction is especially useful for commercial messages. We use a positive way rather than a negative way to state the constraint as later in the negotiation process this option can be traded for interval/ frequency constraints. Allowing Weekend states that messages can be sent in weekend. Like the above, disabling this option leaves a license valid only in weekdays. The restriction may be useful to someone who does not wish to be bothered by business emails during the weekend.

ARTICLE IN PRESS Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

Analogous to the ‘‘Allowing Weekdays/Weekend’’ options, one may refine the above constraints by adding some options like ‘‘Allowing Business Hour/Non-Business Hour’’, ‘‘Allowing 12PM5PM’’, etc. For simplicity, we do not consider such refinement in our current implementation. Note that one may wonder why bother to place a constraint on when an email can be delivered, as if one does not wish to accept an email during some specific time, then he can simply ignore the message until he wishes to read. Our argument is that email clients typically enable an ‘‘alert’’ function (e.g., make a beep) to notify their users upon receiving an email message. It is a nuisance if one is distracted to check an incoming email and learn only that this is not the type of messages he wishes to read at the moment. We believe that the situation will be getting more serious when mobile devices and ubiquitous computing become pervasive, where people wish to be informed on important messages regardless of where they are, but do not like to be bothered by messages they do not expect. So it is necessary to incorporate a mechanism to distinguish if some type of messages can arrive in a certain time. Fig. 5 illustrates an EL. The EL describes that the licensee ‘‘DirectMarketing’’, an email marketing company, obtains an EL from the individual licenser Chu-Jui Yang on 04/12/2006. The licensee is allowed to send Chu-Jui ‘‘Customer Services’’ messages within 4 weeks, and at most two messages per week. The second agreement permits DirectMarketing to send commercial messages for four weeks, three messages are allowed per week, and only during the weekend.

3.2. EL negotiation To obtain an EL, the email sender must propose a request stating the intention of sending a message and the constraint he will follow. Such request is called licensing proposal in OPDL, and it basically has the same format as a license. An acceptable proposal can thus be easily converted to a license, as it states clearly what the requester wants, and the requests have been approved by the data owner. Like licenses, proposals are also digitally signed by the senders. The digital signature can also be used for the two communication parties to authenticate each other. To make granting license automatic, the recipient must set its preferences on what type of messages he wishes to receive, and in what conditions. Still, a licensing proposal may not exactly match the recipient’s preferences, and so a negotiation process may be invoked to help resolving the differences. In general, negotiation is a process in which two (or more) parties with different criteria, constraints, and preferences, jointly reach an agreement on the terms of a transaction. It eliminates the gap between two parties so that both can benefit from reaching agreement to complete the transaction that was originally unacceptable (Cranor and Resnick, 2000; Lomuscio et al., 2001). For negotiation, we use a credit based evaluation system to evaluate proposals (Joung et al., 2005). The idea is to calculate the ‘‘credit consumption’’ of each term requested in a proposal as the cost by the recipient to grant the term. If the total credit consumption does not exceed a user’s incentive (also represented as credits) for reaching agreement, then the proposal can be accepted; otherwise the proposal must be modified for next round of evaluation. Credits are calculated based on the preferences setting of the recipient. Formally, email preferences are specified as follows: Definition 3.1. An email preferences setting is specified as a set fP1 ½C 11 ðw11 Þ; C 21 ðw21 Þ . . .; P 2 ½C 12 ðw12 Þ; C 22 ðw22 Þ . . .; . . .g, where each P i ½C 1i ðw1i Þ; C 2i ðw2i Þ . . . represents a preference about a purpose P i

543

along with an optional list of constraints C 1i ; C 2i . . . . The value wji behind C ji is the credit consumption for using this constraint. Note that the constraints C 1i ; C 2i . . . on purpose P i are optional. If no constraint is given, then the user has not specified any condition on accepting emails of this purpose. For example, the purpose ‘‘Personal Communications’’ is usually requested by someone who has close relationship with the licenser. So the user may choose not to set any constraint for this kind of email communications. Similarly, if some constraint C is not specified in the constraint list of a purpose, then the user has not imposed the constraint on the purpose. This is equivalent to explicitly specify C for the purpose, but put zero credit consumption for the constraint. Moreover, as we have seen in Section 3.1, some constraints like ‘‘Allowing Weekdays/Weekend’’ are more like a permission than a constraint. To disable such an option, one can use a maximal value ‘‘1’’ as its credit consumption. The negotiation mechanism will reject a proposal for requesting a disabled option. On the other hand, any purpose that is not specified in a user’s preferences setting means that the user does not allow email messages of this purpose. As an example, consider the following preferences:

 A user would like to receive Personal messages without any restrictions, and Business messages only during the weekdays.

 He allows Unsolicited Commercial emails but prefers to receive



such messages during the weekend. In addition, he wishes to impose some regulation on sending such messages: no more than five commercial messages within a week for a maximum of 4 weeks. He assigns credit consumption 2 to the frequency constraint and 8 to the interval constraint. Moreover, there is no cost for sending messages of this type in weekend, but it needs three credits if the requesting site wishes to send messages in weekdays.

According to the above description, the user’s email preferences can be set as follows: f Personal Communications Business Communications [Allowing Weekdays (0), Allowing Weekend ð1Þ ] Unsolicited Commercial [Frequency: 5 counts/week (2), Interval: 4 weeks (8), Allowing Weekdays (3), Allowing Weekend (0) ] g

Note that the credit consumption of ‘‘Interval’’ must be equal to the product of the credit consumption of ‘‘Frequency’’ and the constraint value of the ‘‘Interval’’. Analogous to preferences setting, a licensing proposal can be formally specified as follows: Definition 3.2. An email licensing proposal is a set fP1 ½C 11 ; C 21 . . .; P2 ½C 12 ; C 22 . . .; . . .g, where each Pi ½C 1i ; C 2i . . . represents a request of license for purpose Pi , and C 1i ; C 2i . . . are the (optional) constraints the requester will follow for messages of this purpose. As an example, suppose that an email marketing company wishes to send commercial messages to a user 10 times a week for 2 weeks. Then the company can specify its email licensing proposal as follows: f Unsolicited Commercial [ Frequency: 10 counts/week, Interval: 2 weeks] g

ARTICLE IN PRESS 544

Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

Fig. 5. An email license.

We now present the negotiation process. Although an email licensing proposal may contain requests of different purposes, we assume that the purposes are independent. That is, each can be granted independently of one another. So in the negotiation process we will focus on one purpose at a time. The negotiation process is shown in Fig. 6. It begins by checking if the requested purpose in an incoming proposal is allowed by the recipient (that is, if the purpose is specified in the recipient’s preferences setting). If not, then the request cannot be granted. Otherwise, the process checks if the recipient has specified a constraint on the requested purpose. If not, the request is granted. Moreover, if a constraint is specified in the proposal, then the constraint will be kept in the final license issued to the requester. On the other hand, if the recipient has set a constraint on the purpose but the proposal has not specified any constraint, then the proposal is rejected. Alternatively, the negotiation process may provide some default constraint to the purpose, and send the requester a counter-

proposal asking it to impose a constraint as suggested in the counter-proposal. We are now left with the case that both the preferences setting and the proposal have specified a constraint on the requested purpose. For this case we need to calculate the total credit consumption of the request, and check if the amount exceeds the user’s limit. To do so, observe that the constraints frequency and interval together determine the total number of messages the requester may send under this proposal. So these two constraints must be considered together. Let f req and ireq be the requested frequency and interval, and let F max and Imax be the maximum frequency and interval specified in the user’s preferences setting. For the evaluation to continue, we must have f req pF max and ireq pImax ; or else the request is rejected. If the frequency constraint F max has been set, then the credit consumption per sending of an email is wF =F max , where wF is the credit consumption for using the maximum frequency F max. So the

ARTICLE IN PRESS Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

license proposal

no

yes

is purpose allowed?

reject proposal no

proposal has constraint?

yes

preferences has constraint?

yes

no

calculate credit consumption yes

exceed limit?

On the other hand, the total credit consumption requested by the user is 25  4  2 þ 3 ¼ 6:2, which exceeds the user’s upper bound 5.6, so the proposal cannot be granted. There are several ways to generate a counter-proposal to help the requester to reach an agreement. For example, in the above we can remove the ‘‘Allowing Weekdays’’ option from the proposal to reduce its credit consumption to 3.2. Alternatively, we can reduce the frequency and interval values in the proposal to some f and i that satisfy the following conditions: 8 0of pF max > > > < 0oipImax wF > >  f  i þ C others pIL  wI > :F max

accept proposal

no

Fig. 6. Proposal evaluation process.

credit consumption of the requested frequency and interval is calculated as follows: C¼

545

wF  f req  ireq F max

However, if the frequency constraint is not imposed by the user, then the credit consumption C will be determined only by the requested interval ireq ; that is, C ¼ ireq =Imax  wI , where wI is the credit consumption for using the maximum interval Imax . Note that the interval constraint Imax must be specified in a user’s preferences, for otherwise an issued license may have no expiration date. For other constraints (i.e., ‘‘Allowing Weekdays/Weekend’’), their credit consumptions are as specified in the user’s preferences setting. All together, the total credit consumption of a request is the sum of the credits consumed by the constraints specified in the request. We use the credit consumption wI for the Interval constraint as the user’s total credits that may give away at a time to an agreement (and recall that wI ¼ Imax  wF if frequency constraint is imposed). If a proposal additionally requests options ‘‘Allowing Weekdays/Weekend’’ that are not free, then the requesting frequency and interval must be compromised. In addition, we use an incentive level IL, a value between 0 and 1, to let a user express his ‘‘intention’’ to reach an agreement. The maximum credits that a user will actually give away is thus defined as IL  wI . As we shall see, the purpose of adding the incentive level is to let an average user easily control the amount of messages he would like to receive. To illustrate, consider the following preferences setting: f Unsolicited Commercial [ Frequency: 5 counts/week (2), Interval: 4 weeks (8), Allowing Weekdays (3), Allowing Weekend (0) ] }

and an incoming proposal: f Unsolicited Commercial [ Frequency: 4 counts/week, Interval: 2 weeks, Allowing Weekdays, Allowing Weekend ] }

Assume that the user has set his incentive level IL ¼ 0:7. So the maximum credits the user allowed per agreement is 0:7  8 ¼ 5:6.

where C others is the credits consumed by other constraints. Again, there is much flexibility in choosing f and i. A conservative approach tends to release as fewer credits as possible, while a generous approach will give away as many credits as possible to help reaching an agreement. Finally, we note that a user can use the incentive level IL to easily control the amount of messages he would like to receive. For example, in the above condition, when C others ¼ 0, reducing the level by half would result in the amount of messages ðf  iÞ being reduced by half (given other settings unchanged).

4. System implementation Email licensing can be implemented by adding an email licensing agent over existing mail client software. The main task of the agent is to allow users to request EL, evaluate licensing proposals, generate EL, and manage licenses and emails. We chose Microsoft Outlook as our mail client for its popularity. The agent we implemented is an add-in application to the mail client so that the user can install it without additional configurations or modification to Outlook. Fig. 7 shows the architecture and its function components. The agent is composed of two main modules, License Management and Negotiation. License Management consists of two components, License Validator and License Store. License Validator adds email licenses obtained from target receivers into the header of outgoing mails to them. It also checks if incoming mails have a valid license. If not, an appropriate action will be taken, such as flagging it as unacceptable. License Store manages all the issued licenses as well as licenses obtained for sending out emails. The Negotiation module consists of the following four components, User Preference Setting, Proposal Requester, Proposal Evaluator, and Counter-Proposal Generator. User Preference Setting enables users to set their preferences for EL negotiation. Proposal Requester allows users to make a licensing proposal to other email

Email License Agent Negotiation

License Management

User Preferences Setting

Counter Proposal Generator

Email License Store

Proposal Requester

Proposal Evaluator

License Validator

Fig. 7. Email Licensing Agent Architecture.

ARTICLE IN PRESS 546

Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

licensing agent. Proposal Evaluator evaluates an incoming proposal’s credit consumption according to the user’s preference setting, and decides whether or not to accept the proposal. If accepted, the proposal is converted to an EL; otherwise, CounterProposal Generator is triggered to see if a counter-proposal can be generated. After the user installs the add-in and re-launches Outlook, a button ‘‘Email Licensing Agent’’ appears in the command bar. (See Fig. 8, the right most button in the command bar.) When the button is pressed, the agent form is popped out to let the user set his preferences, make proposal requests, view and evaluate proposals. For example, Fig. 9 shows the preference setting page in the form. The user can choose the types of emails he wishes to receive, and the frequency, interval, and incentive level of a specific type. As noted at the end of Section 3, a user can use the incentive level to easily control the amount of messages he would like to receive. When an incoming message arrives, the agent first checks if it has a valid license. If so, ‘‘[email Licensing Certified]’’ will be labeled in front of the original subject to let the user easily recognize if an incoming email is licensed from the message list box (see also Fig. 8). The user can even set a rule in Outlook to automatically place legitimate emails into a special folder called ‘‘Legitimate Messages’’ and unlicensed emails into another. A user can also build a ‘‘Friends List’’ (i.e., whitelist) containing emails addresses that are allowed to send messages to the user without attaching a license. Note that the implementation does not touch SMTP. All communications (i.e., license negotiation) between email licensing agents are performed via the standard SMTP protocol. This is because licenses and proposals are simply XML text files. They can be sent via the standard SMTP protocol while email licensing agents are negotiating with each other. In short, the communications between the agents are nothing more than regular email messages between them. One benefit of not altering the email infrastructure for email licensing is to ease its deployment. This is because email has become our daily life. Any attempt for a proposal to change its

infrastructure would increase the deployment difficulty. Furthermore, since email is already so popular, any new proposal must inevitably face the issue of incremental deployment, that is, for the proposed scheme to coexist with legacy systems. Our implementation addresses this issue by allowing email licensing agents to accept emails from other email clients as well. Specifically, when a sender A with a non-licensed-based email client sends an email to user B that has an email licensing agent, B’s agent will send a message to A to request a license proposal. Since A does not have a licensing agent to process B’s request, A sees this message as a regular email. He can then fill out the license request form manually and sends to B to request a license. Once A receives B’s license, he can send emails to B by attaching the license to his emails. Alternatively, in B’s reply to A, B’s agent may also point a link for A to download the email licensing program, thereby to manage his EL. Even if A insists not to use the email licensing program, his email can still reach to B, but will be classified as ‘‘unlicensed emails’’. It is up to B to read the emails, or to put A in the whitelist (supposed A is a friend of B). Finally, to evaluate our system, we conducted a simple usability test on email licensing. We invited 18 volunteer subjects from a department in our university to participate in the experiment. Each subject was given a new email account to use during the experiment. They can use the new email account to communicate with each other, as well as with the outside world. In addition, we also installed some email servers to generate emails, some licensed and some unlicensed, to the subjects. The experiment lasted for one week. Then, each subject was given a questionnaire to fill, which contained 13 questions about their email usages after installing the email licensing agent. Below are the key findings of this experiment:

 61% of subjects agreed that spam have caused them unable to receive legitimate messages.

 Only 22% of subjects agreed that their current anti-spam tools (filters) really work.

Fig. 8. User interface of the email client.

ARTICLE IN PRESS Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

547

Fig. 9. Preference Setting Tab.

 88% of subjects agreed that email licensing helps them   

distinguish legitimate emails. 83% of subjects said that they do not need to spend much time looking for wanted messages after using the system. 67% of subjects said that they would consider receiving commercial messages if they are coming with a licensing proposal. 83% of subjects said that they would continue using email licensing.

According to the above findings, we can conclude that email licensing can help users distinguish legitimate messages from unwanted ones. Even though there are still unsolicited emails, they do not need to waste so much time in finding wanted messages in their inboxes as before. Besides, users feel that they are more likely to accept commercial emails if marketing companies have asked them in advance. They agree that email licensing provides a mechanism for them to determine if they can accept commercial messages.

5. Conclusions and future work We have proposed a novel framework—email licensing—that enables email users to determine whose messages and in what content and conditions are authorized to come into their inboxes. Recipients can easily configure their mail agents to distinguish legitimate messages from unauthorized ones, and therefore to take some actions on the unauthorized messages before they can bother the recipients. The framework combines several advantages from existing approaches for curbing unsolicited emails. First, the framework uses information technology to make transactions of email licensing automatic. That is, the process of license request and granting can be made fully automatic based on a user’s preferences on incoming emails. The license attached in an

incoming message can also be verified for its validity. Moreover, existing filtering techniques can also be integrated into the framework to examine if the message content is as it claims in the license. Second, the philosophy behind existing economic approaches is to alter the rather unbalanced business model in current systems where the cost of sending bulk commercial emails is insignificant compared to the cost spending in receiving and processing them. In the email licensing framework, a sender is required to engage in a negotiation process with the recipient to obtain an authorization to send a message. The computational cost of the process, although is negligible per execution, would sum up to a non-trivial amount when bulk emails are intended. Note that some challenge-response techniques can also be aggressively incorporated into the negotiation process to authenticate the sender and thereby to make sending bulk emails more costly. Finally, email licensing is certainly a legislative approach, and relies substantially on laws to make the framework successful. An EL is an agreement between the sender and the receiver on what kind of messages will be and can be sent, and in what practice. The agreement is digitally signed by the licensee so that if the licensee violates the agreement by sending messages of different content type as agreed (e.g., sexual-oriented materials with a license obtained for ‘‘consumer electronics’’ commercials), then punishment can be enforced by laws. To summarize, email licensing provides a more effective way to cope with unsolicited emails than existing anti-spam laws do, as individuals now have legal evidence for asking email marketers to comply with their agreements. It also gives the users more privacy as it adopts an ‘‘opt-in’’ mechanism for them to decide whether or not to receive commercial messages, as opposed to existing approaches where unsolicited messages can arrive unless the users have explicitly ‘‘opted out’’. Numerous solutions for unsolicited email have been suggested and implemented. Still, there is no sign of slowing down its volume, revealing the magnitude and the complexity of the

ARTICLE IN PRESS 548

Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

problem. Therefore, we do not expect our proposal to be a ‘‘magic bullet’’ to the problem. Rather, it is just a first and small step toward a better and efficient use of the email infrastructure. Many directions are yet to be explored, and our primary purpose of the paper is to intrigue more research in the directions. For example, one serious challenge we face is the deployment of the email licensing scheme. It is unrealistic to assume a global and direct conversion to the scheme. So in the current stage we implement it as an ‘‘add-in’’ to existing email clients, and allow an EL agent to handle emails even if the senders do not employ an EL agent. A user can also configure its EL agent to allow a ‘‘friend list’’ to send unlicensed emails. To allow EL agents to be implemented by different parties, some standard communication protocol is needed between agents. Some incentive may also be given to promote the scheme. As we have discussed earlier in Section 2.3, from an economic point of view, a more constructive approach to allow commercial email senders to legitimately distribute their emails is to ask them to actually credit their receivers for viewing their messages. Our email licensing framework indeed allows both email marketers and the individuals to negotiate an acceptable price for the license, as our credit-based negotiation mechanism can be easily converted to ask the email marketers to pay the ‘‘credits’’ they consume from the license issuers. However, in this case the credit calculation needs to reflect the real ‘‘price’’ of a user’s email address. How an email address should be priced is an interesting and challenging future work. A credit flow mechanism needs also be incorporated into the system. Moreover, the success of email licensing relies on laws, which can be very complicated. What should a license state? What authority can it claim? What is the liability of a licenser and a licensee? Can a licenser revoke issued licenses? Can a license be transferred to a third party? Is a license an asset to a company that can be traded or subsumed by another company? Clearly, email licensing involves deliberate integration between information technologies and laws, and there is much more to be explored than the technological issues we have addressed. These issues are beyond the scope of the paper, and certainly beyond our limited knowledge. Nevertheless, we believe that through our first step more serious issues about email licensing will be raised and discussed. Hopefully, they will make the proposal more concrete and eventually being adopted in the world. Finally, unsolicited messages have penetrated to other platforms, e.g., Instant Messaging (IM) (Elliott, 2004) and Short Message Service (SMS) (WiredSafety, 2006) in mobile devices. Applying the concept of licensing to solve the problems there may be worth a consideration.

Acknowledgments We would like to thank the anonymous referees for their invaluable comments. References Abadi M, Birrell A, Burrows M, Dabek F, Wobber T. Bankable postage for network services. In: Proceedings of the 8th Asian computing science conference (ASIAN 2003). Lecture notes in computer science, vol. 2896. Berlin: Springer; 2003. p. 72–90. Allman E, Callas J, Delany M, Libbey M, Fenton J, Thomas M. RFC 4871: Domainkeys identified mail (DKIM) signatures. hhttp://www.ietf.org/rfc/rfc4871.txti; May 2007. Bernstein DJ. Internet mail 2000 hhttp://cr.yp.to/im2000.htmli; 2000. Bogofilter. Bogofilter—fast Bayesian spam filter. Retrieved 2004 from hhttp:// bogofilter.sourceforge.net/i. Bonded Sender hhttp://www.bondedsender.com/i. Retrieved 2004 from hhttp:// www.bondedsender.com/i.

Callas J, Donnerhacke L, Finney H, Thayer R. RFC 2440: OpenPGP message format. hhttp://www.ietf.org/rfc/rfc2440.txti; November 1998. Candler B. Some observations on the IM2000 proposal and spam hhttp://cr.yp.to/ im2000.htmli; April 2005. CCITT. Recommendation X:509: the directory—authentication framework. Technical report, CCITT (Consultative Committee on International Telegraphy and Telephony); 1988. Cerf VG. Spam, spim, and spit. Communications of the ACM 2005;48(4): 39–43. Cha S-C, Joung Y-J. Online personal data licensing. In: Proceedings of the third international conference on law and technology (LawTech 2002), November 6–7 2002. p. 28–33. Cha S-C, Joung Y-J. From P3P to data licenses. In: Proceedings of the workshop on privacy enhancing technologies (PET2003). Lecture notes in computer science, vol. 2760. Berlin: Springer; 26–28 March 2003. p. 205–21. Chokhani S. Toward a national public key infrastructure. IEEE Communications Magazine 1994;32(9):70–4. Claburn T. Spammers hijack sender ID. Information Week; September 9 2004. Cole WK. Blacklists, blocklists, DNSBL’s, and survival hhttp://www.scconsult.com/ bill/dnsblhelp.htmli; January 2007. Cranor LF, Resnick P. Protocols for automated negotiations with buyer anonymity and seller reputations. NETNOMICS: Economic Research and Electronic Networking 2000;2:1–23. CRM114. CRM114. Retrieved 2004 from hhttp://crm114.sourceforge.net/i. Dai R, Li K. Shall we stop all unsolicited email messages? In: Proceedings of the First conference on email and anti-spam (CEAS 2004), Mountain View, CA, USA, July 2004. DelConte NT. Spam numbers rise, although porn is down. PCMAG.COM hhttp:// www.pcmag.com/article2/0,1759,2010975,00.aspi; September 01 2006. Denny N, El Hourani T, Denny J, Bissmeyer S, Irby D. SpamCooker: a method for deterring unsolicited electronic communications. In: Proceedings of the third international conference on information technology: new generations. Las Vegas, Nevada, USA: IEEE Computer Society; 2006. p. 590–91. Duan Z, Dong Y, Gopalan K. A differentiated message delivery architecture to control spam. In: Proceedings of the 11th international conference on parallel and distributed systems—workshops (ICPADS’05). Washington, DC, USA: IEEE Computer Society; 2005. p. 255–59. Dwork C, Naor M. Pricing via processing or combatting junk mail. In: Proceedings of the 12th annual international cryptology conference (CRYPTO’92). Lecture notes in computer science, vol. 740. Santa Barbara, CA, USA: Springer; August 1992. p. 137–47. Elliott P. Messaging spam heads for your PC. BBC News; 22 August, 2004 hhttp:// news.bbc.co.uk/2/hi/technology/3581148.stmi. Fahlman SE. Selling interrupt rights: a way to control unwanted email and telephone calls. IBM Systems Journal 2002;41(4):759–66 Available: hhttp:// www.research.ibm.com/journal/sj/414/forum.pdfi. Ferris Research. The global economic impact of spam. Technical report, Ferris Research; February 2005. Graham P. A plan for spam; August 2002 hhttp://www.paulgraham.com/ spam.htmli. Habeas. Habeas sender warranted email. Retrieved 2004 from hhttp://www. habeas.com/i. Harris E. The next step in the spam control war: Greylisting. hhttp://projects. puremagic.com/greylisting/whitepaper.htmli; August 2003. IronPort. Spammers continue innovation: Ironport study shows image-based spam, hit and run, and increased volumes latest threat to your inbox. IronPort Press Release hhttp://www.ironport.com/company/ironport_pr_2006-06-28. htmli; June 28 2006. Joung Y-J, Cha S-C. Online personal data licensing: regulating abuse of personal data in cyberspace. In: Sasaki H, editor. Intellectual property protection for multimedia information technology. IGI Global, 2008. p. 162–185. Joung Y-J, Yen C, Huang C-T, Huang Y-J. On personal data license design and negotiation. In: Proceedings of the 29th international computer software and applications conference (COMPSAC 2005). IEEE Computer Society; July 2005. p. 281–6. Kaushik S, Winsborough W, Wijesekera D, Ammann P. Email feedback: a policybased approach to overcoming false positives. In: Proceedings of the 2005 ACM workshop on formal methods in security engineering (FMSE ’05). New York, NY, USA: ACM Press; 2005. p. 73–82. Kent S. RFC 1422: Privacy enhancement for Internet electronic mail: part II: certificate-based key management hhttp://www.ietf.org/rfc/rfc1422.txti; February 1993. Kraut RE, Morris J, Telang R, Filer D, Cronin M, Sunder S. Markets for attention: will postage for email help? In: Proceedings of the 2002 ACM conference on computer supported cooperative work (CSCW ’02). New York, NY, USA: ACM Press; 2002. p. 206–15. Linn J. RFC 1421: privacy enhancement for Internet electronic mail: part I: message encryption and authentication procedures hhttp://www.ietf.org/rfc/ rfc1421.txti; February 1993. Loder T, Van Alstyne M, Wash R. An economic answer to unsolicited communication. In: Proceedings of the 5th ACM conference on electronic commerce (EC’04). New York, NY, USA: ACM Press; 2004. p. 40–50. Lomuscio A, Wooldridge M, Jennings NR. A classification scheme for negotiation in electronic commerce. In: Proceedings of the agent mediated electronic commerce, the European AgentLink perspective. Lecture notes in computer science, vol. 1991. Berlin: Springer; 2001. p. 19–33.

ARTICLE IN PRESS Y.-J. Joung, C.-J. Yang / Journal of Network and Computer Applications 32 (2009) 538–549

Lyon J, Wong M. RFC 4406: Sender ID: authenticating e-mail hhttp://www.ietf.org/ rfc/rfc4406.txti; April 2006. Mastaler JR. Tagged message delivery agent. Retrieved 2004 from hhttp://tmda.net/i. McMillan R. Consumers to lose $2.8 billion to phishers in 2006. PCWorld hhttp://www. pcworld.com/article/id,127799-pg,1-RSS,RSS/article.htmli; November 09 2006. Menezes AJ, van Oorschot PC, Vanstone SA. In: Handbook of applied cryptography. CRC Press; 1997. MessageLabs. Monthly report: October 2006. hhttp://www.messagelabs.comi. Messaging Anti-Abuse Working Group (MAAWG). Email metrics program: the network operators’ perspective. Report#2—1st quarter; June 2006. Microsoft. The penny black project. hhttp://research.microsoft.com/research/sv/ PennyBlack/i. Miller D. Bouncebacks: the hidden cost of spam. ITPlanet.com, May 2, 2006 hhttp:// www.ironport.com/company/pp_enterprise_it_planet_05-02-2006.htmli. Musil S. Week in review: so long Sobig? Not so fast. In CNET News.com, August 29 2003 hhttp://news.com.com/2100-1083-5069594.htmli. Nielsen J. Confirmation email, automated customer service email, and transactional messages. Retrieved 2005 from hhttp://www.useit.com/alertbox/ 20031208.htmli; December 2003. Olsen S. Corporate in-boxes choke on spam. In CNET News.com, June 2, 2003 hhttp://news.com.com/2100-1024_3-1012418.htmli. Pfleeger SL, Bloom G. Canning spam: proposed solutions to unwanted email. IEEE Security and Privacy 2005;3(2):40–7. PGP. The international PGP home page. Retrieved 2004 from hhttp://www.pgpi.org/i. Prakash VV. Vipul’s Razor. Retrieved August 2005 from hhttp://razor.sourceforge. net/i. Rhyolite Software. Distributed checksum clearinghouse. Retrieved August 2005 from hhttp://www.rhyolite.com/anti-spam/dcc/i. Sahami M, Dumais S, Heckerman D, Horvitz E. A Bayesian approach to filtering junk e-mail. In: Proceedings of the AAAI’98 workshop on learning for text categorization. AAAI Technical Report WS-98-05; July 1998. Santesson S. RFC 4262: X.509 certificate extension for secure/multipurpose Internet mail extensions (S/MIME) capabilities. hhttp://www.ietf.org/rfc/ rfc4262.txti; December 2005.

549

Seigneur J-M, Dimmock N, Bryce C, Jensen CD. Combating spam with TEA (Trustworthy Email Addresses). In: Proceedings of the 2nd conference on privacy, security and trust; October 2004. p. 47–58. Self KM. Challenge-response anti-spam systems considered harmful. Retrieved September 2005 from hhttp://kmself.home.netcom.com/Rants/challengeresponse.htmli; April 2004. SpamAssassin. The SpamAssassin Homepage. Retrieved 2005 from hhttp:// spamassassin.apache.org/i. SpamByes. SpamBayes: Bayesian anti-spam classifier written in Python. Retrieved 2004 from hhttp://spambayes.sourceforge.net/i. Templeton B. Proper principles for challenge/response anti-spam systems. Retrieved 2004 from hhttp://www.templetons.com/brad/spam/challengeresponse. htmli. The European Parliament and the Council. Directive on privacy and electronic communications. heuropa.eu.int/eur-lex/pri/en/oj/dat/2002/l_201/l_ 20120020731en00370047.pdfi; July 12 2002. The U.S. Government. Controlling the Assault of Non-Solicited Pornography and Marketing Act of 2003. hhttp://www.spamlaws.com/federal/108s877.shtmli; 2003. Tompkins T, Handley D. Giving e-mail back to the users: using digital signatures to solve the spam problem. First Monday 2003;8(9). Van Zandt T. Information overload in a network of targeted communication. RAND Journal of Economics 2004;35(3):542–60 Available at: hhttp://ideas.repec.org/ a/rje/randje/v35y20043p542-560.htmli. WiredSafety. SMS spam. hhttp://www.wiredsafety.org/gb/law/spam/sms_spam. htmli; 2006. Wong M, Schlitt W. RFC 4408: Sender policy framework (SPF) for authorizing use of domains in e-mail, version 1. hhttp://www.ietf.org/rfc/rfc4408.txti; April 2006. Yahoo. Domainkeys: proving and protecting email sender identity. Retrieved 2004 from hhttp://antispam.yahoo.com/domainkeysi. Yoke HK, Tan L. Curbing spam via technical measures: an overview hhttp://www.itu.int/ osg/spu/spam/contributions/BackgroundPaper_CurbingSpamViaTechnicalMeasures. pdfi; 2004.