Other Directory Sites: SeekWonder | Directory Owners Forum
The following archive was created by hippie-mail 7.98617-22 on Thu May 27 1999 - 23:44:20
Austin Hill (austin@zks.net)
Mon, 5 Apr 1999 09:25:38 -0400
>-----Original Message-----
>From: Greg Broiles [mailto:gbroiles@netbox.com]
>Sent: Sunday, April 04, 1999 10:39 PM
>To: mgraffam@idsi.net; Adam Back
>Cc: cypherpunks@cyberpass.net; CodherPlunks@toad.com
>Subject: Re: technical solutions to spam
>
>
>At 06:38 PM 4/4/99 -0400, mgraffam@idsi.net wrote:
>>An alternative is the use PK crypto to give us tokens/stamps for email
>>exchange.
>
>Ick. Now you've added export control issues and patent issues.
>
>>In either case, we need user-end email clients.
>
>No, we need client-side proxies (at least for Windows and Mac boxes);
>they'll listen on the local machine's POP3 port, talk POP3
>with the local
>client (Eudora or Netscape or whatever), make an outbound POP3
>connection
>to the user's real mailserver, pull down the mail, process it
>(bouncing or
>marking unwanted mail), and pass it through to the end-user app.
>
<snip>
When we designed Freedom, we actually took this approach. Local SMTP, POP3
proxies, strong crypto and transparent message signing and authentication
techniques. This has allowed us to implement some REALLY strong anti-spam
technologies (Both for pseudonyms sending spam and receiving spam).
One of the problems/goals we had was to encourage persistent pseudonymity
for the accumulation of reputation capital. We figured that if SPAM got
so bad, that a user was willing to kill an old pseudonym and move to a new
one then the value of those pseudonyms are reduced. (The way people use
hotmail accounts until they become unusable and then switch them).
For that reason we developed a bunch of spam prevention techniques. We are
working on a whitepaper describing the techniques we implemented, but the
end result is that we believe that Freedom pseudonyms will be 99.99% spam
proof.
>Then again, that's not as much fun as writing a spam-proof
>strong-crypto
>mail client which will be feature-competitive with Eudora and
>its ilk - but
>it's probably possible to write it in a week or so, without unwanted
>contact with attorneys or other regulatory monsters.
>
>
This is what we did :) But we didn't design it as a client, rather an
application independent pseudonymous & anonymizing system. (It also took
a lot longer than a week for us, but we shot pretty high for the
requirements including HTTP, IRC and all other protocol support).
-Austin
_________________________________________________________________________
Austin Hill Zero-Knowledge Systems Inc.
President Montreal, Quebec
Phone: 514.286.2636 Ext. 226 Fax: 514.286.2755
E-mail: austin@zeroknowledge.com http://www.zeroknowledge.com
Zero Knowledge Systems Inc. - Nothing Personal
PGP Fingerprints
2.6.3i = 3F 42 A2 0D AF 78 20 ED A2 BB AD BE 8B 40 5E 64
5.5.3i = 77 1E 62 21 B3 F0 EB C0 AA 6C 65 30 56 CA BA C4 94 26 EC 00
keys available at
http://www.nai.com/products/security/public_keys/pub_key_default.asp
_________________________________________________________________________
>-----Original Message-----
>From: Greg Broiles [mailto:gbroiles@netbox.com]
>Sent: Sunday, April 04, 1999 10:39 PM
>To: mgraffam@idsi.net; Adam Back
>Cc: cypherpunks@cyberpass.net; CodherPlunks@toad.com
>Subject: Re: technical solutions to spam
>
>
>At 06:38 PM 4/4/99 -0400, mgraffam@idsi.net wrote:
>>An alternative is the use PK crypto to give us tokens/stamps for email
>>exchange.
>
>Ick. Now you've added export control issues and patent issues.
>
>>In either case, we need user-end email clients.
>
>No, we need client-side proxies (at least for Windows and Mac boxes);
>they'll listen on the local machine's POP3 port, talk POP3
>with the local
>client (Eudora or Netscape or whatever), make an outbound POP3
>connection
>to the user's real mailserver, pull down the mail, process it
>(bouncing or
>marking unwanted mail), and pass it through to the end-user app.
>
>>The average guy probably percieves a greater need for widespread spam
>>blocking than confidentiality.. so strong crypto can ride in on a
>>spamblocker's coat-tails, as it were.
>
>Let's not saddle the "block unwanted mail" problem with the
>complexity of
>writing & deploying crypto code if it's not necessary - as soon as you
>start monkeying with crypto, you're getting lawyers involved,
>and that's
>not something you want, trust me. :)
>
>You can get a pretty good solution to this problem by using a
>single token
>for incoming mail and a list of approved originators (to deal
>with mailing
>lists) - it'd even be pretty easy to keep the token in a
>constant location
>in the user's web space, and let the proxy refresh it
>automatically - e.g.,
>maybe I'd keep my token at <http://www.well.com/~gbroiles/mailtok.html>
>(there's nothing there), and you'd keep yours at
><http://www.isp.com/~mgraffam/somewhereelse.html> - the
>"bounce" message
>would tell senders to go look there, which will eliminate spammers (who
>certainly aren't going to be using valid return addresses),
>but your old
>friend from college won't have trouble figuring the system
>out. As long as
>there's some variability in the location of the token files,
>it won't be
>feasible to write harvester programs.
>
>Then again, that's not as much fun as writing a spam-proof
>strong-crypto
>mail client which will be feature-competitive with Eudora and
>its ilk - but
>it's probably possible to write it in a week or so, without unwanted
>contact with attorneys or other regulatory monsters.
>
>
>--
>Greg Broiles
>gbroiles@netbox.com
>PGP: 0x26E4488C
>
The following archive was created by hippie-mail 7.98617-22 on Thu May 27 1999 - 23:44:20