Re: [Asrg] HashCash

> > > AGAIN, THIS DOES NOT SOLVE THE PROBLEM.  It only makes the system 
> > > more
> > > complicated and expensive.
> > I don't buy this argument,
> Hey, suit yourself.
>
> > because the "large numbers" of mail will be
> > significantly smaller than the "massive numbers" we're seeing today.
> I don't think that's assured.
Please justify this statement.  I've taken some numbers provided by a 
poster, and indicated the difference in the quantity of resources 
available - even assuming the spammers can use a significantly larger 
fraction of their zombie pool to make stamps than send mail.  I'll even 
summarise here:
At present, spammers use fresh zombies for an average of 4 days after 
infection - this pool is about 100,000 machines at present.
The total zombie pool is about 1,500,000 machines at present, depending 
who you ask and how they collected their data.  This is about 15x the 
number of active spewers.
Assumption:  It presently takes about 4000 times as long for a typical 
zombie (1.0GHz P6 or K7 class CPU with a 128Kbit DSL uplink) to mint a 
20-bit hashcash stamp as to send out an unstamped, 5KB mail.
Given that spammers can recruit the entire horsepower of their zombie 
army, compared to only a fraction of the bandwidth, this still marks a 
reduction in overall spamming capacity of about 200 times.  And this 
assumes the zombies' CPUs aren't being used for anything else, such as 
games.
> I really don't believe that the solution to the spam problem involves 
> making
> E-mail harder or more costly to send.  I think a much better solution 
> involves
> making it (if unwanted) *far* less likely to actually be delivered... 
> such that
> the spammer realizes that the effort is probably futile.
>
> Likewise, we HAVE to work on cutting down the ease of zombie 
> recruitment, and I
> believe that my attachments (and HTML!) permissions list idea 
> (basically a
> fine-resolution whitelist) is a *major* step in the right direction 
> there.
How is your proposal incompatible with mine?  I can't see any 
particular way.
Just for reference, I turned up the score for MICROSOFT_EXECUTABLE in 
my SpamAssassin filter long ago.  Now I don't get any of the usual 
viruses, but I get the encrypted ZIP archives instead.  I'm sure 
SpamAssassin could easily be modified to handle everything you propose 
- so why don't you talk to them instead of shooting me down all the 
time?
> > Since when is that such a weak argument?
> Well, maybe always, in part since it ignores the very legitimate needs 
> of
> organizations like Yahoogroups and other major outbound mailers to 
> send millions
> and millions of pieces of mail a day.
Did I say that every piece of mail needed a 20-bit hashcash stamp?  No, 
I said that whitelisted senders get to use smaller, even 
computationally trivial stamps.  Subscribing to a mailing list should 
include making a whitelist entry at each end of the transaction.
I also said, at some point, that if a message is addressed to a mailing 
list and the stamp matches the mailing list's address, then if the 
recipient is subscribed to the mailing list he should accept the stamp 
as valid.  This caters for listserv software that doesn't (yet) 
understand stamping, signatures and whitelists.
Here's my point, since you seem to have missed it up until now:  
Hashcash and signatures work in concert!  One covers some situations, 
the other covers the rest.  Please stop taking them in isolation to 
make straw men.
> What determines whether it's spam or not is whether the RECIPIENT 
> wants it and authorized the sender to send it to them, and whether the 
> content of the mail is remotely like what the recipient(s) expect and 
> want to receive from that sender.
Content filters only work to a point.  SpamAssassin actually has 
filters set up to detect most content-disguise mechanisms already - 
stuff like an excessive number of HTML tags, FONT COLOR="white", etc.  
Spam *still* gets past it occasionally.
As for whether the recipient authorised the sender...  without any 
widely deployed authentication mechanism, how do you avoid spoofing on 
the whitelist entries?
> > I added the idea of a simple signature because it's clear that PGP and
> > S/MIME haven't taken off - so are they too complex and/or intrusive 
> > for
> > Joe User?  We need *something* to whitelist against.
> Why do you think that it's not enough to simply use the E-mail 
> characteristics
> (type of content, HTML classes used, type of attachments, size maybe) 
> in
> combination with the sender and the list of permissions granted to 
> that sender
> by the recipient?
Because we already have that general type of filtering, and it isn't 
working well enough.
> And if you DO want something more, why is a "passcode" or
> something freely made available by the recipient (perhaps in large 
> number of
> variant forms, so to make life difficult for address harvesters) and 
> included in
> (say) the Subject or a special header line perhaps, not enough?
Because that's too much effort for most users - it's "intrusive".  I 
have seen people using it, but they're distinctly in the minority.
> > Each signature, incidentally, will be valuable only for the number of 
> > recipients who have whitelisted it, which for Joe User will normally 
> > be quite a small window.
> So what happens if they HAVE NOT whitelisted it?  I think that many 
> (most if not
> all!) types of users NEED to have SOME kind of way to receive 
> legitimate,
> unanticipated E-mails...
Then they mint hashcash for it.  It only takes a few seconds of CPU 
time for most people.  If they happen not to have the CPU resources 
available to do it themselves, they have the option of paying a third 
party to do it for them.
The signature is merely a way to bypass the CPU expenditure for regular 
correspondents - friends, family, regular business contacts, mailing 
list subscriptions, etc.  Nothing more.
> Who really cares about signing keys, or certificates, or all these 
> SPF-like mods
> to DNS which don't solve the problem, or E-postage and all the new 
> opportunities
> for fraud, abuse, extra costs and hassles?  I sure don't.  All I'm 
> concerned
> about is dumping spam in the trash so I don't have to deal with it.
Then implement your filter for yourself.  It sounds like something you 
can implement and gain benefits from on an individual basis, so you 
shouldn't really have any trouble with it.  If it works for you, come 
back and tell us about your experience.  But don't just pan everyone 
else's ideas while your own is still theory.
--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     chromi(_at_)chromatix(_dot_)demon(_dot_)co(_dot_)uk
website:  http://www.chromatix.uklinux.net/
tagline:  The key to knowledge is not to rely on people to teach you it.


_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg