Wanted feature / option

[Tony]

Spammers use other peoples hacked PCs to send messages and the 'reply to' addresses are faked. So all in all, rather pointless...
 
 
Regards,
 
Tony.

________________________________

From: owner-or-talk at freehaven.net on behalf of Kyle Williams
Sent: Wed 30/05/2007 04:54
To: or-talk at freehaven.net
Subject: Re: Wanted feature / option


I was testing a spam-reply script and or-talk at freehaven.net got into it somehow.

My bad, sorry.


On 5/29/07, Kyle Williams <kyle.kwilliams at gmail.com> wrote: 

	FIRST AND FINAL WARNING!!!!
	You have 48 hours to remove me from your mailing list.
	If you do NOT remove me, I will DDOS (Distributed Denial of Service) your server until you are broke.
	
	Try me, I got 10 OC192's, 15 OC48's, and 8 OC12's just waiting for shit like this...and I'm getting pissed.  If you are working for yourself or some spam king, either way the "customer" who is paying you to "advertise" will NOT be happy when they spent their money to be only be attacked in return.
	
	Remove me or else I remove your source of revenue.
	
	Again, FIRST AND FINAL WARNING!!!!
	
	Have a nice day and get a real fucking job. 
	
	
	
	
	On 5/26/07, Michael_google gmail_Gersten < keybounce at gmail.com <mailto:keybounce at gmail.com> > wrote: 

		I finally realized what feature I'd like to see. CircuitMinimumBandwidth.
		
		Have a config option to tell Tor how much CPU time it can expect to
		give to processing onions (which will tell it how many active
		connections it can handle) (Or tell it directly how many active ones
		it can handle).
		
		Tor knows the total bandwidth it has to use.
		There's good heuristics for telling how much bandwidth a connection
		will need. (Most will need a high initial push, and then occasional, 
		intermittent spikes; if a connection needs a lot for more than <N>
		seconds, it's likely to need a lot for a while longer. Etc.)
		There's a way to tell when the CPU limit will prevent any more data
		transmission.
		
		Combined, this would allow a node to refuse non-specific node requests
		(normal circuits would be blocked if the tor server is busy, but a
		".node.exit" would still be allowed).
		
		This would also eliminate any perceived "slowness" of tor -- no longer 
		would I see 22 MB nodes in my path, yet dialup users could still use
		them. If I have a 1300 MB node in my path, I know it can handle my 150
		request, and not be either so swamped that I'm only seeing 15, or so 
		overloaded that it's past it's CPU limit. Equally, I know that I can
		tell tor (without having to use "nice") not to steal all my CPU while
		I'm using my computer.
		
		Potential problems? What would we do if we could not find a viable 
		circuit? What if every node is asked and reports "Busy" -- how do we
		tell the user that "Tor is full", or should a lowspeed connection be
		made anyways?
		



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 5908 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20070530/d163137f/attachment.bin>