Re: remailer hashcash spam prevention

["Robert A. Costner" <pooh@efga.org>]

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