ietf
[Top] [All Lists]

Re: Engineering to deal with the social problem of spam

2003-06-08 22:40:41

on 6/8/2003 12:47 PM Theodore Ts'o wrote:

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.

If a key was linked to a sender address, wouldn't that give somebody
everything they'd need to send me mail (just send it as me, since I'm
going to read my own mail even if nobody else does)? What's to prevent a
group of blackhats in the ~Ukraine from having their farm of 3Ghz PCs
generate error responses all day, just to gather keys to sell along with
the associated addresses? How would I replace the key/address pair in all
of the good repositories -- but not the bad ones -- after my key were
compromised, especially if my own delivery server is responding to
requests on my behalf?

Isn't the only way out of this to require senders use certificates that
can be validated, proving that the sender has access to a private key
which roughly corresponds to that address?

I'm in agreement that we don't need a "global PKI" to do any of this. We
only (ha!) need a relatively simple and lightweight way to locate and
retrieve public keys associated with specific resources (additional
vouching systems would be useful but aren't immediately necessary). That
particular problem isn't too tough to solve when limited to a scope that
is somewhat smaller than "global PKI", and I think we'll actually get
something like that relatively quickly. I also think this is mostly a
chicken-and-egg problem at that level, and that we might find both the
chicken and the egg at the same time if we're willing to look a bit.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/




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