DMTP: Controlling Spam Through Message Delivery Differentiation

EE Times: Are there solutions to spam?

Bob Metcalfe: There are two. One is economics, the other is permission. These were left out [of the original Internet], and now we're having to retrofit. Putting some economics around e-mail would greatly diminish spam. Permission means you can't send an e-mail to someone without their permission. And since e-mail should be strongly encrypted at all times, e-mail filtering is really the wrong way to go, since you shouldn't have third parties reading your e-mail. The best option is a combination of economics and permission.

-- Excerpt of the EE Times interview of Robert M. Metcalfe, "Ethernet's Inventor Sounds Off", November 11, 2005. 

Unsolicited commercial email, commonly known as spam, is a pressing problem on the Internet. In addition to undermining the usability of the current email system, spam also costs industry billions of dollars each year in recent years.

Why is it so hard to control spam?

  1. First, the current email system is fundamentally sender-driven, and there is a distinct lack of receiver control over how messages should be delivered from sender to receiver on the Internet. For example, in the current SMTP-based email delivery system, any user can send an email to another at will, regardless of whether or not the receiver is willing to accept the message. In the early days of the Internet development, this was not a big problem as people on the network largely trusted each other. However, since the commercialization of the Internet in the mid-1990s, the nature of the Internet community has changed. It has become less trustworthy, and email spam is possibly one of the most notable examples of the untrustworthy nature of the Internet. In order to effectively address the issue of spam in the untrustworthy Internet, we argue that receivers must gain greater control over if and when a message should be delivered to them.
  2. Secondly, volume is the most crucial factor in making spamming a profitable business. In order to squeeze spammers out of business, we need to eradicate the economy of scale they rely on. However, in the current email system, the sending rate of spam is, to a large extent, only constrained by the processing power and network connectivity of spammers' own mail servers, of which the spammers have fully control. Nowadays, with increasingly-powerful (and cheaper) PCs and ubiquitous high-speed Internet access, spammers can push out a deluge of email spam within a very short period of time, making spamming a profitable business because of the economy of scale. We argue that {\em the Internet email delivery system must be augmented so that the sending rate of spam can be regulated, ideally under the discrimination of email receivers}.
  3. Lastly, the current SMTP-based email system makes it hard to hold spammers accountable for spamming. Spammers can vanish (go offline) immediately after pushing spam to receivers--note that spammers can finish sending a deluge of spam messages within a very short period of time. This makes it quick and easy for spammers to hide their identities. Moreover, this also provides spammers with the flexibility to frequently change their locations and/or Internet service providers, which complicates the effort to filter spam based on the IP addresses of sender mail servers, such as various real-time blacklists (RBLs). We contend that in order to hold spammers accountable and to make RBLs more effective, {\em we must augment the Internet email delivery system so as to force spammers to stay online for longer periods of time}.

What we propose:

The Differentiated Mail Transfer Protocol (DMTP), a permission-based email delivery protocol,  provides simple extensions to the Simple Mail Transfer Protocol (SMTP) that enable receivers to exercise greater control over the email delivery process. The current SMTP-based email delivery architecture is fundamentally sender-driven and distinctly lacks receiver control over the message delivery mechanisms. This document describes DMTP that enables receivers to classify senders into three categories -- allowed, denied, and unclassified -- and process the delivery of messages from each category independently. As is the current practice, receivers may directly accept messages from senders in the allowed category and decline senders in the denied category. In addition, DMTP receivers require senders in the unclassified category to store messages on the senders' own mail servers. Such messages are retrieved only if and when the end receivers wish to do so. By granting greater control over message delivery to receivers and imposing greater message storage and maintenance overhead on senders, DMTP provides significant advantages in controlling spam. DMTP also easily operates in conjunction with (but does not require) many currently deployed anti-spam techniques.

DMTP add two new commands and a reply code into SMTP to support the receiver pull message delivery model:

MSID: for sender MTA to send a reference or index to a message to the receiver MTA. Syntax:

"MSID:" msid [SP subject] CRFL

GTML: for the receiver MTA to retrieve a message (GeT MaiL) from the sender MTA. Syntax:

"GTML:" msid SP receiver CRFL

Reply code 253: used by a receiver MTA to inform a sender MTA to send a reference instead of the message itself (issuing MSID instead of DATA command).

Figure 1: Illustration of the DMTP architecture.

Some Advantages:

  1. The delivery rate of spam is determined by the spam retrieval behavior of receivers instead of controlled by spammers;
  2. Spammers are forced to stay online for longer periods of time (hoping the spam messages can be retrieved by the majority of the intended receivers), which can significantly improve the performance of RBLs;
  3. Regular correspondents of a receiver do not need to take any extra effort to communicate with the receiver--correspondence from regular contacts is handled in the same manner as in the current SMTP-based email system;
  4. In addition, DMTP is a simple extension to SMTP and can be easily deployed on the Internet incrementally.

Internet Draft:

  1. Receiver-Driven Extensions to SMTP [I-D]. Zhenhai Duan, Kartik Gopalan, Yingfei Dong, IETF Internet Draft. Jan. 2007.

Publication:

  1. Behavioral Characteristics of Spammers and Their Network Reachability Properties, [PDF].
    Zhenhai Duan, Kartik Gopalan, and Xin Yuan. Technical Report TR-060602, Computer Science Department, Florida State University. June 2006.
  2. DMTP: Controlling Spam Through Message Delivery Differentiation, [PDF][Talk Slides]
    Zhenhai Duan, Yingfei Dong, Kartik Gopalan. In Proc. Networking 2006 , Coimbra, Portugal, May 15-19, 2006.
  3. Push vs. Pull: Implications of Protocol Design on Controlling Unwanted Traffic, [PDF] [HTML].
    Zhenhai Duan, Kartik Gopalan, Yingfei Dong. To appear In Proc. USENIX SRUTI 2005 Workshop, MIT, Cambridge, MA, July 7-8, 2005.
  4. DMTP: Controlling Spam Through Message Delivery Differentiation, [PDF]
    Zhenhai Duan, Yingfei Dong, Kartik Gopalan. Techinical Report, TR-041025, Computer Science Department, Florida State University, October 2004.