hashcash spam prevention & firewalls

I am looking at writing some hashcash
(http://www.dcs.ex.ac.uk/~aba/hashcash/) based spam prevention
software.  The motivation for writing spam prevention software is that
spam is better combatted with technical methods than legal or
political (we do not want clueless politicians coming in ham-fisted
and requiring "Internet Drivers Licenses" or anti-spam legislation or
anything else, such actions will be hazardous for the future of
remailers, in my opinion).

(Hashcash is a way of proving that the sender has consumed a tunable
amount of CPU time.  The verification process consumes negligible CPU
time.  This allows us to require the would be spammer to spend say 20
seconds per mail, which will slow him down considerably, over his
current tactics of 1000 long Bcc lists allowing him to hand off
spamming tasks to mail servers.)

So what we want is a filter to bounce messages without the required
hashcash postage, we ideally want this to happen at the ISP or
organisational SMTP server end, rather than at the recipients end,
because a) it is simpler for 1 service provider to install software
than 100,000 neophytes, and b) it reduces bandwidth consumption on
dial up users pay per second lines as the spam is killed before they
see it.

The Right Way to do it perhaps is as an SMTP extension, however I
consider this impractical in the short term because as far as I know
there is no SMTP extension plug-in mechanism (other than access to the
source code, and lots of development time) and because there are a
large number of mail servers in use, and it will be expensive in
developer (that's me) time to provide patches for them all
(exarcebated by the fact that in many cases source will not be
available).

So these problems leave us scratching around for other more generic
approaches.  One method is to create a proxy which receives mail on
port 25 (as the SMTP server normally does) filters examining for
correct hashcash postage, and bounces if the postage is missing, and
forwards the mail on to the real SMTP server if the hashcash postage
is valid.  The real SMTP server would then be set to run on another
port... say port 26 which is reserved, and have the mail forwarded to
it at that port.  (You would want to disable non-local access to port
26 either at firewall or with SMTP server configuration if that is
possible).

Alternatively run the real SMTP server on another machine inside the
local network.

A few problems with this approach, firstly it may not be possible to
configure some SMTP server software to run at ports other than 25.  (I
know you can do it with sendmail: OOPort=26 does it.)  (If this is not
possible with a given SMTP server you can still run a proxy by running
the real SMTP server on another machine inside the network).

Secondly the proxy approach prevents some of the SMTP server functions
from operating properly because the process on the other end of the
socket is our hashcash proxy on localhost rather than the remote mail
hub (modern sendmails can be configured to perform reverse name
lookups on IP addresses, call ident (ident sucks anyway IMO), or block
based on IP address or domain, etc.)  Is this kind of thing likely to
be a big problem?

Another approach is to try to hook in a hashcash SMTP proxy filter at
the firewall.  I am not that familiar with firewalls.

Anyone have thoughts on the sorts of filtering you could install at
the firewall level, and how portable this would be based on installed
base of types of firewall?  (ie It is not interesting if you can do
nifty proxy functions with foobar firewall software if it is used by
<1% of sites, and the function is impossible with other firewall
software).

The required filter functionality is something like this in order of
desirability:

Accept the SMTP session.  Use an EHLO extension HASHCASH to say that
this server expects hashcash.  (Extended HELO is a method of
specifying SMTP extensions (I think)).  Accept the headers, and if a
valid hashcash postage is not included, hand off to the real
mailserver a site configurable bounce message.

If the postage is valid, replay the headers to the real SMTP server
(with IP masquerading so that the IP address appears to be coming from
the originator, so that the SMTP server will not get upset about
reverse DNS look up mismatches etc).  Then act as a dumb proxy for the
rest of the connection passing data through to the normal hashcash
server.


This still leaves open the question of the user generating their own
hashcash postage.  Again this could be problematic for neophytes.  One
solution is to include a URL for a web page including a javascript
hashcash generator -- this means that no new software must be
installed, the user cut and pastes the generated hashcash into their
message.

However things would be a whole lot simpler short term if the mail
originators ISP created the hashcash for him at the ISPs SMTP hub
where the user hands off his mail for further delivery.

The main problem with this is that the SMTP mail hub would be
overloaded by the CPU intensive task of generating hashcash.

There are a few techniques to reduce the overhead of preventing spam
with hashcash.  One is to require valid hashcash only on the first
message to a given address.  (Spammers being hit and run types, and
even having to generate hashcash for each spamee once would be
expensive for a spam list of 10 million unwilling spam recipients).
Better, is to require valid hashcash on all mail, _until_ the
recipient replies to a mail.  This is good because people rarely reply
to spammers.

Ordinary users who chit-chat backwards and forwards in mail generate
little added overhead for the hand off SMTP server -- the only
overhead being to generate say 5 seconds CPU worth of hashcash for
each new recipient the user sends to.

Then you add some hashcash accounting so that users who overspend
(consuming more than say 1 minutes CPU consumption on the server in a
24 hour period have their email bounced with explanation of how to
generate their own hashcash as a heavy user).

Figures would need tuning to see how they worked out in practice,
however it seems that it would be feasible to handle the whole
operation entirely at the sending and receiving SMTP servers.

Comments?

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

Adam Back wrote:
>I am looking at writing some hashcash
>(http://www.dcs.ex.ac.uk/~aba/hashcash/) based spam prevention
>software.  The motivation for writing spam prevention software is that
>spam is better combatted with technical methods than legal or
>political

Would this work for GSM phones as well? I believe that GSM-spam is becoming
a wide spread problem. In Finland the GSM phone numbers are published in
online databases where spammers get the numbers and they use free
Internet-to-GSM/SMS message services.

Using hashcash on the smartcard in a GSM phone would be really neat!


Mike.

At 12:59 AM 12/13/97 GMT, Adam Back wrote:
>(Hashcash is a way of proving that the sender has consumed a tunable
>amount of CPU time.  The verification process consumes negligible CPU
>time.  This allows us to require the would be spammer to spend say 20
>seconds per mail, which will slow him down considerably, over his
>current tactics of 1000 long Bcc lists allowing him to hand off
>spamming tasks to mail servers.)

So a remailer, such as Cracker, that might send out an average of 3,000
emails per day would be required to use up 3,000 * 20 secs = 17 hours of
cpu time per day.  Since a portion of these emails are to multiple
recipients, then let's add 1/3 extra hashcash CPU time, or a total of about
22 hours of CPU time per day.

Now since Cracker runs on old, antiquated equipment, easily two or more
years out of date, I think we need to double this figure.  (The Cracker CPU
is actually less than 1/4 of the speed of many up to date desktop
machines.)  So, we would need about 44 hours of CPU time each day.

Of course the Cracker mail system also runs various mail lists for EFGA.
So we will need hashcash for these messages as well.  If I wish to send out
a personal email to each of say 900 nyms, then I will have to generate 900
* 20 seconds, or 5 hours of hashcash time in order to send an individual
message to each nym.  I certainly can setup myself as a privileged user on
the Cracker SMTP port and bypass this requirement, but I'll need the
hashcash for the unknown destination address of final delivery.

Of course, since we might be able to delete the need for hashcash among
people who know each other, we could have Cracker build a database of
people who like to have privacy, and not have to generate the hashcash if
we find you in our files.  ISP's in general could handle the hashcash
generation at the SMTP level by keeping databases of who sends email to
whom.  It is of course far easier to do a single database lookup than to
generate the 20 seconds of hashcash.

I don't know.  I just don't understand the plan fully.  I'll have to think
about it some more.

  -- Robert Costner                  Phone: (770) 512-8746
     Electronic Frontiers Georgia    mailto:pooh@efga.org  
     http://www.efga.org/            run PGP 5.0 for my public key

Robert Costner <pooh@efga.org> writes:
> At 12:59 AM 12/13/97 GMT, Adam Back wrote:
> >(Hashcash is a way of proving that the sender has consumed a tunable
> >amount of CPU time.  The verification process consumes negligible CPU
> >time.  This allows us to require the would be spammer to spend say 20
> >seconds per mail, which will slow him down considerably, over his
> >current tactics of 1000 long Bcc lists allowing him to hand off
> >spamming tasks to mail servers.)
> 
> So a remailer, such as Cracker, that might send out an average of 3,000
> emails per day would be required to use up 3,000 * 20 secs = 17 hours of
> cpu time per day.  Since a portion of these emails are to multiple
> recipients, then let's add 1/3 extra hashcash CPU time, or a total of about
> 22 hours of CPU time per day.

Remailers require a different strategy.  With remailers you are trying
to discourage spammers from using the remailer, with email you are
also trying to discourage spammers, but you have to do it in ways
which is easy for neophytes to cope with.

With remailers people already have to get new software, and all of the
source is available, so it is relatively easy for us to add
requirements for hashcash postage into type I remailers, in to
mixmaster, and newnym.  Hashcash was originally designed for this.
There is an implementation on http://www.dcs.ex.ac.uk/~aba/hashcash/

Also Andy Dustman, who is the guy who administers the efga remailer
(right?) wrote a python interface to hashcash, and is keen on python
hacking.  I suspect efga remailer may even be written in python if
Andy had much to do with it :-)

So with remailers you insist that the sender generate the hashcash
with all of their remailer requests, you bounce it or silently trash
it if there is no valid hashcash.  Also I would highly recommend that
you use Ian Goldbergs exit man script for remailer delivery -- it
delivers via HotMail and other such free web based email systems, via
publically accessible proxies and ensures that your remailer address
doesn't appear in the headers where you are the exit remailer. 

> Of course the Cracker mail system also runs various mail lists for EFGA.

Mailing lists you have to realistically I think not use hashcash for.
The majordomo process would become overloaded if it had to generate
hashcash for each recipient of each message.  Similarly the poster
would be over loaded if he had to generate hashcash for each recipient
of the message.  (I would not like to have to generate 1000 (or
whatever the current readership is ) of 20 second hashcash stamps to
post this message to cypherpunks for instance).

The way to cope with this in hashcash filters is to exempt mailing
lists from hascash requirement via a user administered allow list.

(You could possibly auto detect mailing lists at the hashcash filter
agent -- the subscription process could be detected -- or more risky
in that spammers might work out a way to abuse this -- by recognising
the pattern of mails -- lots of mails with the same Sender, and
different From fields.

> Of course, since we might be able to delete the need for hashcash among
> people who know each other, we could have Cracker build a database of
> people who like to have privacy

I tend to argue against this include list -- remailers become less
useful if you can not send mail to anyone who can receive SMTP mail.
I prefer the exit man via HotMail approach to the send notification
that there is anonymous email ready to be picked up approach.

> ISP's in general could handle the hashcash generation at the SMTP
> level by keeping databases of who sends email to whom.

Yes.  This can work reasonably well because people do not reply to
spammers, and most email has a to and fro pattern.

> It is of course far easier to do a single database lookup than to
> generate the 20 seconds of hashcash.

> I don't know.  I just don't understand the plan fully.  I'll have to
> think about it some more.

Read the stuff on http://www.dcs.ex.ac.uk/~aba/hashcash/ it talks more
about remailers.

Adam

At 10:55 AM 12/13/97 GMT, Adam Back wrote:
>Remailers require a different strategy.  With remailers you are trying
>to discourage spammers from using the remailer, with email you are
>also trying to discourage spammers, but you have to do it in ways
>which is easy for neophytes to cope with.

I'm unsure that this is what we are trying to do at all.  I'm perfectly
willing to assume that a remailer gets it's mail into it.  The problem is
now that the remailer has to deliver the mail.  Under this plan, to deliver
mail there must be hashcash for the delivery to the point beyond the
remailer.  I'm suggesting that if the remailer sends out 3,000 messages
with a 1/3 sprinkling of CC'ed addresses on equipment that is half as fast
as normal equipment, the 20 seconds of hashcash will require an average of
44 hours of CPU time per day.  44 hours for the hashcash that is needed at
the destination SMTP, not the hashcash to get into the remailer.

HashCash has often been suggested as a method for throttling spam that
would be sent to remailers.  This is not what I was responding to.  I was
responding to a suggestion that ISPs start requiring hashcash.  I'm
honestly unclear as to whether the remailer must generate the hashcash for
the future SMTP's or if the suggestion is that the originator is generating
all of the hashcash.  Since remailers mangle the messages and regenerate
them, I am unsure if originator generated hashcash is to be made for the
destination mail port, or if the remailer must do this.

If there is in fact a requirement that the sender generate the hashcash,
then I am not sure this will work.  A nym reply block possibly does not
lead to an exit address, but rather to another reply block.  In fact, this
should always be the case.  There is no way for the sender of the email to
know this route, or how many reply blocks there are.  Any scheme which
permits the same hashcash to send a message to two nym reply blocks and a
destination address will also allow spammers to send spams to multiple
addresses with the same hashcash.

Not only with nyms, but with regular email addresses multiple hops may be
required to deliver email.  For instance, the address "rcostner@cpsr.org"
will deliver email to me.  This address forwards mail to "pooh@efga.org".
The efga domain cannot be POP'ed into, so this is then remailed to wherever
I'm POP'ing into this month.  Since the original sender cannot know this,
and since ALL email to me requires a minimum of two mail gateways to get to
me it seems that this hashcash plan has some problems.

Further, I highly dislike the notion of maintaining system level databases
of who is communicated with.  As in a quote from Adam Back's web page

     To solve this problem subscribers should put the mailing list
     address in a postage-free recipients list. 

Traditional "wire tapping" would require that a communications port be
monitored to find out who communications are being made with.  Under the
"postage free list" plan, this information sits in a file waiting to be
collected with no difficulty at all.  Implemented on the SMTP level, we
have a way of testing for who a person communicates with.  After a HELO, we
spoof in a MAIL FROM:, then look to see if we get a "559 HashCash Required"
error.

I've never been impressed with the hashcash method of thwarting spam.  I'm
just not really sure that a technical solution to spam will work in any event.


  -- Robert Costner                  Phone: (770) 512-8746
     Electronic Frontiers Georgia    mailto:pooh@efga.org  
     http://www.efga.org/            run PGP 5.0 for my public key

At 11:19 PM 12/13/97 GMT, Adam Back wrote:
>> If there is in fact a requirement that the sender generate the hashcash,
>> then I am not sure this will work.  A nym reply block possibly does not
>> lead to an exit address, but rather to another reply block.  In fact, this
>> should always be the case.  
>
>I am not sure I understand the comment above.  Why should a reply
>block always point to another reply block?
...
>To point the whole reply block back to another newnym address adds
>additional protection but I would have thought most people use only
>one reply block.

If a person sends email from the source that also houses his nym identity,
then all of the eggs are in one basket.  A nym that points to another nym,
that perhaps points somewhere else like hotmail is needed.  Using only one
nym is about as safe as not using encryption.  It's fine for most purposes,
but can be broken.

I have gotten telephone requests from police, attorney general prosecutors,
private detectives, and others that ask for the identity of a remailer user
to be identified.  These are refused.  But I don't play games.  My response
is always I don't know, but if I did, I wouldn't tell you.

The attack on a single reply block is simple.  If the remailer machine is
seized, or if a VALID court order is received, we would turn the name over.
 (if anything about the request is incorrect, then we would refuse the
request and do so legally)  If we pull up the nym HashMan@anon.efga.org and
discover it is aba@dcs.ex.ac.uk then the anonymity is over.  If however it
points to MrHash@anotherremailer then the identity is preserved a little
bit longer.  The only way to breach this is to seize all remailers at the
same time.

Better security would be had by having a public nym that receives email,
and a private nym that delivers email.

  -- Robert Costner                  Phone: (770) 512-8746
     Electronic Frontiers Georgia    mailto:pooh@efga.org  
     http://www.efga.org/            run PGP 5.0 for my public key

Robert Costner <pooh@efga.org> writes:
> At 10:55 AM 12/13/97 GMT, Adam Back wrote:
> >Remailers require a different strategy.  With remailers you are trying
> >to discourage spammers from using the remailer, with email you are
> >also trying to discourage spammers, but you have to do it in ways
> >which is easy for neophytes to cope with.
> 
> I'm unsure that this is what we are trying to do at all.  I'm perfectly
> willing to assume that a remailer gets it's mail into it.  The problem is
> now that the remailer has to deliver the mail.  Under this plan, to deliver
> mail there must be hashcash for the delivery to the point beyond the
> remailer.

Simplest thing to do for non-replyable remailers is to insist that the
originator include hashcash for each remailer hop.  Then remailers can
just refuse to remail anything unless there is a valid hashcash
postage token included.  For example:

	Hashcash-Postage: 10208remailer@efga.orgb35b746c387ff6bc

Is a 20 bit hash collision on remailer@efga.org.  (Antonomasia sent me
a patch sometime back for hashcash which changed the hashcash syntax
to:

	Hashcash-Postage: 10208:remailer@efga.org:b35b746c387ff6bc 

which is easier to parse.  (He also simplified the command line
interface... mine is a bit scruffy)).

To send through remailer@efga.org and remailer@replay.com, you would
include a hashcash postage stamp for each remailer.

So you add to the remail instructions for remailer@efga.org a hashcash
postage stamp:

	::
	Request-Remailing-To: remailer@replay.com
	Hashcash-Postage: 10208remailer@efga.orgb35b746c387ff6bc

and to the nested encrypted remailing instructions for replay you add
a hashcash stamp for it too:

	::
	Request-Remailing-To: replay.com
	Hashcash-Postage: 10208replay.com05e4fee159c1cfc9

> HashCash has often been suggested as a method for throttling spam that
> would be sent to remailers.  This is not what I was responding to.  I was
> responding to a suggestion that ISPs start requiring hashcash.  I'm
> honestly unclear as to whether the remailer must generate the hashcash for
> the future SMTP's or if the suggestion is that the originator is generating
> all of the hashcash.  

The originator must generate the hashcash for all hops.

> Since remailers mangle the messages and regenerate them, I am unsure
> if originator generated hashcash is to be made for the destination
> mail port, or if the remailer must do this.

The hashcash proposal was originally focussed on remailers, and for
this purpose it is suggested that the originator generate all postage.

> If there is in fact a requirement that the sender generate the hashcash,
> then I am not sure this will work.  A nym reply block possibly does not
> lead to an exit address, but rather to another reply block.  In fact, this
> should always be the case.  

I am not sure I understand the comment above.  Why should a reply
block always point to another reply block?

It provides pretty good security to have a newnym address which when
mail is sent to it, the newnym server looksup that nyms reply block,
and mails the message with that reply block prepended to the
designated first hop remailer.  The reply block chain can have several
hops, and can even end up in a newsgroup via a mail2news gateway, or
typeI remailer.

To point the whole reply block back to another newnym address adds
additional protection but I would have thought most people use only
one reply block.

> There is no way for the sender of the email to know this route,

A good point.

You have to restructure the payment to cope with this.  Here are a few
ideas:

- One way to do it is to require the nym owner to pre-pay hashcash
postage for mails he receives.  When the postage runs out, the
delivery ceases.  However this provides a denial of service attack
against the newnym user -- just have more CPU than him and you can
prevent him getting any real replies by spamming him.

- Another is to require postage only for the entry remailer.  This
however begs the question of what is a remailer.  There are problems
with assuming there is some official list of "remailers".  For example
if I am a spammer and I want to spam I will call myself a remailer,
and spam via the other remailers from this vantage point apparently
within the fold, it will be difficult to detect me.  I might even
remail the odd message to keep up appearances.

- A distributed hashcash double spend database could allow remailers
to accept hashcash which wasn't directed to them specifically, but
rather, which was directed to any remailer.  Remailers would propogate
hashcash database updates.  This preserves anonymity because hashcash
says nothing about the person who minted the hashcash stamp.  However,
interestingly, it would be necessary for the remailers to anonymously
remail database updates because revealing the remailer which received
the hashcash token would allow the newnym reply blocks to be traced.
Disruptive remailers could remove all of the hashcash tokens as the
sender would be forced to send them all to be readable by the first
remailer, not knowing the identity of the rest of the remailers.  Not
a big problem I think because remailers which do this can be weeded
out statistically, and will suffer in the remailer ping league tables
for such behaviour.  They can already disrupt pretty well if inclined
-- just discard messages.

- Or more simply, but more expensively for the sender, include a
couple of hashcash tokens for all of the remailers (there being only
20 or so).

> Not only with nyms, but with regular email addresses multiple hops may be
> required to deliver email.  For instance, the address "rcostner@cpsr.org"
> will deliver email to me.  This address forwards mail to "pooh@efga.org".
> The efga domain cannot be POP'ed into, so this is then remailed to wherever
> I'm POP'ing into this month.  Since the original sender cannot know this,
> and since ALL email to me requires a minimum of two mail gateways to get to
> me it seems that this hashcash plan has some problems.

This an interesting problem that I have not seen raised before.  One
way to get around it would be to allow mail from rcostner@cpsr.org to
arrive at pooh@efga.org without hashcash, and for mail from
pooh@efga.org to arrive at your pop this month without hashcash also.
You would allow via a token which you would not make generally
available.  That is you would say set up the .forward file not to send
to pooh@efga.org, but:

	Robert Costner c387ff6bcb35b746 <pooh@efga.org>

Then instruct the ISP side hashcash based filtering agent at efga.org,
to allow this token through.  Similarly for the second hop from
efga.org to this months POP. 

> Further, I highly dislike the notion of maintaining system level databases
> of who is communicated with.  As in a quote from Adam Back's web page
> 
>      To solve this problem subscribers should put the mailing list
>      address in a postage-free recipients list. 
> 
> Traditional "wire tapping" would require that a communications port be
> monitored to find out who communications are being made with.  Under the
> "postage free list" plan, this information sits in a file waiting to be
> collected with no difficulty at all.  Implemented on the SMTP level, we
> have a way of testing for who a person communicates with.  After a HELO, we
> spoof in a MAIL FROM:, then look to see if we get a "559 HashCash Required"
> error.

This is a major danger I agree.  Bill Stewart suggested hashing the
database entries, which complicates things for the attacker, but not
as much as we would like.

I am 100% with you on the dangers of supeonaed postage free lists.

How about this alternative which achieves the same functionality and
removes the juicy supeona target:

Turn on hashash database for all mails.  That means hashcash gets put
in the database to prevent double spending.  (If we don't do this
spammers will club together and do one mega-spam reusing the same
hashcash they generated with their spam fest motivated CPU farm and
hit you with spam from many addresses, or all forged as from the same
address or whatever).

So now when you reply to a message, on it's way out via the mail hub,
you remove that hashcash token from the double spending database.
This means that the sender can cache sent hashcash tokens, and re-use
them when after he gets a reply.

Neat.

> I've never been impressed with the hashcash method of thwarting
> spam.  I'm just not really sure that a technical solution to spam
> will work in any event.

Technical solutions to spam are not easy.

However hashcash is reasonably flexible in what you can do with it,
and real payee and payer anonymous ecash even more so, and I figure we
ought to give it a go because the non-technical solutions involve
low-life politicians trying to solve the spam problems for us, and
introducing legislation giving jail time for forged From fields,
trying to introduce internet drivers licenses, and deputising ISPs to
try to enforce the mess.  It is unclear how remailers would fare in
such a scenario.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

I disagree that the best way to implement hashcash is solely via the SMTP mechanism.  

Almost any efficient hashcash mechanism will require some sort of history file, or "invited list," to allow mail lists and those we have corresponded with to continue to do so w/i having to supply hashcash each time.  This list contains information which might have privacy implications and so should not be stored at the ISP, which can be forced to reveal such info w/o the knowledge of the client.

If 'open' list policies were changed so that anyone could post if they supplied enough hashcash for each mailing list recipient for their first 1 or 2 posts, and thereafter no longer needed to supply hashcash (sort of minimum reputation capital), it might eliminate hit-and-run or throw-away account SPAMers without offering too high a hurdle to new or infrequent posters.

Since most popular email clients allow plug-ins (e.g. Eudora) or extensions via Java/ActiveX, providing hashcash functionality via a plug-in and the java generators you propose would provide a simple mechanism to test its effectiveness w/o needing to involve the IETF.  The shortcoming of a plug-in approach is that few newbies will know of it or install it and will therefore have to wait till its built into the new release of whatever client they use or until some or all of the features are supplied by their ISP, allowing those calling regulation to continue to blow their horns.  However, if after a successful cypherpunk beta we could get the major email client companies (Netscape, M$ and Qualcomm) to include our plug-ins with all their new updates and offer them for free download from their Web sites, it could quickly steal the CAUCE folk's thunder.

--Steve

Steve Schear <schear@lvdi.net> writes:
> I disagree that the best way to implement hashcash is solely via the SMTP
>  mechanism.

It is nicest to implement the blocking at the SMTP agent if this can
be done in a privacy preserving manner, because it reduces the
bandwidth consumption for users, and reduces the complexity of their
local software -- they only need to generate hashcash for outgoing
mail.

> Almost any efficient hashcash mechanism will require some sort of history
>  file, or "invited list," to allow mail lists and those we have corresponded
>  with to continue to do so w/i having to supply hashcash each time.  This
>  list contains information which might have privacy implications and so
>  should not be stored at the ISP, which can be forced to reveal such info
>  w/o the knowledge of the client.

See my post to Bill Stewart with 

	Subject: supeona immune postage free list

I think you can construct ways to allow the ISP to reject messages
without postage, and to allow frequent users to be exempt, and to do
this such that there is no invited list which becomes a juicy target.

> If 'open' list policies were changed so that anyone could post if they
>  supplied enough hashcash for each mailing list recipient for their first 1
>  or 2 posts, and thereafter no longer needed to supply hashcash (sort of
>  minimum reputation capital), it might eliminate hit-and-run or throw-away
>  account SPAMers without offering too high a hurdle to new or infrequent pos
> ters.

That is an interesting thought.  Well the interesting thought is that
it gives us a way to block spam at the list server, because a) the
spammer has to overcome the hurdle you described, and b) the list
operator could punish spammers who started spamming once getting over
the hurdle by blocking them.  The usual trick of switching to a
different address, or a remailer would not work because they would
still have to generate a new hashcash coin as the list operator could
block the coin.

