[Top] [All Lists]

Re: Getmail: A New Email Delivery Architecture to Control Spam

2004-06-01 17:31:46


This suffers from most of the problems associated with "solutions" like this one, which is that it requires that most of the email infrastructure needs to be replaced before it is effective. Otherwise, while it is easy to define the mechanism (see below), it is hard to imagine why the spammers (or many others) would use it.

To save you some trouble and research, this general strategy could be implemented by either of two existing mechanisms. One would be to just include a URL in the message body, rather than actual text. The other would be to take advantage of the MIME "external body" mechanism to send a reference to a body part, rather than the body part itself. Of course, to make it work, we would all have to start rejecting (or discarding) mail that contained anything other than external references or a very brief statement followed by a URL. That wouldn't be a hard test to make, but I can't imagine very many people doing it -- too many false positives for unwanted material, including your message and this response.

It is worth noting that some spammers, especially of the pornographic persuasion, use the URL method today, often with a subject line or introductory message line of the character of "hi. I'm Bambi and I have a brand new web cam, please click _here_ to see me and my friends doing exciting things". It doesn't seem to reduce the amount of spam very much.

Again, sigh.

--On Tuesday, 01 June, 2004 18:36 -0400 Zhenhai Duan <duan(_at_)cs(_dot_)fsu(_dot_)edu> wrote:


Apologize if it is not allowed to post paper here.

Attached please find an abtract paper of Getmail. Any comments
are appreciated. (below is some high level description of the
architecture and some of the advantages.)

We propose a new message delivery architecture, called Getmail.
The principal idea behind Getmail is to force the spammer to
dedicate storage for the Emails being sent out. Instead of the
entire message being directly delivered to the receiver (or
more precisely the receiver  side Mail Transfer Agent,  MTA)
from the  sender, only the message header (including the
ubject line with a limited length) is sent to the receiver.
The message  header is augmented with a field informing where
the  receiver can retrieve  the complete Email.

There are several advantages of this architecture. First,
Getmail forces the senders to maintain their messages and keep
their MTA servers up, before receivers retrieve the messages.
Thus Getmail makes it relatively easy to
identify spammers and facilitates the  design of schemes that
rely on IP addresses to block  spam messages.  Of course,
spammers  can still crack into other users'
machines to send spam, but clearly  it is orthogonal to the
problem we are dealing  with here and beyond the scope  of
this paper.  Second,  in the
current  system it costs  money and  time for  receivers to
receive and handle spams,  this is especially  true for users
who dial  up to their  ISPs.  By  only  delivering  message
headers  from  senders  to receivers, less  bandwidth,
storage,  and time will  be occupied  at the receiver side, and
senders will have a greater share of responsibility in
managing the messages they send. For example, senders hold
their messages until they are retrieved by receivers and clean
up the messages that are not read by receivers for a certain
amount of time.
Third, by forcing sender side
MTA servers to hold messages,  spammers will notice that a
large portion of  the  spam messages  are  not  read at  all.
As  a consequence,  the incentive to send spams is reduced.
Moreover, in the long run, spammers  will learn who are
interested  in a certain specific advertisement  (the ones
who  read the  spam  message), and  commercial advertisement
can  be  targeted   at  a  certain  group  of  interested
receivers, instead of being sent blindly to everyone.  In this
way, both advertisers and Internet users will benefit from
this learning process in a long run.

Zhenhai Duan
Assistant Professor
Department of Computer Science
Florida State University
Tallahassee, FL 32306-4530

Phone: (850) 645-1561
Fax:   (850) 644-0058
Email: duan(_at_)cs(_dot_)fsu(_dot_)edu

<Prev in Thread] Current Thread [Next in Thread>