At 10:45 PM 4/21/2002 -0400, Jim Paris wrote: >... > > so, in contrast to 28,800 possible messages in the day, an unencumbered > > spammer could deliver between 147744 and 4060800 pieces of spam. yes, > > 28,000 messages is a lot but it's one helluva lot less than 150,000. >... > >I think you'll find that most spammers are not limited by the fatness >of their pipe, but how many e-mail addresses they have and how many >mails they can send out before their ISP shuts them down. > >In other words, I don't think spammers are sending between 147744 and >4060800 pieces of spam per day -- I think they're, on average, sending >much, much fewer, less than 28,800 per day per spammer. > >Sure, the numbers can be debated (and I'm not really interested in >doing so). But you will at least agree, I hope, that your hashcash >solution will slow down spammers _only_ if they happen to be sending >more than 28,800 per day. (Or 10,000 a day depending on computer >speed, whatever). > >If, for example, we actually have 1,000,000 spammers sending 1,000 per >day, your solution won't do _anything_, unless hash cash takes more >than a minute per message to compute. And _that_ starts to become a >burden for regular users.
I half agree. the points you raise are why it's so important to get a moderately accurate understanding of the number of spammers and how much mail they send. Without hard information, one can spin strawman models all day and come up with "proof" on both sides. So, taking your strawman of a spammers sending only 1000 messages on a dial-up line, they would be done in 2.4 minutes. Assuming they have a top-of-the-line Pentium IV machine, generating coins would slow them down and stretch out the delivery time to 49.9 minutes. That might not seem like much but the numbers get better if you look at the real world distribution of machines. It makes spam less profitable because they cannot deliver as many messages as quickly as they had in the past and their profit is directly tied to the number of messages delivered. Yes, one can raise the threshold by increasing the difficulty of the problem and spending more time but that starts imposing an unacceptable burden on the low end users. There are some techniques one can use (i.e. precalculation as soon as e-mail address is known, background calculation) to get around this but it requires deeper integration with e-mail clients. >(And what about legitimate mailing lists? And autoresponders? And..) these are familiar horsemen of the idea apocalypse. Mailing lists: far future would have the list subscription process exchange keys for active identification of messages from the mailing list. Near-term uses white list acceptance. Autoresponders would need to be coined but since they do not have a human around screw up the process, this should be no problem. blind carbon copies: require message replication and attachment of the coin or signature for the blind carbon copy recipient only. daemon messages: white list but like autoresponders, I would argue for having them generate coins because of the spammer tendency to fake messages from daemons. Bounce messages: this requires actual content analysis for identification. Ugly problem. double spent coins: we use a double spending database to verify each coin has been used only once. Precalculated coins: we have put a time window for validity of the coin. This means that any service bureau that precalculated coins only has a limited window in which the coins will be valid. Too early or too late will be treated as invalid (on delivery). Yes, we've been thinking about the problem a while. ;-) but even with something like camram, there will be a need for spam filters because if a spammer decides to start using the coins then it will take the combination of a filter and coins to keep out spam from a mailbox. --- eric _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