I would however think that a large denomiation coin made out to the
list server would make more sense than generating lots of coins for
all of the list subscribers.

However there is a nasty side to the above, in that it encourages the
list operator to censor posts he considers spam.

It would be simpler and I think tend to less encourage censorship to
introduce a third party filtering service such as Ray Arachellian's,
and the other one, which had an option to have only spam filtered out.

At this moment in time the spam content on mailing lists I am on is
very low.  I get much more in email.

Doubtless this would change when spammers discovered that email spam
is too CPU expensive to use.

Also hashcash really doesn't work well for USENET.  NoCeM's are cool
things for USENET, a distributed ratings system, and I understand can
be configured to work for mailing lists also.

> Since most popular email clients allow plug-ins (e.g. Eudora) or extensions
>  via Java/ActiveX, providing hashcash functionality via a plug-in and the
>  java generators you propose would provide a simple mechanism to test its
>  effectiveness w/o needing to involve the IETF.  

You can do a lot with local SMTP and POP3 proxies.

There are a couple of java ones around.

Anyone know if there is code available to do SMTP and POP3 proxying?

I am told by one subscriber to look at TIS firewall toolkits imap
program.

> The shortcoming of a
>  plug-in approach is that few newbies will know of it or install it and will
>  therefore have to wait till its built into the new release of whatever
>  client they use or until some or all of the features are supplied by their
>  ISP, 

