1

DMPT: Controlling Spam Through Message Delivery Differentiation

Zhenhai Duan, Kartik Gopalan

Florida State University

Yingfei Dong

University of Hawaii

2

Outline

• Motivation for a new mail transfer protocol

• Two application-level communication models: – Sender push vs. Receiver pull

• DMTP: Differentiated Mail Transfer Protocol

• Performance study

• Summary and on-going work

3

Why It is so Hard to Control Email Spam?

• Most existing solutions are reactive in nature– Complete messages must received before processed– Spammers have strong incentive to send more– Hard to deal with encrypted messages– Need proactive solutions

• From an architectural perspective– Currently, Simple Mail Transfer Protocol (SMTP)– Sender: prepares messages and pushes– Receiver: passively accepts messages– Sender: quickly vanish after spamming– Ideal platform for spamming

4

What it Takes to Effectively Control Spam?

• Moving to a receiver-driven model– Currently, senders control what/when to send– Granting receivers greater control over msg delivery– Spammers cannot send messages at will

• Eliminating economy of scale– Currently, sending rate controlled by sender– Regulating sending rate of senders by receivers– Spammers cannot quickly send large amount of spam

• Increasing accountability– Currently, can go offline immediately after spamming– Forcing spammers stay online for longer period of time– Spammers cannot hide their identities

5

Application-Level Communication Model 1

• Sender push– SMTP-based email service

• Receiver-intent-based sender push– Mailing list– Stock and news ticker applications

• Senders control what and when to send

6

Application-Level Communication Model 2

• Receiver pull – ftp, http

• Sender-intent-based receiver pull– Pager service

• Receivers control what and when to fetch.

7

DMTP: Differentiated Mail Transfer Protocol

• Based on sender-intent-based rcver pull model• Extends the current SMTP protocol

8

DMTP

• Senders classified into three classes– Regular contacts– Well-known spammers– Unclassified senders

• Messages from each class handled differently– Regular contacts: sender push (SMTP)– Well-known spammers: reject connection, of course!– Unclassified senders: can only deliver short intent

• Different granularities– Sender email addresses (spoofing problem)– Sender Mail Transfer Agent (MTA) IP addresses

9

DMTP

• Unclassified senders– Store outgoing messages on their own MTA servers– Deliver intent through new MSID (msg ID) command

• Pulling messages from unclassified senders– If receiver decides to– Using the new GTML (get mail) command– Security: only MTA servers can retrieve messages– Outgoing msgs cannot stored third-party servers

• Minimizing impact of intent messages– Receiver MTAs can quarantine intent messages– Delivered to end-users in batch periodically

10

DMTP

• Sender classification defined only at MTA IP address levelSender classification defined only at MTA IP address level

11

DMTP: Advantages

• Spam delivery rate controlled by receivers• Spammers forced stay online for longer period

– Helping IP address based spam filtering such as RBL

• Regular correspondence handling same as SMTP• Can be incrementally deployed on the Internet

– Combined with any sender discouragement schemes such as challenge-response, greylisting, etc

– Only imposed on unclassified senders.

12

Simple Model of Spam Revenue

• In SMTP

– Determined by sending speed of spammer MTA

• In DMTP

– Controlled by receivers’ retrieval behavior/rate

13

Expected spammer revenue

• Without DMTP (SMTP)– Gathering max revenue (49990) within 2 units of time

• With DMTP– Max revenue dropped to 7812, only 16% of SMTP– Have to stay online for longer time window (1240)

14

Sending speed and number of MTA servers

• Employing faster MTA servers does not help• Employing more MTAs helps to some extent

– Diminishing return for spammers

15

Effects of Spam Retrieval Rate

• Max spammer revenue decreases as retrvl rate decreases• Higher retrvl rate required to profit when more MTAs emplyd

16

Summary and on-going work

• DMTP: a receiver pull based email system– Receivers control what and when to retrieve– Eliminating economy of scale that spammers rely on– Holding spammers accountability– Simple incremental deployment path

• On-going work– Implementing DMTP based on Sendmail

• More information– http://www.cs.fsu.edu/~duan/projects/dmtp/dmtp.htm– Receiver-Driven Extensions to SMTP, Zhenhai Duan,

Kartik Gopalan, Yingfei Dong, IETF Internet Draft. Jan, 2006.