DiffMail: A Differentiated Message Delivery Architecture to Control Spam


Unsolicited bulk electronic mail (spam) is increasingly plaguing the Internet Email users and deteriorating the value of Email as a convenient communication tool. Although many different spam control schemes have been proposed and deployed on the Internet, the proportion of Email spam seen on the Internet has been increasing in recent years.


In this project we argue that the difficulties in controlling spam can be attributed to the lack of user control on how different Email messages should be delievered on the Internet. In the current Email delivery architecture, a party can at will force another party to be involved in an Email communication, regardless of whether the latter is willing to accept the message. Email spam is possibly one of the most notable examples of the untrustworthy nature of the Internet. We propose a differentiated message delivery architecture---DiffMail.


Design Objectives


  1. Receivers should have more control over how different messages are delivered from senders to the receivers, in order to control spam; 
  2. Messages from regular correspondents should be handled in the same way as in the current Email delivery architecture, in order to preserve Email as a convenient communication tool; 
  3. People other than regular contacts may be allowed to express the intention to communicate, in order to retain Email as an open communication tool; 
  4. DiffMail must allow incremental deployment.


To achieve these goals in DiffMail, each receiving party (a party or a user (sender/receiver) can be either a Mail Transfer Agentor a real Email user. We will distinguish them when it is desirable) can classify senders into different classes, and specify how messages from different classes should be delivered to the party. Here a sender can be defined at different granularities, for example, Email accounts, IP addresses, and domain names. Messages from different classes may be handled differently. For example, a user may directly accept messages from regular contacts, while asking other senders to hold their messages at their own mail servers. Such messages can be retrieved from the sender's mail server if and when the receiver wishes to do so. It is critical to note that a sender needs to maintain such messages on his own mail server before they are retrieved by the receivers. The following figure illustrates the architecture of DiffMail. In the figure, DMTP stands for Differentiated Mail Transfer Protocol, it is an extended version of Simple Mail Transfer Protocol (SMTP). DMTP extends SMTP in two aspects: it allows senders to manage their outgoing message folders, and it supports message retrieval by receivers. DMTP defines two new commands: MSID (for sender MTA to send a reference or index to a message to the receiver MTA) and GTML (for the receiver MTA to retrieve a message (GeT MaiL) from the sender MTA). It also defines a new reply code 253, which is 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 DiffMail architecture.




  1. By asking senders (non-regular contacts) to maintain messages on their mail servers, spammers are forced to keep their servers up. They cannot simply send a large number of spam messages, shut down their servers, and switch to another domain (and/or change IP addresses). In this way, DiffMail helps to improve the effectiveness of IP-address-based filtering schemes. 
  2. Since a (complete) message is only retrieved by a receiver at his will, less bandwidth and storage resource will be consumed at the receiver side if the user does not retrieve the majority of messages from non-regular contacts. 
  3. Spammers now have more responsibilities to maintain their outgoing messages, for example, deleting messages that have not be retrieved by receivers after a certain amount of time. This will discourage spammers from blindly sending spam to arbitrary user accounts.





          Dr. Yingfei Dong, University of Hawaii, collaborates with Dr. Zhenhai Duan and Dr. Kartik Goplan, Florida State University



Internet Draft:

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



  1. DMTP: Controlling Spam Through Message Delivery Differentiation, [PDF]
    Zhenhai Duan, Yingfei Dong, Kartik Gopalan. In Proc. Networking 2006 , Coimbra, Portugal, May 15-19, 2006.
  2. 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.
  3. DiffMail: A Differentiated Message Delivery Architecture to Control Spam, [PS][PDF]
    Zhenhai Duan, Yingfei Dong, Kartik Gopalan. Techinical Report, TR-041025, Computer Science Department, Florida State University, October 2004.


Collaborative Site


          DiffMail at Florida State University