Yes, this problem is the motivation for trying to work out ways that
as much as possible could happen at the ISP side for less technical
users, and even for technical users, I know few people are interested
to install new software.

Also ISPs often seem more concerned about spam abuse than users.

> allowing those calling regulation to continue to blow their horns. 
>  However, if after a successful cypherpunk beta we could get the major email
>  client companies (Netscape, M$ and Qualcomm) to include our plug-ins with
>  all their new updates and offer them for free download from their Web
>  sites, it could quickly steal the CAUCE folk's thunder.

It would be cool if we could pull that one off.

Do we have anyone on list who is familiar with eurdora, qualcomm and
netscape plugins who would like to interface a hashcash library to
these systems?

Anyone who can write java applets want to implement a java hashcash
library?  (Should be easy.. jdk1.1.3 includes a sha1 function ... I am
not sure if this is included with netscape 4 or not, but there are
also numerous sha1 native java codes around, www.systemics.com being
one).

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

>Steve Schear <schear@lvdi.net> writes:
>> I disagree that the best way to implement hashcash is solely via the SMTP
>>  mechanism.
>
>It is nicest to implement the blocking at the SMTP agent if this can
>be done in a privacy preserving manner, because it reduces the
>bandwidth consumption for users, and reduces the complexity of their
>local software -- they only need to generate hashcash for outgoing
>mail.
>
>> Almost any efficient hashcash mechanism will require some sort of history
>>  file, or "invited list," to allow mail lists and those we have corresponded
>>  with to continue to do so w/i having to supply hashcash each time.  This
>>  list contains information which might have privacy implications and so
>>  should not be stored at the ISP, which can be forced to reveal such info
>>  w/o the knowledge of the client.
>
>See my post to Bill Stewart with 
>
>	Subject: supeona immune postage free list
>
>I think you can construct ways to allow the ISP to reject messages
>without postage, and to allow frequent users to be exempt, and to do
>this such that there is no invited list which becomes a juicy target.
>
>> If 'open' list policies were changed so that anyone could post if they
>>  supplied enough hashcash for each mailing list recipient for their first 1
>>  or 2 posts, and thereafter no longer needed to supply hashcash (sort of
>>  minimum reputation capital), it might eliminate hit-and-run or throw-away
>>  account SPAMers without offering too high a hurdle to new or infrequent pos
>> ters.
>
>That is an interesting thought.  Well the interesting thought is that
>it gives us a way to block spam at the list server, because a) the
>spammer has to overcome the hurdle you described, and b) the list
>operator could punish spammers who started spamming once getting over
>the hurdle by blocking them.  The usual trick of switching to a
>different address, or a remailer would not work because they would
>still have to generate a new hashcash coin as the list operator could
>block the coin.
>
>I would however think that a large denomiation coin made out to the
>list server would make more sense than generating lots of coins for
>all of the list subscribers.
>
>However there is a nasty side to the above, in that it encourages the
>list operator to censor posts he considers spam.
>
>It would be simpler and I think tend to less encourage censorship to
>introduce a third party filtering service such as Ray Arachellian's,
>and the other one, which had an option to have only spam filtered out.
>
>At this moment in time the spam content on mailing lists I am on is
>very low.  I get much more in email.
>
>Doubtless this would change when spammers discovered that email spam
>is too CPU expensive to use.
>
>Also hashcash really doesn't work well for USENET.  NoCeM's are cool
>things for USENET, a distributed ratings system, and I understand can
>be configured to work for mailing lists also.
>
>> Since most popular email clients allow plug-ins (e.g. Eudora) or extensions
>>  via Java/ActiveX, providing hashcash functionality via a plug-in and the
>>  java generators you propose would provide a simple mechanism to test its
>>  effectiveness w/o needing to involve the IETF.  
>
>You can do a lot with local SMTP and POP3 proxies.
>
>There are a couple of java ones around.
>
>Anyone know if there is code available to do SMTP and POP3 proxying?
>
>I am told by one subscriber to look at TIS firewall toolkits imap
>program.
>
>> The shortcoming of a
>>  plug-in approach is that few newbies will know of it or install it and will
>>  therefore have to wait till its built into the new release of whatever
>>  client they use or until some or all of the features are supplied by their
>>  ISP, 
>
>Yes, this problem is the motivation for trying to work out ways that
>as much as possible could happen at the ISP side for less technical
>users, and even for technical users, I know few people are interested
>to install new software.
>
>Also ISPs often seem more concerned about spam abuse than users.
>
>> allowing those calling regulation to continue to blow their horns. 
>>  However, if after a successful cypherpunk beta we could get the major email
>>  client companies (Netscape, M$ and Qualcomm) to include our plug-ins with
>>  all their new updates and offer them for free download from their Web
>>  sites, it could quickly steal the CAUCE folk's thunder.
>
>It would be cool if we could pull that one off.
>
>Do we have anyone on list who is familiar with eurdora, qualcomm and
>netscape plugins who would like to interface a hashcash library to
>these systems?
>
>Anyone who can write java applets want to implement a java hashcash
>library?  (Should be easy.. jdk1.1.3 includes a sha1 function ... I am
>not sure if this is included with netscape 4 or not, but there are
>also numerous sha1 native java codes around, www.systemics.com being
>one).
>
>Adam
>-- 
>Now officially an EAR violation...
>Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
>
>print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
>)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

...
> So, we would need about 44 hours of CPU time each day.

Well, have a system of certified remailers trusted to force their users to burn
up time at the sending end, so the ultimate recipient accepts their messages
w/o postage. One certified remailer accepts messages from others without any
postage, so only the original sender has to use up CPU time. 

>   -- Robert Costner                  Phone: (770) 512-8746
>      Electronic Frontiers Georgia    mailto:pooh@efga.org  
>      http://www.efga.org/            run PGP 5.0 for my public key

---------------------------------------------------------------------------
Randall Farmer
    rfarmer@hiwaay.net
    http://hiwaay.net/~rfarmer

At 02:07 PM 12/13/97 -0600, Uhh...this is Joe [Randall Farmer] wrote:
>> So, we would need about 44 hours of CPU time each day.
>
>Well, have a system of certified remailers trusted to force their users to
burn
>up time at the sending end, so the ultimate recipient accepts their messages
>w/o postage. One certified remailer accepts messages from others without any
>postage, so only the original sender has to use up CPU time. 

