On Thursday 29 May 2003 01:13, Valdis.Kletnieks@vt.edu wrote: Va> On Thu, 29 May 2003 06:20:47 +0200, Anthony Atkielski Va> <anthony@atkielski.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