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: [EMAIL PROTECTED] on behalf of Kyle Williams Sent: Wed 30/05/2007 04:54 To: [email protected] Subject: Re: Wanted feature / option I was testing a spam-reply script and [email protected] got into it somehow. My bad, sorry. On 5/29/07, Kyle Williams <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > 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?
<<winmail.dat>>