Once again someone is responding to me by talking about hashcash in the
internal remailer network.  I don't think this is what I'm referring to.
Perhaps because I do not fully understand how anti spam hashcash would be
implemented on a per message basis.

The idea proposed was one to limit Spam to ISPs by using hashcash to stop
spam coming into an ISP.  Imagine the domain anon.efga.org wishes to send
4,000 per day messages to the various domains netcom.com, aol.com,
mindspring.com, etc.  Each individual message is reasonably unique coming
from anon.efga.org.  Since we need hashcash now to LEAVE a remailer, not to
enter one, where does this hashcash come from?  A busy remailer could not
generate it's own hashcash for the destination non-remailer ISPs.

Does the same hashcash that allows a message to enter the remailer network
also retain it's validity once the message has been rewritten by the
remailer?  Is this hashcash still valid for the destination mail server at
netcom?  Does the initial sender provide two instances of hashcash, one to
get into the remailer, and one to get into the destination mail system?

Various remailers can distort a message in a variety of ways.  Dropping of
MIME attachments, munging of email addresses when CC'ed to a newsgroup,
adding a PGP signature or timestamp, adding headers that explain it's a
remailer, adding footers that explain it's a remailer.  Since the actual
message can change, it seems that for hashcash to be message dependent, it
would have to be generated by the exit remailer.

I'm not claiming I understand the concept of hashcash.  I'm simply pointing
out I don't see how it would truly be effective in a real world application.


  -- Robert Costner                  Phone: (770) 512-8746
     Electronic Frontiers Georgia    mailto:pooh@efga.org  
     http://www.efga.org/            run PGP 5.0 for my public key

>> > So, we would need about 44 hours of CPU time each day.
>> >Well, have a system of certified remailers trusted to force their 
>> >users to burn up time at the sending end, so the ultimate recipient
>> >accepts their messages w/o postage. One certified remailer accepts
>> >messages from others without any postage, so only the original
>> >sender has to use up CPU time. 
>...
>> Since we need hashcash now to LEAVE a remailer, not to enter one,
>> where does this hashcash come from?  A busy remailer could not
>> generate it's own hashcash for the destination non-remailer ISPs. 
>
>This is exactly what I was addressing: remailers only have to get themselves
>certified as remailers and then prove their certification to the destination

You're both taking the wrong approach - make the originator of the message
generate the hashcash, and make sure the remailer syntax lets them paste it in
as needed.  For chained remailers, generate multiple layers of hashcash.
Maintaining whitelists is a losing game, but unnecessary here.

Mailing lists are still hard, and perhaps best handled by the user's software
(or some fancy variant like user-selectable filters at the ISP mailbox.)
It's hard to tell a real mailing list from a spammer's mailing list,
and both of them do mail explosion and send their mail to names not 
listed in the To: line, so it's hard to do a technical fix.
There are scads of attacks against any fix, like having 
disposable_user@juno.com join the mailing list for a while and them spam it.
But remailers are easy.
				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

On 22 Dec 1997 14:15:31 -0600, Adam Back <aba@dcs.ex.ac.uk> wrote:

>The more thorny problem to solve is that posed by Robert Costner: what
>do you do about nyms.  You (the sender) can't include postage for nym
>reply blocks because you don't know (and mustn't know) the remailer
>chain pointed to by the reply block.

Could you throw hashcash into the reply block?  This would, of course, make
reply blocks non-reusable. 

Perhaps all remailers could agree to accept hashcash made out to a generic
name like "remailer".  This way, the sender can just generate X coins
without worrying about which remailers the message would go through.  The
only problem is that the sender would have to know how many coins to
generate.

Actually, if the message never went through the same remailer twice, only
one coin would needed.  Set up the remailers so that they don't strip away
a coin made out to "remailer".  There could be problems with tracking the
message though.


>
>> Mailing lists are still hard, and perhaps best handled by the user's
>> software (or some fancy variant like user-selectable filters at the
>> ISP mailbox.)
>
>I think it's simplest to have the user explicitly allow the mailing
>list.
>
>You could possibly auto detect the pattern of a user subscribing to a
>mailing list at the mail filter level also.
>

Each user will probably have a list of names that he will accept coins for.
Mail sent to a listserver could have a coin made out to
"listserver@foo.bar".  The listserver could, after checking the coin,
simply pass that coin along with the message to everyone subscribed on the
list.  The end user will receive a coin made out to "listserver@foo.bar".
If that name is on his list, the coin will be checked; otherwise the
message is automatically dropped/bounced/whatever.

This way, the listserver is never burdened with generating hashcash; but
those who send messages to the list are (but they only have to generate one
coin for each message).

-- Phelix

Bill Stewart <bill.stewart@pobox.com> writes:
> >This is exactly what I was addressing: remailers only have to get
> >themselves certified as remailers and then prove their certification
> >to the destination
> 
> You're both taking the wrong approach - make the originator of the
> message generate the hashcash, and make sure the remailer syntax
> lets them paste it in as needed.  For chained remailers, generate
> multiple layers of hashcash.  Maintaining whitelists is a losing
> game, but unnecessary here.

This works well enough.

The more thorny problem to solve is that posed by Robert Costner: what
do you do about nyms.  You (the sender) can't include postage for nym
reply blocks because you don't know (and mustn't know) the remailer
chain pointed to by the reply block.

> Mailing lists are still hard, and perhaps best handled by the user's
> software (or some fancy variant like user-selectable filters at the
> ISP mailbox.)

I think it's simplest to have the user explicitly allow the mailing
list.

You could possibly auto detect the pattern of a user subscribing to a
mailing list at the mail filter level also.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

At 5:55 PM +0000 12/22/1997, Adam Back wrote:
>Bill Stewart <bill.stewart@pobox.com> writes:
>> >This is exactly what I was addressing: remailers only have to get
>> >themselves certified as remailers and then prove their certification
>> >to the destination
>> 
>> You're both taking the wrong approach - make the originator of the
>> message generate the hashcash, and make sure the remailer syntax
>> lets them paste it in as needed.  For chained remailers, generate
>> multiple layers of hashcash.  Maintaining whitelists is a losing
>> game, but unnecessary here.
>
>This works well enough.
>
>The more thorny problem to solve is that posed by Robert Costner: what
>do you do about nyms.  You (the sender) can't include postage for nym
>reply blocks because you don't know (and mustn't know) the remailer
>chain pointed to by the reply block.

eCache is probably the best solution for remailers (and probably SPAM in general) since real value can pass anonymously from sender to receptient.

>
>> Mailing lists are still hard, and perhaps best handled by the user's
>> software (or some fancy variant like user-selectable filters at the
>> ISP mailbox.)
>
>I think it's simplest to have the user explicitly allow the mailing
>list.

Yes, especially when the list requires a hashcash 'initiation,' before allowing unlimited postings, to prevent many  common list SPAM abuses.

--Steve

At 11:48 PM 12/13/97 GMT, Adam Back wrote:
>However, generally I have been assuming that it's easier to have a
>double spend database, and to make the hashcash depend only on the
>resource name for the kinds of problems you raise, and because it is
>cheaper to verify hashcash on shorter strings.  By resource name I
>mean whatever it is that is being used.  For an email address it is
>the email address, for a remailer it is the remailers address.  Could
>be generalised for other purposes, for example free use of web based
>resources or even telnet based TCP/IP protocols in general.

As a technological fix for spam, destination address hashcash seems to be
lacking.  All this does is raise the wall of entry into becoming a
spamhause from one PC to say, ten.  It is not much more difficult to sell a
CD-ROM with one million email addresses & hashcash.   A 20 second hashcash
expenditure on one million email addresses will take about 231 CPU days, or
about three weeks if you use ten machines.  Sell 500 copies of the CD-ROM
for $500, and you net $250K, easily enough profit to purchase the $20K of
machines or even to rent them for one month.  After six months, you will
have around eight million pieces of hashcash from the computational power
of only ten machines.  This says nothing of the profits from actually
sending spam.

The implementation of the plan is a more or less impossible scheme.  Many
people like myself exist who do not care from spam, but wish to receive
email from anyone who legitimately sends it.  I can only see a hashcash
anti-spam plan working when you have a closed list of people who generally
know each other.  While the mail gateway I use could easily be converted to
a hashcash enabled gateway, I have no interest in refusing email from those
who do not have hashcash gateways.

To be an anti-spam measure for ISPs, hashcash would have to be based on the
destination email address, the text of the message in some fashion, and
possibly on other factors such as a timestamp or a from address.  Hashcash
tied to a from address as well as the destination would do a lot for spam
filters.  Using all or a portion of the message body, say every 23
characters in a round robin fashion until 50 sample body message characters
had been collected would make hashcash non reusable and not sellable.

Any ISP hashcash plan still does not take into account the effect of
services like hotmail, rocketmail, and the like who will need to generate
hashcash for the destination address because they exist to shield the
destination address from the sender.  Changes to the "Don't charge postage"
database will be awkward.  There are some serious privacy problems with
warehousing with your ISP a list of your other email addresses, or the
addresses of your postage free friends.


  -- Robert Costner                  Phone: (770) 512-8746
     Electronic Frontiers Georgia    mailto:pooh@efga.org  
     http://www.efga.org/            run PGP 5.0 for my public key

>On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote:
>Yes, but if you just phase it in over time, what benefit, if any, will
>users see until hashcash is fully deployed.  Until that time, people will
>still have to accept email without hashcash or risk losing important
>messages. 

If I want to send an important message to you and I get a hashcash rejection reponse and I'm given a Web site where I can get a Java applet to create the hashcash, I'll do it.  We all know we must affix postage to our snailmail. Its time to embrace the postal system's paradigm and educate the reminder of the Net.  Those who risk missing an email or two will totally stop their SPAM. Those who won't, won't.

>I don't see people adopting hashcash unless there is some intermediate
>benefit to doing so.

All we need is a small, influential, group to sing the praises of hashcash.  I'm sure Declan and Wired will pick up the banner if what we come up with works.  After that IETF activity is a far gone conclusion.

--Steve

-----BEGIN PGP SIGNED MESSAGE-----

In <v03102806b0bdff5466dc@[208.129.55.202]>, on 12/17/97 
   at 05:26 PM, Steve Schear <schear@lvdi.net> said:

>>On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote:
>>Yes, but if you just phase it in over time, what benefit, if any, will
>>users see until hashcash is fully deployed.  Until that time, people will
>>still have to accept email without hashcash or risk losing important
>>messages. 

>If I want to send an important message to you and I get a hashcash
>rejection reponse and I'm given a Web site where I can get a Java applet
>to create the hashcash, I'll do it.  We all know we must affix postage to
>our snailmail. Its time to embrace the postal system's paradigm and
>educate the reminder of the Net.  Those who risk missing an email or two
>will totally stop their SPAM. Those who won't, won't.

>>I don't see people adopting hashcash unless there is some intermediate
>>benefit to doing so.

>All we need is a small, influential, group to sing the praises of
>hashcash.  I'm sure Declan and Wired will pick up the banner if what we
>come up with works.  After that IETF activity is a far gone conclusion.

Well IMNSHO hashcahs mail sucks!! It opens up the pandora's box of usage
based charges for everything done on the 'net. What will be next? FTP
sites charging hashcash for DL's? WebPages charging hashcash per hit? DNS
servers charging per lookup? Routers charging per packet?

