At 09:57 AM 5/14/2003 -0400, Sunder wrote:
Yes, but how will you stop the spammer from double spending the same $0.25 micropayment on all of his 170,000 email addresses? Depending on whether you check that there is a payment attached or not, and also check it with the bank before delivering it, you'd have already wasted your bandwith and possibly have accepted a spam into your mail spool.
It is true that the notions of micropayments as applied to spam (that I'm familiar with, at least) would require that the email recipient check with the bank to detect doublespending. This would introduce an additional delay before delivery from unknown senders, yes, but I fail to see how it would impose an unacceptable cost in bandwidth or CPU usage. Spammers could still try the same-micropayment-a-million-times route, just as they could try to spam without micropayments, but if their email is rejected in sufficient quantities, the cost to the spammer would outweigh the benefits. The key is achieving sufficient quantities. -Declan
The current cost to the spammer is currently nearly zero. To add hash generation for each email might slow things down a bit, but throwing more hardware at it gets around this. Hardware is cheap, and old out of date PC's are plentiful. The bandwidth cost is the same, the CPU cost and time is a bit higher, but not much. 170,000 email addresses is what one CD offered. Assume that spammer bob sends emails to that many from lots of servers, say it takes one or two hours. Most spams are small, some are over 20-30K (gif attachments, and other crap.) Each time this happens - (from my point of view I get about 50-60 spams/day that I filter) each of those recipients turns around and sends some traffic attempting to auth the micropayments via the micropayment bank. That's a DDoS from the point of view of the bank. Even if it can handle the traffic it has to do lots of CPU intensive work and send the error back to each of those requests, which will result in rejection of 169,999 requests and 1 acceptance (assuming the spammer is using a valid coin in the 1st place.) It becomes expensive to run the mint. The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w. Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same. Say, things get harder and he has to adapt, well, he'll just charge his clients more for the trouble and advertise it as a value add that it's garanteed that x% will be read (never mind that idiot client hasn't got a way to prove it one way or another.) You have to think about it from their point of view to find out what they could do to get around it. Then you have to think about it from the bank or mint's point of view, and the traffic and CPU operations, it will have to deal with. Does this solution make it exponentially harder for spammer to deliver the spam? Does this incur cost to the recipient? Does it incur cost to the mint? and so on. Looking at this problem from the spam recipient's point of view isn't enough.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
----------------------Kaos-Keraunos-Kybernetos--------------------------- + ^ + :25Kliters anthrax, 38K liters botulinum toxin, 500 tons of /|\ \|/ :sarin, mustard and VX gas, mobile bio-weapons labs, nukular /\|/\ <--*-->:weapons.. Reasons for war on Iraq - GWB 2003-01-28 speech. \/|\/ /|\ :Found to date: 0. Cost of war: $800,000,000,000 USD. \|/ + v + : The look on Sadam's face - priceless! --------_sunder_@_sunder_._net_------- http://www.sunder.net ------------ On Wed, 14 May 2003, Declan McCullagh wrote:
It is true that the notions of micropayments as applied to spam (that I'm familiar with, at least) would require that the email recipient check with the bank to detect doublespending. This would introduce an additional delay before delivery from unknown senders, yes, but I fail to see how it would impose an unacceptable cost in bandwidth or CPU usage.
Spammers could still try the same-micropayment-a-million-times route, just as they could try to spam without micropayments, but if their email is rejected in sufficient quantities, the cost to the spammer would outweigh the benefits. The key is achieving sufficient quantities.
On Wed, 14 May 2003, Sunder wrote:
Say, things get harder and he has to adapt, well, he'll just charge his clients more for the trouble and advertise it as a value add that it's garanteed that x% will be read (never mind that idiot client hasn't got a way to prove it one way or another.)
There are ways to prove it. You can use web bugs embedded in HTML mail, fetching an object from a tracking server. This doesn't work with some mailers, however Outlooks to version 5.5 are vulnerable for sure and numerous other ones are as well. This approach is already widely used for checking the validity of email addresses. You can count the clickthroughs from the mails, thus not measuring the impressions themselves, but the raw success. The spammer then can be paid not per mail sent, but per URL clicked to - leading to a new level of various confusing and enticing tactics. You can also share profit with the spammer using some kind of provision per sale, thus fully outsourcing your advertising. Possibly there are yet other ways. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Thu, May 15, 2003 at 03:50:43AM +0200, Thomas Shaddack wrote:
You can use web bugs embedded in HTML mail, fetching an object from a tracking server. This doesn't work with some mailers, however Outlooks to version 5.5 are vulnerable for sure and numerous other ones are as well. This approach is already widely used for checking the validity of email addresses.
Yep, and I've never understood why someone would do that. I read email using mutt/lynx and Eudora (with "Automatically download HTML graphics" turned off). Heck, sometimes I'll use /bin/mail or cat. I'd never register as having read the email. Guess I'm not the target audience; the Outlook crowd is. -Declan
Sunder wrote: [...spammer sends 170k mails all with same micropayment coin...]
Each time this happens - (from my point of view I get about 50-60 spams/day that I filter) each of those recipients turns around and sends some traffic attempting to auth the micropayments via the micropayment bank. That's a DDoS from the point of view of the bank.
Even if it can handle the traffic it has to do lots of CPU intensive work and send the error back to each of those requests, which will result in rejection of 169,999 requests and 1 acceptance (assuming the spammer is using a valid coin in the 1st place.) It becomes expensive to run the mint.
and Declan wrote: | It is true that the notions of micropayments as applied to spam | (that I'm familiar with, at least) would require that the email | recipient check with the bank to detect doublespending. This would | introduce an additional delay before delivery from unknown senders, | yes, but I fail to see how it would impose an unacceptable cost in | bandwidth or CPU usage. So I'm not sure if you'd want to do it, and it has other issues discussed on cpunks recently, but there are some other options here with ecash that can avoid the bank having to say "already spent" 169,999 times for each valid but already spent coin. (I concur with Sunder that if the bank had to fit such usage patterns into their business model, it would increase ther costs significantly which would make running the bank even harder to do and still turn a profit, especially as we are talking very high volume, and exceedingly low value tokens.) One assumption I'm making is presumably the micropayment system provides the option for payer and payee anonymity, or email privacy just got removed once and for all. (Trace the payments at the bank and you know who emailed who in a convenient central database - a definite privacy no-no). So with the offline brands protocol of which there was some discussion recently, the MTA could verify the coin locally. It would be assured that if the coin was locally verified as valid, he either gets the money later when he deposits, or the bank gets the spammers identity and prosecutes them for payment fraud. So (and this is why I said I don't know if you would want to do this...) this payment choice where identity is revealed iff you double-spend has the recently discussed issue: A) you have to provide your identity in the first place, and if having it revealed is any deterrent, you'd better be identified robustly (doing this identification for every email user on the planet seems a somewhat daunting task) B) the spammer will have an incentive to find a way to provide fake identity to the bank, or of buying someone else's identification (eg. someone with no credit rating, or of stealing someone else's tokens, or stealing someone else's mail services which automatically add a payment (identifying them) on event of double spend But aside from those issues (plus the showstopper issue of building a payment infrastructure to support this volume in the first place which was discussed earlier in this thread) this now gives the MTA the ability to reject double-spends locally -- modulo the amount of deterrent to double-spending anyway and being identified ends up providing after the spammers have finished attacking issue B). A remaining technical issue would be the MTA could have it's CPU overloaded as verifying such tokens is while relatively cheap (I think around DSA signature verification cost) still much more expensive than it is for the DoS spammer to send you plausibly formatted random numbers to burn off your CPU. But we have a separate solution to that: you make the spammer provide a hashcash token of comparable cost to that verification and this can be verified an one order of magnitude or more efficiently and increases the would-be DoSers costs to be comparable to the signature verification. (Or more if you wish -- legitimate mail users usually don't need to send 200 mails/sec). Sunder wrote:
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Well in some cases I guess the ISP lost the bandwidth (depending on where you do your checking). But anyway personally I'd be more than happy to double by bandwidth consumption to receiving email to avoid any spam arriving in my mailbox. (As an individuals bandwidth consumption sending and receiving email is typically rather low, and entirely feasible over perhaps 15 minutes of dialup per day). Or at least to the end-user the human attention costs of spam are vastly in excess of the bandwidth costs of spam. ISPs I suspect have a different perspective: while they have some human costs -- dealing with complaints and manually throttling debilitating spam floods -- the users inconvenience at having to sort spam from non-spam is not directly their problem, other than in perhaps a competitive advantage if users will switch ISPs to use one which offers better anti-spam options. Sunder also wrote:
The current cost to the spammer is currently nearly zero. To add hash generation for each email might slow things down a bit, but throwing more hardware at it gets around this. Hardware is cheap, and old out of date PC's are plentiful. The bandwidth cost is the same, the CPU cost and time is a bit higher, but not much.
I presume this comment is about hashcash or variants rather than about ecash which the rest of the post was about. Hardware is cheap, but 1 sec of CPU per sent mail on a 1Ghz machine still ends up costing by my estimates (see thread with Subject: economics of spam) about a factor of 30 more for the spammer. Note old machines are cheaper but they are also slower; the spammer would want to buy the best value for money hardware factoring in electricty costs (old slow machines don't necessarily consume less electricity, and electricity is around the same cost as the amortized cost of ownership of the machine). Adam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
On Wed, 14 May 2003, Sunder wrote:
The 1st time a significant number of users start using this scheme, the spammers will adapt to get around to it. Just like they've already adapted against keyword searches by using text such as e'n'l'ar'g'e' 'y,o,u,r, `pe`n`i`s__n_o_w.
Amusing side note: Spamassassing 2.53 didn't catch this particular g a p p y t e x t. Good job.
Again, from the spammer's point of view, they don't necessarily care that you recieved the email. They sell advertisements for a price. Say you have an ad, you go to the spammer, he spams 170,000 emails with it for $10. He doesn't give a shit if less than 1% of those will get the spam - he charges his client the same.
I don't think this is usually the case. Spammers who talk seem to indicate that they get commissions, not per message fees. In my mind, this means that lowering delivery is good, but an arms race. For some spam, driving up costs may be a short term good, but a long term evil - if the commission is based on inquiries to a mortage refinance broker, lots of phony addresses will make for an extremely unprofitable campaign which they hopefully won't try again, but that also puts money in the pocket of a spammer.
From my point of view, if my MTA has already spooled the spam, I've already lost my bandwidth, and thus lost some value. Doesn't matter that I never see the spam. Bandwidth was already wasted receiving bits that wind up in /dev/null and cpu cycles to make the decision to drop said bits.
Yes. I'm writing up a rant about spam, that I'll send to the list shortly. But I agree completely. -j -- Jamie Lawrence jal@jal.org
----- Original Message -----
From: "Declan McCullagh"
At 09:57 AM 5/14/2003 -0400, Sunder wrote: [double-spending problem, and associated unacceptable costs]
It is true that the notions of micropayments as applied to spam (that I'm familiar with, at least) would require that the email recipient check with the bank to detect doublespending. This would introduce an additional delay before delivery from unknown senders, yes, but I fail to see how it would impose an unacceptable cost in bandwidth or CPU usage.
The biggest cost I see isn't in the bandwidth or cpu, the cost I see is in the memory. First let's look at the load incurred on these systems. For a single email, the email must be held in RAM for the time necessary to verify the coin (otherwise double spending occurs, filters fail, etc). Obviously each of these messages (real or fake doesn't matter) will incur a toll on the memory of the system. Let's assume for the sake of argument that 1 token costs 1 second to verify (under heavy loads this would be an expectable number), this is not the CPU-time necessary, but the roundtrip bank time, where the token enters a queue on each side and slowly makes it's way through. So every message must be held an additional 1 second for verification. Now let's look at the impact this would have on say AOL's mail system. Estimating that they have 35 million members (I believe this is close to accurate), each of them receiving on average 16 emails a day, and each email averaging 100kb (AOL appears to use strictly HTMLified email so this number is not as off as it sounds), this will result in an additional load of 663 MB of RAM at the very minimum. Since these emails come in batches and there is additional overhead beyond simply holding the message in RAM, what you're looking at is probably approaching 50 GB of RAM, last time I checked a fully loaded Itanium could handle 68 GB, so this is pushing dangerously close. Now let's assume something like hat happened at Telewest over the last week or so happens (http://www.theregister.co.uk/content/6/30650.html) where an enormous quantity of email is sent in, brute force style, now you start requiring increasing amounts of RAM because although you filter as fast as you can, you can't send out. This places increaseing load on your resources, enormously accelerated and aggravated by the necessity of verifying each coin (you can't contact the bank under such load so the round trip time starts increasing, reaching several minutes, and eventually stops). For all it matters you could have 0% cpu load during this, the cpu isn't the problem. The problem is the full incoming pipe, normally this can be dealt with by spooling to disk, but the necessity of contacting the bank creates a rippled effect of this. The net result is that a single short-term attack can conceivably bring down a mailsystem for days. The net effect of this is that the small spam problem (those companies tht have a small list of people they occassionally send unwanted mail to) pretty much goes away, the bigger fish though are unaffected. Personally I don't much mind some of the small fish, right now I have several unwanted emails from various conference companies, but I only get 20 a year, that's handlable, but from cypherpunks alone I received several times that in really dumb ones today. If we can find a solution to the big problem (which this doesn't solve at all), I think the little problem won't seem like a problem at all.
Spammers could still try the same-micropayment-a-million-times route, just as they could try to spam without micropayments, but if their email is rejected in sufficient quantities, the cost to the spammer would outweigh the benefits. The key is achieving sufficient quantities.
I agree, the problem with the proposal is that it very quickly opens the door to spammers sending "sufficient quantities" to cripple the entire payment claim system. The net result is that under the best of conditions the bank is under a sporadic DDoS from people trying to claim tokens before anyone else, and at worst the bank is fine because no one can speak from all the spam being shoved in their mouths, crippling the entire system. Doesn't sound like much of a winning situation for the "good" side. Joe
participants (6)
-
Adam Back -
Declan McCullagh -
Joseph Ashwood -
None -
Sunder -
Thomas Shaddack