Tim, I think my scanning method is a bit more sophisticated than just noticing or omitting a VIA or FORWARDED FOR header. My scanner requests a page from a server (my own) via the suspect proxy. Provisions are taken that the program recognises that page. The page returns the complete header info. Following cases can happen: * The header being returned includes the ip of the proxy (in REMOTE_HOST or REMOTE_ADDR) and my own (in HTTP_VIA or HTTP_X_FOWARDED_FOR): transparent proxy - only reactive blocking after vandalism * The header includes the ip of the proxy: elite (or anonymous) proxy - same as above * The header includes a totally different ip (in REMOTE_HOST or REMOTE_ADDR): high anonymous proxy. The latter case means that the proxy, as chosen by the program, is followed by at least one other proxy, being the one that shows up in the header (a cascade more or less similar to TOR). What is between, I don't know. The exit node ip is added to a seperate table of exit nodes. The program retries building up a connection via the same (entrant) proxy to find wether there are other exit nodes used by the same. That loop ends when new==previous and the program continues with the next (actually many instances run in parallel). In this way some 1000 exit proxies have been found till now. These are fed by over 5000 entrant open proxies (and whatever might be in between). The champion is serving even >800 different entrant proxies, some 250 serve 2 or more. The other way around: one entrant ip is feeding 32 exit servers (a kind of mini-TOR) and 600 entrant IP's are feeding 2 or more exit servers (status of yesterday, continuously growing). The exit nodes, which might also be a normal open proxy, are today's issue. Because of the impossibility to trace the originating ip and the possibly changing exit nodes, these are pro-actively blocked. After reading the XXF article, an improvement I could think of is testing the VIA/FORWARDED of the exit server as well (which I don't care of at the moment). And subsequently checking whether the entrant node (and/or VIA) fits in a similar ip range as the exit node, or more loosely the same country. Depending on the result the blocking of exit node would be hard or soft, regardless wether it is a trusted proxy. Just had a look to the table (in human readible format, ip's are stored as longs) and sampled some records. Some combinations are within the same submask, others are more weird (e.g. an US exit fed by ip's from US, CA, FR, GB, SE, AE). I'll send you info on trusted proxies which appear to have an open proxy behind them, according my list. Rgds Ronald