Note: In Adams proposal for hashcash only charges the user CPU cycles. The
incentive for wide implementation of hashcash is going to be a real ecash
based system where the implementors can make $$$ off it.

All this talk of "educating" the user is scary. After the newspeak
translation: "Lets condition the sheeple to accept a metered rate Internet
even though they don't want it".

Hashcash is an evil worse than a 1000 Spamfords. I will not support
Hashcash now or in the future and will do my best to stop its spread. As a
matter of fact I plan on writtin Declan on this personaly. I also plan to
form a coalition to block any adoption of hashcash within the IETF. Hmmmmm
sounds like a good BOF for LA :)

This crap will do nothing but place an unnecessary burdon on users while
doing *nothing* to stop SPAM.

I have *PAID IN FULL* for my Inet usage!! What bits I send over the Inet,
how many bits I send, and who I send them to is NO ONE's BUSINESS but my
own!!! -- Last Anarchist of the Inet.

- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNJmTx49Co1n+aLhhAQLc6QP/YDyeSPwmqhKaLTyBiU236/2hlKCMRmaW
tRuPhIGE76aO4JQqRIxSvVeSJsH3qvm7VW6OPn93gHQqji0OOcAbniZyYJuLJFx/
EHeuj2+FiFjVaHZNu2HhPS5x22AmeMNb0a8OtZFZVHYCobHTYpYvxzJVWCll7sCu
mm3jGp16eZQ=
=XLxl
-----END PGP SIGNATURE-----

At 4:21 pm -0500 on 12/18/97, William H. Geiger III wrote, 
though not in this order,

>> I have *PAID IN FULL* for my Inet usage!! What bits I send over the Inet,
>> how many bits I send, and who I send them to is NO ONE's BUSINESS but my
>> own!!! -- Last Anarchist of the Inet.

You've paid for your end of the connection, but you haven't paid for mine,
and you especially haven't paid for getting your bits to my eyeballs.
Neither has Spamford.  I'm usually willing to read your words, but not his.
Hashcash-mail is a tool for users to use to automate limiting the email 
they receive to mail sent out by real individuals who actually want to 
communicate with them, throwing away mail from spammers.

Whether it will catch on or not is a social issue.  There are telephone
answering devices that prompt for a password and either hang up on callers
who don't have one, forward them to the answering machine, or just
give them a low-priority ring.  I don't use one, and nobody I know
currently does, because they annoy the callers you care about
more than they annoy telephone spammers, who have lists of thousands of
other people to spam if you're not interested.  On the other ham,
if PacBell offered distinctive ringing like most Bell companies do,
I'd use it - not for splitting types of callers, but for my fax machine...

>> Note: In Adams proposal for hashcash only charges the user CPU cycles. The
>> incentive for wide implementation of hashcash is going to be a real ecash
>> based system where the implementors can make $$$ off it.

It would be interesting to find useful problems that could be used 
instead of hash collisions.  Factoring numbers can be distributed well,
and it's possible to tell quickly that X is a factor of Y, but unfortunately
it's not possible to tell quickly that the user unsuccessfully checked some
range of potential factors rather than just pretending to have done so.
Similarly, if the user finds the key K | C=DES(M,K), you can tell quickly,
but you can't tell if the user checked a range K1..Kn except by
checking it yourself (slowly.)  But maybe there's some useful variant that
can be checked quickly.

>> Well IMNSHO hashcash mail sucks!! It opens up the pandora's box of usage
>> based charges for everything done on the 'net. What will be next? FTP
>> sites charging hashcash for DL's? WebPages charging hashcash per hit? DNS
>> servers charging per lookup? Routers charging per packet?

Digicash, maybe, though not hashcash, since hashcash is just a timewaster
that's easy to verify and only takes a long time for high-volume users.
As far as routers charging per packet goes, we've had X.25 networks which
charge by the kilopacket for a long time; it's much clumsier and more
expensive
to operate than a flat-rate network.  One of the reasons the Internet has 
overtaken X.25 so dramatically is that flat-rate pricing encourages people to
use and provide free services, increasing the base of customers and the
size of the flat-rate service they buy -- the ISPs also win.

And many web pages _do_ charge for reading them - usually the charge is
the time it takes to download and (read or) discard an advertising banner;
users are generally much more willing to pay that cost than cash,
though there are some services that give you abstracts of articles for free
and charge you money for the full version (either charging per item or 
charging per month for "premium" service.)

DNS charges are paid for by the domain name holder who wants to be found.
TLDs and SLDs are funded by the domain name registration fees in some places,
and unfortunately by Your Tax Dollars in other places, or by DNS fees
laundered by the government through their subcontractors.
Lower-level domain name service is paid for by the SLD holder or agents.
If you don't want to pay to publish your DNS name on the servers,
you can always call yourself http://192.257.23.42/ or whatever,
as many spam sellers do.


				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

William Geiger <whgiii@invweb.net> writes:
> Well IMNSHO hashcahs mail sucks!! It opens up the pandora's box of usage
> based charges for everything done on the 'net. What will be next? FTP
> sites charging hashcash for DL's? WebPages charging hashcash per hit? DNS
> servers charging per lookup? Routers charging per packet?

We already pay usage charges indirectly.

That is to say, in the UK you pay per second phone line charges.  It
would actually save me money if the net was a bit more responsive.  If
I was paying packet delivery at guaranteed performance, I would spend
less money on the phone charges.

Flat rate charges is nice enough, and the way I would like things to
stay, however I tend to think that usage charges would not be as bad
as you expect, because it would put competitive pressure on ISPs to
provide performance.

(My current ISP has truly pitiful performance.)

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

In <199712221801.SAA00366@server.eternity.org>, on 12/22/97 
   at 01:01 PM, Adam Back <aba@dcs.ex.ac.uk> said:

>William Geiger <whgiii@invweb.net> writes:
>> Well IMNSHO hashcahs mail sucks!! It opens up the pandora's box of usage
>> based charges for everything done on the 'net. What will be next? FTP
>> sites charging hashcash for DL's? WebPages charging hashcash per hit? DNS
>> servers charging per lookup? Routers charging per packet?

>We already pay usage charges indirectly.

>That is to say, in the UK you pay per second phone line charges.  It
>would actually save me money if the net was a bit more responsive.  If I
>was paying packet delivery at guaranteed performance, I would spend less
>money on the phone charges.

Well this is a UK telco problem not an Internet problem. I most certianly
do not wish to see my rates increase in an effort lower yours.

>Flat rate charges is nice enough, and the way I would like things to
>stay, however I tend to think that usage charges would not be as bad as
>you expect, because it would put competitive pressure on ISPs to provide
>performance.

I highly doubt it. Currently the going rate in the US is $15-$20/mo
unmetered rate for a standard dial-up ppp account. This includes 1 or 2
mail boxes, 5-10Mb quota space, WebServer, NewsServer, POP3 & SMTP
servers. This is fairly standard offering but will vary slightly from one
ISP to another. This is what the market will bare due to fierce
competition in the ISP bussiness. I doubt that switching to a metered rate
system will lower prices any and more than likely will *increase* prices.

There have been ISP's in the past who have offered metered rate services,
they are no longer in business. People have voted with their walets and
have overwhelmingly stated that they do not want metered rate services
(this is why you hear some on the list talking about "educating" the
users).

>(My current ISP has truly pitiful performance.)

Get a different ISP. I have switched my webpages and mail accounts to a
shell account so I can switch ISP's at will without any problems.


- -- 
- ---------------------------------------------------------------
William H. Geiger III  http://users.invweb.net/~whgiii
Geiger Consulting    Cooking With Warp 4.0

Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html                        
- ---------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000

iQCVAwUBNJ9FiI9Co1n+aLhhAQI3YgP/V886btQ7hRVL1ouJc7kq92ESmveQshEo
TEMzFq1lFABiuOd5cfdup92irtKWkIzZFZ+gK0Og9PR7XFVcqd1a4YgB3RKpXCcV
30185A6YtsHnvmK4FgulGNE9kKcTlqjVMLCbQduV+hTxrJy8AWO3fLdvUj70nfdp
y0iv1ve+w3A=
=lGTl
-----END PGP SIGNATURE-----

At 4:21 pm -0500 on 12/18/97, William H. Geiger III wrote:


> Well IMNSHO hashcahs mail sucks!! It opens up the pandora's box of usage
> based charges for everything done on the 'net. What will be next? FTP
> sites charging hashcash for DL's? WebPages charging hashcash per hit? DNS
> servers charging per lookup? Routers charging per packet?

Yup, and you'll like it too. Especially if it efficiently prices
net.resources so well that the cost of "administering" and "controlling"
them disappears, well past the last basis point compared to our current
network resource "allocation" scheme, with time-based fixed pricing,
"peering" agreements, etc. ...

For details of the foundations of this, cf Kevin Kelly's "Out of Control",
or any e$ rant I've written in the past few years. Remember my joke about a
router which saves enough out of operations to buy a copy of itself?
Micromoney mitochondria, picomoney processor food, and so forth... Look,
Ma, no (human) hands...


> Note: In Adams proposal for hashcash only charges the user CPU cycles. The
> incentive for wide implementation of hashcash is going to be a real ecash
> based system where the implementors can make $$$ off it.

Yup. Money's fungible, and all that. In collision algorithms like hashcash
and MicroMint, you're effectively using computation time as copy protection
on unique digital objects, but *only* for that, like you're only using the
cost of intaglio printing to create unique paper bearer certificates,
dollar bills being a good example. You still have to add *value* to those
unique objects, and for that you need a market to set a price. (Sorry, Adam)

The parallels are even greater for things like hashcash, or at least
MicroMint. Like real coins in meatspace, the first collision-coin's
expensive to "mint", but the rest are vanishingly cheap. However, you *do*
want to make them to be worth something besides cycle time. That's because
the cost of anything is the foregone alternative, and all that. If you
don't attach fair value to unique useful items, someone else will and start
arbitraging them anyway. Ticket scalpers are a classic case of this. Might
as well get into the business explicitly instead of creating it for someone
else, I figure.

Anyway, all this fun with money requires, horrors, an actual financial
intermediary. Yet another private currency, in other words. Probably whole
bunches of them, I bet, all competing to fill each available market niche.
CryptoAnarchy, MarketEarth, Geodesic Economy, whatever...

> I have *PAID IN FULL* for my Inet usage!! What bits I send over the Inet,
> how many bits I send, and who I send them to is NO ONE's BUSINESS but my
> own!!! -- Last Anarchist of the Inet.

Sounds more like an industrio-socialist, to me. :-). Naw... Just pulling
your leg. Put your Glock away...

Seriously, I can't imagine fixed prices for *anything* once we have
instantaneously settled cash auction markets for anything you can send down
a wire. Fixed pricing is an artifact of long production runs,
hierarchically organized "economies of scale", and all that. Moore's "Law"
creates diseconomies of scale, particularly for information goods and
services on a public network. Nodes become cheaper compared to lines, which
gives you geodesic networks instead of hierarchical ones, all that stuff.
The, um, net, result is auction pricing and cash settlement. Not will you
pay in full, Mr. Geiger, but you'll pay cheaper, too. :-). Lots cheaper, I
bet...

