----- Original Message -----
From: "Theodore Ts'o" <tytso@mit.edu>
To: "Paul Vixie" <vixie@vix.com>
Cc: <ietf@ietf.org>
Sent: Sunday, June 08, 2003 1:47 PM
Subject: Re: Engineering to deal with the social problem of spam
> On Sun, Jun 08, 2003 at 07:29:32AM +0000, Paul Vixie wrote:
> > tytso@mit.edu ("Theodore Ts'o") writes:
> >
> > > Bare keys will do; consider a system where people keep a list of those
> > > keys that they will accept mail. If someone tries to send mail and
> > > their key is not on the recipient's list, the mail is returned to them
> > > until they can perform a Hashcash calculation consuming a non-trivial
> > > amount of CPU time, at which point their key is placed on the
> > > recipient's list, and the sender can retry to send the message. If a
> > > recipient receives SPAM, they simply drop the key of the sender from
> > > their "ok-to-receive" list.
> >
> > i think that we could write this up as open source and widely distribute
> > it and publicize the hell out of it for the rest of our careers without
> > ever having it become common practice to reject-with-explaination all
> > e-mail that comes from unauthorized senders. therefore it can become,
> > at best, a system that radical and highly technical recipients can use.
> > we've got a number of those already. (this one sounds new and better.)
>
> In order for this to work, the request for the Hashcalc calculation
> has to be done automatically. If it requires manual intervention
> where the user sees the reject notice and then has to manually take
> action --- of course, it's doomed to fail. So this is something which
> would require modification to the MTA's in order for this to work.
>
> The easist way to automate such a scheme would be in the context of
> your "replace SMTP" proposal; it's just a matter of using bare keys +
> hashcash-style solution, instead of requiring a global PKI.
>
> - Ted
Good Idea. Sounds like a Pretty Good Protocol.
>