On Thursday 29 May 2003 01:13, Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu wrote:
Va> On Thu, 29 May 2003 06:20:47 +0200, Anthony Atkielski
Va> <anthony(_at_)atkielski(_dot_)com> said:
...
Va> > Hash it and sign it with the public key of the recipient.
Va> > That would work, because spammers would not have the
Va> > public key, whereas legitimate senders would.
Va>
Va> Only if it's an *UNPUBLISHED* public key - at which point
Va> it just degenerates into your "secret number" protocol,
Va> with the same bootstrapping issues.
Correct, but still methinks Anthony is onto something.
Yes, a spammer could get hold of your public key. However, this
"tailoring" means that he's going to have to send the spam to each
recipient individually, instead of using a huge Bcc list. This won't
get rid of spam entirely, but it could put somewhat of a damper on the
flow.
The big question is, how many recipients are there (To + Cc + Bcc), for
the average piece of outbound spam? That is roughly the ratio by which
such a scheme will make it costlier to spam. (I'm purposesly ignoring
the extra cost of the hashing and encryption. These will probably make
a small contribution, by comparison.) Anybody got a large corpus of
spam, COMPLETE WITH BCC LISTS, to analyze?
Then comes the followup question of whether that ratio is enough to be
worth the trouble of further investigation along this path. Keep in
mind, they could always simply apply the usual Microsoft solution: throw
more and faster hardware at it. Note also that a lot of spam is already
sent to single recipients per piece. In those cases, the extra costs of
hashing and encryption MIGHT make a SMALL dent, but I doubt it would be
enough to be worth the hassle.
--
David J. Aronson, Unemployed Software Engineer near Washington DC
See http://destined.to/program/ for online resume, and other info