If you could have cash-on-the-routerhead packet switching, it would behoove
each router to have as many connections as possible to sell it's services
down. You get a *more* geodesic network. That means lots of smaller routers
instead of Forbin-sized ones that we're trying to build now. Frankly,
super-routers are lost cause. No switch can monopolize the traffic, or
it'll choke and the network will route around it. That's the nice thing
about Moore's "Law" on the net.

Cheers,
Bob Hettinga

-----------------
Robert Hettinga (rah@shipwright.com), Philodox
e$, 44 Farquhar Street, Boston, MA 02131 USA
"... however it may deserve respect for its usefulness and antiquity,
[predicting the end of the world] has not been found agreeable to
experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'
The e$ Home Page: http://www.shipwright.com/
Ask me about FC98 in Anguilla!: <http://www.fc98.ai/>

...
> As a technological fix for spam, destination address hashcash seems to be
> lacking.  All this does is raise the wall of entry into becoming a
> spamhause from one PC to say, ten.  It is not much more difficult to sell a
> CD-ROM with one million email addresses & hashcash.   A 20 second hashcash
> expenditure on one million email addresses will take about 231 CPU days, or
> about three weeks if you use ten machines.  Sell 500 copies of the CD-ROM
						   ^^^^^^^^^^ 
Hashcash has a double-spending database to prevent this -- one use and you've
got to wait until it's out of the database (quite possibly a long time) before
you can reuse it.

...
> The implementation of the plan is a more or less impossible scheme. 

Nyet. It can be phased in over time...people install the software, mailing
lists warn their users to exempt them, and the big servers start asking for the
hashcash, little servers pick it up. 

...
> privacy problems with warehousing with your ISP a list of your other email
> addresses, or the addresses of your postage free friends.  

This's already been addressed.

> Changes to the "Don't charge postage" database will be awkward.  

Well, it wouldn't be much trickier than a Pine address book (few things are :) 
or a killfile.

---------------------------------------------------------------------------
Randall Farmer
    rfarmer@hiwaay.net
    http://hiwaay.net/~rfarmer

On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote:

>.....
>> The implementation of the plan is a more or less impossible scheme. 
>
>Nyet. It can be phased in over time...people install the software, mailing
>lists warn their users to exempt them, and the big servers start asking for the
>hashcash, little servers pick it up. 
>
>.....

Yes, but if you just phase it in over time, what benefit, if any, will
users see until hashcash is fully deployed.  Until that time, people will
still have to accept email without hashcash or risk losing important
messages.  

We need to find some way for users to benefit from hashcash now, not 2
years from now when 90% of sites are using it.  The only thing I can think
of is having servers place "Hashcash-verified" headers on incoming mail so
that users can do positive filtering ("this is valid email") rather than
negative filtering ("this is spam").

I don't see people adopting hashcash unless there is some intermediate
benefit to doing so.

-- Phelix

At 3:26 PM -0700 12/17/97, Steve Schear wrote:
>>On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote:
>>Yes, but if you just phase it in over time, what benefit, if any, will
>>users see until hashcash is fully deployed.  Until that time, people will
>>still have to accept email without hashcash or risk losing important
>>messages.
>
>If I want to send an important message to you and I get a hashcash
>rejection reponse and I'm given a Web site where I can get a Java applet
>to create the hashcash, I'll do it.  We all know we must affix postage to
>our snailmail. Its time to embrace the postal system's paradigm and
>educate the reminder of the Net.  Those

This "We all know we must affix postage to our snailmail. " is misleading,
as there is no "must affix postage" ontologically wired into mail delivery.
Or package delivery. Indeed, package deliverers charge what the market will
bear, and prices move around as competitors jockey for market share.

If a private network decides to charge for packet delivery, then the price
will be what the price is, determined by a variety of factors. Ditto for
remailers.

The solution is not at the "international standards" level.

>All we need is a small, influential, group to sing the praises of
>hashcash.  I'm sure Declan and Wired will pick up the banner if what we
>come up with works.  After that IETF activity is a far gone conclusion.

"Far gone" is probably correct. Foregone is not.

I doubt that puff pieces in "Wired" will do much. And all those cover
stories showing Jaron Lanier and his dreadlocks jacking into virtual
reality did exactly what for VR, besides selling some magazines?

--Tim May

The Feds have shown their hand: they want a ban on domestic cryptography
---------:---------:---------:---------:---------:---------:---------:----
Timothy C. May              | Crypto Anarchy: encryption, digital money,
ComSec 3DES:   408-728-0152 | anonymous networks, digital pseudonyms, zero
W.A.S.T.E.: Corralitos, CA  | knowledge, reputations, information markets,
Higher Power: 2^2,976,221   | black markets, collapse of governments.
"National borders aren't even speed bumps on the information superhighway."

Phelix <phelix@vallnet.com> writes:
> On 17 Dec 1997 02:21:48 -0600, in local.cypherpunks you wrote:
> 
> >.....
> >> The implementation of the plan is a more or less impossible scheme. 
> >
> >Nyet. It can be phased in over time...people install the software, mailing
> >lists warn their users to exempt them, and the big servers start asking for the
> >hashcash, little servers pick it up. 
> >
> >.....
> 
> Yes, but if you just phase it in over time, what benefit, if any, will
> users see until hashcash is fully deployed.  

No spam in their mail boxes :-)

> Until that time, people will still have to accept email without
> hashcash or risk losing important messages.

You could work around this somewhat by configuring the hashcash filter
to put nonces (a random number) in the bounce messages for messages
which arrived without hashcash.

The instructions could read:

	Email to this address requires hashcash postage.  To generate
	your hashcash postage get software from here: <URL>

	Alternatively simply reply to this message putting this number
	in the subject field: 12347651324

The danger is that the spammer could abuse this by automating the
reply to these bounce messages.  However spammers typically don't like
to include a valid reply address, so this at least makes spammers
include an address where they can be replied to.

> We need to find some way for users to benefit from hashcash now, not 2
> years from now when 90% of sites are using it.  The only thing I can think
> of is having servers place "Hashcash-verified" headers on incoming mail so
> that users can do positive filtering ("this is valid email") rather than
> negative filtering ("this is spam").
> 
> I don't see people adopting hashcash unless there is some intermediate
> benefit to doing so.

An easily observable tag in the subject field such as: [SPAM?] meaning
no hashcash or [NEW] meaning you had never received messages from this
address before could be useful perhaps.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

At 06:53 PM 12/13/97 -0600, Uhh...this is Joe [Randall Farmer] wrote:
>This is exactly what I was addressing: remailers only have to get themselves
>certified as remailers and then prove their certification to the destination
>server, not do the whole hashcash shtick for every message. (For example,
they
>could publish their public key's hash signed by some anti-spam organization,
>then sign the hash of the server's challenge to prove that they are a real
>remailer, not an advanced spammer imitating one) 

I find this concept to have problems.  I don't know how many there are, but
with 4,000+ US ISPs, all of the schools, corporations, etc, there must be
at least 50,000 mailhosts that would have to accept authentication.  This
whitelist concept, that if I am "good" I get approved and certified smacks
of things which I generally oppose.  And who keeps the whitelist?  CAUCE?
Verisign?  Time Magazine?  The NSA? Microsoft?

How much would it cost for each of the 50K mail hosts to become certified?
This is an administrative nightmare.  The current alternative to this
certification list is the configuration files such as domains.banned,
user.banned, etc.

Currently remailers can send mail most anywhere.  I suspect that if
remailers had to get certified (say a RASCi rating of "remailer") most mail
hosts would begin denying mail from remailers.  I don't believe that mail
servers need to be certified.



  -- Robert Costner                  Phone: (770) 512-8746
     Electronic Frontiers Georgia    mailto:pooh@efga.org  
     http://www.efga.org/            run PGP 5.0 for my public key

...
> I find this concept to have problems. 

Yah, so do I...I don't like things that allow abuse of discretion, but I
thought it was necessary -- I didn't know hashcash could be prepackaged when I
posted this. 

It's a moot point since it's not needed anyway, but if morbid curiosity
overwhelms you, read on...To summarize, no single organization would certify
remailers, not all hosts would need to be certified, and banning remailers
wouldn't be any harder than it is today. 

===============================================================================

...
> This whitelist concept, that if I am "good" I get approved and certified
> smacks of things which I generally oppose.  And who keeps the whitelist? 
> CAUCE?  Verisign?  Time Magazine?  The NSA?  Microsoft? 

Well, the intention was for no single organization to certify remailers, but
rather to distribute the responsibility among anyone who can be trusted not to
certify a spammer. Individual gateways could choose whose certifications they
trusted if they thought some authorities were too restrictive or thought spam
was seeping through. Yes, I'd imagine CAUCE and Verisign (along with Infonex,
nym.alias.net, etc.) would try to set themselves up as authorities. NSA
wouldn't because they don't like remailers at all (except for those
identity-escrowed FORTEZZA-powered Big-Brother-friendly ones, which wouldn't
get users anyhow :). 

> 
> How much would it cost for each of the 50K mail hosts to become certified?
> This is an administrative nightmare.

Not all hosts, just high-traffic ones for which other solutions (having users
exempt them from hashcash [for mailing lists] and having heavy users generate
their own hashcash [for ISPs]) won't work. This basically means remailers.

...
> 
> Currently remailers can send mail most anywhere.  I suspect that if remailers
> had to get certified (say a RASCi rating of "remailer") 

The certification scheme wasn't designed for rating but rather to let cracker
get by on less than 44 CPU-hours a day. 

> most mail hosts would begin denying mail from remailers. 

They could already. Get Raph Levien's list and block mail from those addresses; 
unlisted remailers would be found soon enough. If you also used the
certification for some arbitrary non-remailer, non-spam servers, it would
probably be harder to use certification to ban remailers than to use the
remailer list.

---------------------------------------------------------------------------
Randall Farmer
    rfarmer@hiwaay.net
    http://hiwaay.net/~rfarmer

Robert Costner <pooh@efga.org> writes:
> Does the same hashcash that allows a message to enter the remailer network
> also retain it's validity once the message has been rewritten by the
> remailer?  Is this hashcash still valid for the destination mail server at
> netcom?  Does the initial sender provide two instances of hashcash, one to
> get into the remailer, and one to get into the destination mail system?

The latter.  The originator provides all postage for one way
remailers.

Nym reply block postage needs other mechanisms as described in a
previous post.

> Various remailers can distort a message in a variety of ways.  Dropping of
> MIME attachments, munging of email addresses when CC'ed to a newsgroup,
> adding a PGP signature or timestamp, adding headers that explain it's a
> remailer, adding footers that explain it's a remailer.  Since the actual
> message can change, it seems that for hashcash to be message dependent, it
> would have to be generated by the exit remailer.

Making the hashcash message dependent is interesting in that it
removes the need for a double spending database, because apart from a
DoS attack it is not interesting to the spammer to send you multiple
copies of the same mail, and in previous discussions someone suggested
it for this reason.

However, generally I have been assuming that it's easier to have a
double spend database, and to make the hashcash depend only on the
resource name for the kinds of problems you raise, and because it is
cheaper to verify hashcash on shorter strings.  By resource name I
mean whatever it is that is being used.  For an email address it is
the email address, for a remailer it is the remailers address.  Could
be generalised for other purposes, for example free use of web based
resources or even telnet based TCP/IP protocols in general.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

> >> So, we would need about 44 hours of CPU time each day.
> >
> >Well, have a system of certified remailers trusted to force their users to
> burn
> >up time at the sending end, so the ultimate recipient accepts their messages
> >w/o postage. One certified remailer accepts messages from others without any
> >postage, so only the original sender has to use up CPU time. 
...
> Since we need hashcash now to LEAVE a remailer, not to enter one, where does
> this hashcash come from?  A busy remailer could not generate it's own
> hashcash for the destination non-remailer ISPs. 

This is exactly what I was addressing: remailers only have to get themselves
certified as remailers and then prove their certification to the destination
server, not do the whole hashcash shtick for every message. (For example, they
could publish their public key's hash signed by some anti-spam organization,
then sign the hash of the server's challenge to prove that they are a real
remailer, not an advanced spammer imitating one) 

> 
> Does the same hashcash that allows a message to enter the remailer network
> also retain it's validity once the message has been rewritten by the
> remailer?  Is this hashcash still valid for the destination mail server at
> netcom?  Does the initial sender provide two instances of hashcash, one to
> get into the remailer, and one to get into the destination mail system? 

Nope. The original sender provides hashcash to get into the remailer net, and
the receiver, after seeing the remailer's certificate, trusts that the original
sender spent some CPU time to send the message. The remailer doesn't have to
while away nearly as much of *its* CPU time, and spammers still couldn't send
many messages since they still have to waste their CPU cycles to do so. 

...
> 
>   -- Robert Costner                  Phone: (770) 512-8746
>      Electronic Frontiers Georgia    mailto:pooh@efga.org  
>      http://www.efga.org/            run PGP 5.0 for my public key

---------------------------------------------------------------------------
Randall Farmer
    rfarmer@hiwaay.net
    http://hiwaay.net/~rfarmer

At 4:59 PM -0800 12/12/97, Adam Back wrote:
>I am looking at writing some hashcash
> ... Neatly worked out scheme deleted ...

I think there needs to be a story for mailing lists.  It might be
acceptable for the first pass to allow spamming of mailing lists but not of
individuals email addresses.  (Apologies in advance to list moderators.)


-------------------------------------------------------------------------
Bill Frantz       | One party wants to control | Periwinkle -- Consulting
(408)356-8506     | what you do in the bedroom,| 16345 Englewood Ave.
frantz@netcom.com | the other in the boardroom.| Los Gatos, CA 95032, USA

Bill Frantz <frantz@netcom.com> writes:
> 
> At 4:59 PM -0800 12/12/97, Adam Back wrote:
> >I am looking at writing some hashcash
> > ... Neatly worked out scheme deleted ...
> 
> I think there needs to be a story for mailing lists.  It might be
> acceptable for the first pass to allow spamming of mailing lists but not of
> individuals email addresses.  (Apologies in advance to list moderators.)

Yes, I think this is a reasonable first pass.

Naturally as you suggest the foiled spammer will then target mailing
lists and newsgroups.

I tend to view this as less of a problem because these forums are
already noisy and tend to require filtering, or manual filtering by
skimming for posters you recognize anyway.

Also I understand collaborative ratings schemes like NoCeM can be
configured to work for mailing lists.  For people who don't want to
install new software (and that is most people in my experience, myself
included) can use filtering services.

For example if spam became a problem on cypherpunks it would be easy
for someone to set up yet another filtered cypherpunks list which
promised to filter purely on the commercial spam criteria.

The reputation of the available filtering services, and the paranoia
of various list members would ensure that any untoward filtering would
be called into question.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

On 12 Dec 1997 22:44:29 -0600, Adam Back <aba@dcs.ex.ac.uk> wrote:

