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

Sigh.

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.
   john



--On Tuesday, 01 June, 2004 18:36 -0400 Zhenhai Duan 
<duan(_at_)cs(_dot_)fsu(_dot_)edu> wrote:
> Hello,
>
> 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
> ============================================
> 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
> URL:   http://www.cs.fsu.edu/~duan
> =============================================