Re: [Asrg] 6. Email Path Verification

Please pardon me for jumping in on a conversation that I have definitely 
not kept up with in any way, but I have something to add here.
Spamming is a business. Not all of them are people of low intelligence 
and not all of them are one man operations. Not all of them are
running on financial fumes.

If we can assume all that, then figure this one into your equation. PC 
processors have a large instruction set so they are great for
very non-specific tasks. The massive amount of heat comes from the 
abnormal amount of transistors. Fabrication of processors
with large instruction sets with complicated designs is very costly. 
FPGA's however are not excessively hard to design nor are
they enormously expensive to fabricate. My memory is quite rusty on this 
but I seem to recall a non-profit group wanted to
attack the distributed.net problem from a new angle. Rather than using a 
large number of commodity PC's, they had something
like 10-15 FPGA's (field programmable gate-array's, task-specific 
processors that can be reprogrammed on the fly) with
very specific instruction sets on a special PCB that connected directly 
to a normal PC (I don't recall how).
I do believe the cost was somewhere in the range of $15,000 - $20,000 
for the hardware and they were blowing away PC clusters
with nodes well over 200. Because these chips don't have anywhere near 
the transistor count of a PC processor they didn't
generate anywhere near the equivalent amount of heat. Their performance 
simply wasn't tied to the clock cycle like PC processors
are.

That's a small price to pay, and that was back in the late 90's.

If the idea here is to cause penalty for sending email (doesn't matter 
in what way), it's fundamentally flawed.
Whatever the software does, it has to run on a processor of some sort, 
and not necessarily the kind you
want it to be run on. Linear speed is not always going to be a limiting 
factor.
Eric S. Johansson wrote:

> I really must find the time for a camram FAQ:
>
> You assuming that the costs camram puts on a spammer are financial.  
> They are but only indirectly.  Camram imposes a time penalty on 
> sending messages.  Given a three second stamp, T1 data path yields a 
> 140X slowdown for a spammer.  Add a couple of bits to the stamp and 
> the slowdown is now 560X.  In the spam world, revenue is a function of 
> volume.  Slow them down and you reduce their revenue. Slowly it down 
> enough and you end up with reducing or eliminating profitability.
> Now, one might think you would be easy to put together a room and run 
> 150 or more machines generating stamps.  The problem is generating 
> stamps creates heat and lots of it.  It is working that CPU to death.  
> That means the systems must be extremely well cooled and the server 
> room must have very two to three times the normal cooling level.  If 
> you don't, you end up with rapidly failing machines.
> Take this observation to absurd directions and you get the impression 
> that one could target spammers with heat seeking missiles... ;-)
> what I am really trying to point out is that the large-scale 
> generation of stamps is not a trivial proposition and puts costs in 
> terms of time, infrastructure and personnel on a spammer.
> always work the math on problems like these from many angles because 
> the desired effect may not always be obvious.  I learned that lesson 
> when trying to analyze why we have monopolies at last mile and the 
> construction of duplicate facilities just isn't going to work.
> remember what I said about not obvious effects and he generation 
> above.  If there are Trojaned machines out there and they start 
> generating stamps, they won't get a very high generation rate if they 
> want to remain invisible.  If you are generating stamps at any level, 
> performance goes to hell, the machine overheats, becomes unreliable, 
> stamp generation stops.  If it is a personal machine then someone is 
> bound to notice a) the performance degradation or b) that something 
> smells bad just before it stopped working.  Unless you slow down the 
> stamp generation process, it is clearly visible.
> I'm not try to minimize the Trojan problem.  It is a serious issue in 
> many ways.  However, it does have its limits and is not invisible like 
> the current Trojans.  On the plus side, it may make compromised 
> machines easier to find and repair.
> ---eric


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