>
>
>I am looking at writing some hashcash
>(http://www.dcs.ex.ac.uk/~aba/hashcash/) based spam prevention
>software.  The motivation for writing spam prevention software is that
>spam is better combatted with technical methods than legal or
>political (we do not want clueless politicians coming in ham-fisted
>and requiring "Internet Drivers Licenses" or anti-spam legislation or
>anything else, such actions will be hazardous for the future of
>remailers, in my opinion).

I fear such draconian measures are inevitable as long as the "lobbying"
group CAUCE is around.  They actively discourage the adoption of technical
solutions; favoring legislation.  And since CAUCE was formed by "Net
people", it will be seen (and spun in the press) as though we actually
welcome such legislation.

[... explaination of hashcash spam prevention deleted...]

>The Right Way to do it perhaps is as an SMTP extension, however I
>consider this impractical in the short term because as far as I know
>there is no SMTP extension plug-in mechanism (other than access to the
>source code, and lots of development time) and because there are a
>large number of mail servers in use, and it will be expensive in
>developer (that's me) time to provide patches for them all
>(exarcebated by the fact that in many cases source will not be
>available).

How does PGP do it with their policy enforcer?

>So these problems leave us scratching around for other more generic
>approaches.  One method is to create a proxy which receives mail on
>port 25 (as the SMTP server normally does) filters examining for
>correct hashcash postage, and bounces if the postage is missing, and
>forwards the mail on to the real SMTP server if the hashcash postage
>is valid.  The real SMTP server would then be set to run on another
>port... say port 26 which is reserved, and have the mail forwarded to
>it at that port.  (You would want to disable non-local access to port
>26 either at firewall or with SMTP server configuration if that is
>possible).
>
>Alternatively run the real SMTP server on another machine inside the
>local network.
>
>A few problems with this approach, firstly it may not be possible to
>configure some SMTP server software to run at ports other than 25.  (I
>know you can do it with sendmail: OOPort=26 does it.)  (If this is not
>possible with a given SMTP server you can still run a proxy by running
>the real SMTP server on another machine inside the network).
>
>Secondly the proxy approach prevents some of the SMTP server functions
>from operating properly because the process on the other end of the
>socket is our hashcash proxy on localhost rather than the remote mail
>hub (modern sendmails can be configured to perform reverse name
>lookups on IP addresses, call ident (ident sucks anyway IMO), or block
>based on IP address or domain, etc.)  Is this kind of thing likely to
>be a big problem?

I don't see why.  Just have the proxy work both ways.  Isn't it possible
for the proxy to keep track of which message came from which address and
relay server requests back to the right user?  (I'm not familiary with how
sendmail works, so I'm probably missing something)

>
>This still leaves open the question of the user generating their own
>hashcash postage.  Again this could be problematic for neophytes.  One
>solution is to include a URL for a web page including a javascript
>hashcash generator -- this means that no new software must be
>installed, the user cut and pastes the generated hashcash into their
>message.

How many of the popular email pacakges have support for plug-ins?
Netscape Communicator is the only package (that neophytes will use) I know
of that doesn't support email plugins.  Perhaps in this case a small proxy
could be installed on the user's machine.  The only thing it would have to
do is generate hashcash for outgoing messages.  

>However things would be a whole lot simpler short term if the mail
>originators ISP created the hashcash for him at the ISPs SMTP hub
>where the user hands off his mail for further delivery.
>
>The main problem with this is that the SMTP mail hub would be
>overloaded by the CPU intensive task of generating hashcash.
>
>There are a few techniques to reduce the overhead of preventing spam
>with hashcash.  One is to require valid hashcash only on the first
>message to a given address.  (Spammers being hit and run types, and
>even having to generate hashcash for each spamee once would be
>expensive for a spam list of 10 million unwilling spam recipients).
>Better, is to require valid hashcash on all mail, _until_ the
>recipient replies to a mail.  This is good because people rarely reply
>to spammers.
>
>Ordinary users who chit-chat backwards and forwards in mail generate
>little added overhead for the hand off SMTP server -- the only
>overhead being to generate say 5 seconds CPU worth of hashcash for
>each new recipient the user sends to.
>
>Then you add some hashcash accounting so that users who overspend
>(consuming more than say 1 minutes CPU consumption on the server in a
>24 hour period have their email bounced with explanation of how to
>generate their own hashcash as a heavy user).
>
>Figures would need tuning to see how they worked out in practice,
>however it seems that it would be feasible to handle the whole
>operation entirely at the sending and receiving SMTP servers.
>

What's the difference between this and simply keeping track of how many
messages each user sends in a 24 hour period and blocking people who are
obviously spamming?

-- Phelix

Phelix <phelix@vallnet.com> writes:
> 
> >The Right Way to do it perhaps is as an SMTP extension, however I
> >consider this impractical in the short term because as far as I know
> >there is no SMTP extension plug-in mechanism [...]
> 
> How does PGP do it with their policy enforcer?

Their controversial GAK ready policy enforcer works as a a local SMTP
proxy.  You set up your normal SMTP server on another machine, and
configure the policy enforcer to forward mails to the normal SMTP
server.  Or presumably if you can configure your SMTP server to accept
connections on a port other than 25 you could have the SMTP enforcer
on the same machine.

The same thing could work for a hashcash filter, and it is one
feasible solution.

> >Secondly the proxy approach prevents some of the SMTP server functions
> >from operating properly because the process on the other end of the
> >socket is our hashcash proxy on localhost rather than the remote mail
> >hub (modern sendmails can be configured to perform reverse name
> >lookups on IP addresses, call ident (ident sucks anyway IMO), or block
> >based on IP address or domain, etc.)  Is this kind of thing likely to
> >be a big problem?
> 
> I don't see why.  Just have the proxy work both ways.  Isn't it possible
> for the proxy to keep track of which message came from which address and
> relay server requests back to the right user?  (I'm not familiary with how
> sendmail works, so I'm probably missing something)

The functionality which is lost is the possibility for the sendmail to
be configured to do a reverse DNS lookup on the IP address which is
connecting to it, and check that that domain is the same as the domain
in the From field.  Also ident lookups don't work anymore either.
However I am not sure how reliable either of these mechanisms are, and
I'm not sure that many people are using them because they would be
unlikely to be reliable in the general case.

So probably this is not a problem.

> >This still leaves open the question of the user generating their own
> >hashcash postage.  Again this could be problematic for neophytes.  One
> >solution is to include a URL for a web page including a javascript
> >hashcash generator -- this means that no new software must be
> >installed, the user cut and pastes the generated hashcash into their
> >message.
> 
> How many of the popular email pacakges have support for plug-ins?
> Netscape Communicator is the only package (that neophytes will use) I know
> of that doesn't support email plugins.  Perhaps in this case a small proxy
> could be installed on the user's machine.  The only thing it would have to
> do is generate hashcash for outgoing messages.  

A local SMTP proxy to add hashcash on the way out should work fine.

> >require valid hashcash on all mail, _until_ the
> >recipient replies to a mail.  This is good because people rarely reply
> >to spammers.
> >
> >Then you add some hashcash accounting so that users who overspend
> >(consuming more than say 1 minutes CPU consumption on the server in a
> >24 hour period have their email bounced with explanation of how to
> >generate their own hashcash as a heavy user).
> 
> What's the difference between this and simply keeping track of how many
> messages each user sends in a 24 hour period and blocking people who are
> obviously spamming?

The difference is that it allows the ISP which is hit by spam attacks
to install a hashcash filter.

With simple resource metering at the spammers ISP side, the spammers
typically abuse other peoples open SMTP agents to forward their spams
for them.

Their ISPs can do little about this.

Really it's best if the sender is left to generate his own hashcash,
the motivation for working out ways to have the originators ISP's
outgoing SMTP hub generate hashcash for them is that it is simpler to
install in the short term.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

-----BEGIN PGP SIGNED MESSAGE-----

The Net teaches even old dogs new tricks.  From the Laissez Faire Books 
catalog:

http://www.lfb.org/investment.html#iv7644

*****************

James Davidson and William Ress-Mogg 

THE SOVEREIGN INDIVIDUAL
How to Survive and Thrive During the Collapse of the Welfare State
by James Dale Davidson and Lord William Rees-Mogg 

In their newest work, the authors of Blood in the Streets and The Great 
Reckoning predict increased autonomy for the individual as information 
technologies advance and old institutions crumble-including the welfare state 
itself. Along with an array of provocative predictions (government will 
declare war on groups that try to circumvent income tax through cyberspace; 
central banks will lose control over the money supply as cybercash supplants 
paper money; the U.S. government will shrink) Rees-Mogg and Davidson offer 
investment advice and strategies for coping.

*****************
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQCVAwUBNJKcjIVO4r4sgSPhAQHLQwQAlBdYuWWoA/Q3Y6xkM1vT3iMm0HMCAuBS
HYCu5NaRUfslMdbjvgqHAnc8SV+AX7fXVSfgCZ6nVtchnubgKaO22RcMlKWu423i
dQrBvP0ZBK+fbWaFjZVvVVS4uZcHrUniUNj/u57Px9OmzK09zXXfJqdBuvwfm8ta
X8br0rsIz48=
=0opA
-----END PGP SIGNATURE-----

> What's the difference between this and simply keeping track of how many
> messages each user sends in a 24 hour period and blocking people who are
> obviously spamming?

Spammers don't have to appear to be the same person every time, nor do their
messages have to be identical or even similar, so blocking of that kind can be
worked around fairly easily -- at least more easily than hashcash. 

> 
> -- Phelix

---------------------------------------------------------------------------
Randall Farmer
    rfarmer@hiwaay.net
    http://hiwaay.net/~rfarmer

Randall Farmer masquerading as Joe <rfarmer@HiWAAY.net> writes:
> > What's the difference between this and simply keeping track of how many
> > messages each user sends in a 24 hour period and blocking people who are
> > obviously spamming?
> 
> Spammers don't have to appear to be the same person every time, nor
> do their messages have to be identical or even similar, so blocking
> of that kind can be worked around fairly easily -- at least more
> easily than hashcash.

I think Phelix was probably viewing it from the point of view if "what
if all ISPs turned off non subscriber mail forwarding at their SMTP
hubs"?

Well that would work clearly enough.  However I think there are a
number of technical problems to acheiving this.  Firstly SMTP does not
include authentication.

Secondly doing so reduces flexibility and many users use multiple
ISPs, forward their mail to various places, etc., and this kind of
stuff gets in the way.

Really we I think should be discouraging the control freak "positive
identification to use this port" syndrome such as the ident fuck up,
(Ident is a dumb method of identifying who is on the other end of a
socket on a unix box.  It opens up a socket to the ident port on the
originating machine, and asks who is on socket x port y?  The machine
can determine this from local OS tables, and sends the info back.
This works if the user does not have root on the machine.  Fortunately
this snoopy bastardised protocol is not doing so well these days
because there are more and more people who have root on their own
machines, and because there are so many windows machines which don't
know what a protected port number is.  This is good because Ident
sucks.) and moving instead towards, "who cares you are so long as you
can't overload my machine".  Moving longer term towards "who cares who
you are so long as I profit from your connecting to this port" aka
charge for port access with payer and payee anonymous ecash.  Then
everyone is welcome to use anywhere as a mail forwarding service --
spam becomes welcomed, and encouraged, too much custom and too low
bandwidth discouraging customers, the ISP will use the profits to
purchase a few more T3s.

Hashcash is the interim solution.

In the interim it is a fact of life that there are many many open SMTP
forwarding hubs.  The lack of software to configure them otherwise,
and inertia will ensure things remaing this way for some time.

Hashcash cuts out spam to your site (if you are an ISP), or to your
mailbox (if you are a user) even in an environment of an almost
unlimited supply of open SMTP hubs, and disposable ISP accounts,
because it puts the onus on the sender to consume more resources than
you.

Authenticated the hell out of your ISP's SMTP as a forwarding hub
won't prevent your users getting spammed to death, nor will it reduce
the overall spam problem much because the spammers will just use one
of the other open SMTP servers.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

[I see I overlooked a major feature of hashcash in my idea for exempting
remailers from it...sp'cifically, I didn't know you could prepackage hashcash. 
Needless to say, I don't send my good posts from this address :) ]

> Randall Farmer masquerading as Joe <rfarmer@HiWAAY.net> writes:

Yep, state-of-the-art MITM techniques in action. :)

...

> I think Phelix was probably viewing it from the point of view [o]f "what if
> all ISPs turned off non subscriber mail forwarding at their SMTP hubs"?

Nonetheless, it'd still hold that hashcash would be harder to get around than
simple filtering...also, like you said, it's in the interest of the ISPs to use
hashcash, whereas stopping outgoing spam doesn't do much for them.

...  
> (Ident is a dumb method of identifying who is on the other end of a socket on
> a unix box.  It opens up a socket to the ident port on the originating
> machine, and asks who is on socket x port y?  The machine can determine this
> from local OS tables, and sends the info back.  This works if the user does
> not have root on the machine.  Fortunately this snoopy bastardised protocol
> is not doing so well these days because there are more and more people who
> have root on their own machines, and because there are so many windows
> machines which don't know what a protected port number is. This is good
> because Ident sucks.)
          ^^^^^^^^^^^ 

Good description, but you only needed those last two words. Ident really is a
pain, especially for those of us who can't avoid it (It makes the case for
crypto that much stronger, though :). 

---------------------------------------------------------------------------
Randall Farmer
    rfarmer@hiwaay.net
    http://hiwaay.net/~rfarmer

On Sat, 13 Dec 1997, Adam Back wrote:

[...]
> (Hashcash is a way of proving that the sender has consumed a tunable
> amount of CPU time.  The verification process consumes negligible CPU
> time.  This allows us to require the would be spammer to spend say 20
> seconds per mail, which will slow him down considerably, over his
> current tactics of 1000 long Bcc lists allowing him to hand off
> spamming tasks to mail servers.)
[...]

Sounds like a headache to me: people use wildly different machines to
handle their e-mail. Some places use 25 MHz '486 machines, others use
300 MHz Pentium-IIs, a difference of 1-2 orders of magnitude? Collision
search is also easy to parallelize over a network, so the load can be
shared using, say, 50 Pentium-II 300MHz PCs, costing less than $100,000
(we don't need lots of disk or memory, just a fast CPU). Here's at least
three orders of magnitude for you.

The '486 may be used by a school, while the 50 Pentium-II machines
are owned by Spamford W., Esq. Now we're faced with a dilemma: we either
limit the school's outgoing e-mail capacity severely, or Spamford will
keep on sending spam. For every thousand messages the school sends
Spamford can send a million. 

The risk: starting a CPU arms race.

Ge'


Ge' Weijers                                Voice: (614)326 4600
Progressive Systems, Inc.                    FAX: (614)326 4601
2000 West Henderson Rd. Suite 400
Columbus, OH 43220  	     http://www.Progressive-Systems.com

CC: me as I'm not presently reading cypherpunks (this was bcc:ed to
coderpunks).

On Sat, 13 Dec 1997, Adam Back wrote:

> The required filter functionality is something like this in order of
> desirability:
> 
> Accept the SMTP session.  Use an EHLO extension HASHCASH to say that
> this server expects hashcash.  (Extended HELO is a method of
> specifying SMTP extensions (I think)).  Accept the headers, and if a
> valid hashcash postage is not included, hand off to the real
> mailserver a site configurable bounce message.

I'm not sure this is doable. From what I've seen of the sendmail anti-spam
stuff and the SMTP protocol, you can't just accept the headers and then
decide whether not not to accept the rest; you either have to be able to
(at present) a) reject the message before you receive it based on the FROM
data (known spammers, bogus hostnames, etc); b) reject the messages before
you receive it based on the RCPT data (anti-relaying: is the recipient at
our site?); c) reject the message after you receive it. Obviously with
spam, you'd like to be able to reject it before it takes up bandwidth. So,
an extended protocol could require a CASH command from the client before
DATA will be accepted. The client could generate the cash on the fly, or
it could be grepped out of the headers. 

If you don't want to dink around with patching sendmail or whatever for an
extended protocol, then simply use a system-wide procmailrc to enforce
hashcash; procmail can generate bounces very easily (or rather, trick the
MTA into generating the bounce for it). Or, make requiring hashcash a
user-selectable option by having a publicly-available script which a user
can have included into his .procmailrc by setting some variable.

> This still leaves open the question of the user generating their own
> hashcash postage.  Again this could be problematic for neophytes.  One
> solution is to include a URL for a web page including a javascript
> hashcash generator -- this means that no new software must be
> installed, the user cut and pastes the generated hashcash into their
> message.

Two potentially simpler solutions: a) the client MTA could generate
hashcash on the fly as needed (like it generates Message-IDs); b) a filter
could be installed in place of the user's normal MTA which generates
hashcash. The latter is probably better (easier to implement). For
example, if the normal MTA is sendmail, then a fake sendmail could be
installed which is just a nasty little script which parses out the
recipients, generates a suitable hashcash token for each one, and inserts
the appropriate headers, and then passes the message off to the real
sendmail.

My preferred means of spam-blocking right now is a barrage of tests for
typical spams using procmail, combined with a reverse spam block. An
ordinary spam block is an address munge where something is added to the
address to make it undeliverable, so ordinary users have to unmunge your
address before they can mail you, i.e. andy@neptune.chem.uga.nospam.edu. A 
reverse spam block lets you use your real address for posts but requires
users to add something to your address to guarantee delivery. As my sig
indicates, if you add +spamsucks to my username, various spam filtering
features are deactivated. If I wanted to, I could bounce anything which
didn't have the +spamsucks in it. The recipe I use also uses lists of
"trusted" users (ones I don't do any spam testing on, so they don't need
the password) and "spammers" (we don't spam test these either, we just
make them bounce). Also will reject messages where I am bcc:ed (unless
from someone trusted or the password was used) or on a huge visible list
(again as before).

It works pretty darn good. I hardly get any spam. Most of what I get
bounces back to the sender with "User unknown". If the sender has a forged
From, then this at least bounces there, or to the site's postmaster, who
will likely take some action (but not complain to me because I don't
exist). If the From was completely bogus, then I get the bounce, but that
doesn't happen too often. I use this same system for the return address of
the cracker remailer (anon@anon.efga.org) and it works pretty well, though
as of late I am munging the return address for all USENET posts a la
mail2news_nospam@anon.lcs.mit.edu (which has been hugely effective); 
you're not supposed to reply anyway...

I would like to modify the nymserver so that users can set a reverse spam
blocking password, but just haven't gotten around to it. I'm pretty sure
it can be done, though.

Andy Dustman / Computational Center for Molecular Structure and Design
For a great anti-spam procmail recipe, send me mail with subject "spam".
Append "+spamsucks" to my username to ensure delivery.  KeyID=0xC72F3F1D
Encryption is too important to leave to the government. -- Bruce Schneier
http://www.athens.net/~dustman mailto:andy@neptune.chem.uga.edu   <}+++<