Create the following DWORD values, as most of these values will not already exist you will need to create them by clicking on ‘Edit -> New -> DWORD Value’ and then set the value as shown below.

DefaultTTL = “80″ hex (or 128 decimal)
Specifies the default time to live (TTL) for TCP/IP packets. The default is 32.

EnablePMTUBHDetect = “0″
Specifies whether the stack will attempt to detect Maximum Transmission Unit (MTU) routers that do not send back ICMP fragmentation-needed messages. The default is 0.

EnablePMTUDiscovery = “1″
Specifies whether the TCP/IP stack will attempt to perform path MTU discovery as specified in RFC 1191. The default is 1.

GlobalMaxTcpWindowSize = “7FFF” hex (or 32767 decimal)
Specifies the system maximum receive window size advertised by the TCP/IP stack.

TcpMaxDupAcks = “2″
Determines the number of duplicate ACKs that must be received for the same sequence number of sent data before “fast retransmit” is triggered.

SackOpts = “1″
Enables support for selective acknowledgements as documented by Request for Comment (RFC) 2018. Default is 0.

Tcp1323Opts = “1″
Controls RFC 1323 time stamps and window scaling options. Possible values are: “0″ = disable RFC 1323 options, “1″ = window scale enabled only, “2″ = time stamps enabled only and “3″ = both options enabled.

TcpWindowSize = “7FFF” hex (or 32767 decimal)
Specifies the receive window size advertised by the TCP/IP stack. If you have a latent network you can try increasing the value to 93440, 186880, or 372300.

Exit your registry and restart Windows for the changes to take effect.

If you don’t want to edit the registry, here’s a little TCP utility that is ideal…

DOWNLOAD

The exchange of information in Internet is made by the “client – server” model. A client sends a request (what files he needs) and a server sends a reply (required files). For close cooperation (full understanding) between a client and a server the client sends additional information about itself: a version and a name of an operating system, configuration of a browser (including its name and version) etc. This information can be necessary for the server in order to know which web-page should be given (open) to the client. There are different variants of web-pages for different configurations of browsers. However, as long as web-pages do not usually depend on browsers, it makes sense to hide this information from the web-server.

What your browser transmits to a web-server:
a name and a version of an operating system
a name and a version of a browser
configuration of a browser (display resolution, color depth, java / javascript support, …)
IP-address of a client
Other information

The most important part of such information (and absolutely needless for a web-server) is information about IP-address. Using your IP it is possible to know about you the following:
a country where you are from
a city
your provider?s name and e-mail
your physical address

Information, transmitted by a client to a server is available (accessible) for a server as environment variables. Every information unit is a value of some variable. If any information unit is not transmitted, then corresponding variable will be empty (its value will be undetermined).

These are some environment variables:

REMOTE_ADDR ? IP address of a client

HTTP_VIA ? if it is not empty, then a proxy is used. Value is an address (or several addresses) of a proxy server, this variable is added by a proxy server itself if you use one.

HTTP_X_FORWARDED_FOR ? if it is not empty, then a proxy is used. Value is a real IP address of a client (your IP), this variable is also added by a proxy server if you use one.

HTTP_ACCEPT_LANGUAGE ? what language is used in browser (what language a page should be displayed in)

HTTP_USER_AGENT ? so called “a user?s agent”. For all browsers this is Mozilla. Furthermore, browser?s name and version (e.g. MSIE 5.5) and an operating system (e.g. Windows 98) is also mentioned here.

HTTP_HOST ? is a web server?s name

This is a small part of environment variables. In fact there are much more of them (DOCUMENT_ROOT, HTTP_ACCEPT_ENCODING, HTTP_CACHE_CONTROL, HTTP_CONNECTION, SERVER_ADDR, SERVER_SOFTWARE, SERVER_PROTOCOL, …). Their quantity can depend on settings of both a server and a client.

These are examples of variable values:

REMOTE_ADDR = 194.85.1.1
HTTP_ACCEPT_LANGUAGE = ru
HTTP_USER_AGENT = Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
HTTP_HOST = www.webserver.ru
HTTP_VIA = 194.85.1.1 (Squid/2.4.STABLE7)
HTTP_X_FORWARDED_FOR = 194.115.5.5

Anonymity at work in Internet is determined by what environment variables “hide” from a web-server.

If a proxy server is not used, then environment variables look in the following way:

REMOTE_ADDR = your IP
HTTP_VIA = not determined
HTTP_X_FORWARDED_FOR = not determined

According to how environment variables “hided” by proxy servers, there are several types of proxies
Transparent Proxies

They do not hide information about your IP address:

REMOTE_ADDR = proxy IP
HTTP_VIA = proxy IP
HTTP_X_FORWARDED_FOR = your IP

The function of such proxy servers is not the improvement of your anonymity in Internet. Their purpose is information cashing, organization of joint access to Internet of several computers, etc.
Anonymous Proxies

All proxy servers, that hide a client?s IP address in any way are called anonymous proxies

Simple Anonymous Proxies

These proxy servers do not hide a fact that a proxy is used, however they replace your IP with its own:
REMOTE_ADDR = proxy IP
HTTP_VIA = proxy IP
HTTP_X_FORWARDED_FOR = proxy IP

These proxies are the most widespread among other anonymous proxy servers.

Distorting Proxies

As well as simple anonymous proxy servers these proxies do not hide the fact that a proxy server is used. However a client?s IP address (your IP address) is replaced with another (arbitrary, random) IP:

REMOTE_ADDR = proxy IP
HTTP_VIA = proxy IP
HTTP_X_FORWARDED_FOR = random IP address
High Anonymity Proxies

These proxy servers are also called “high anonymity proxy”. In contrast to other types of anonymity proxy servers they hide a fact of using a proxy:

REMOTE_ADDR = proxy IP
HTTP_VIA = not determined
HTTP_X_FORWARDED_FOR = not determined

That means that values of variables are the same as if proxy is not used, with the exception of one very important thing ? proxy IP is used instead of your IP address.
Summary

Depending on purposes there are transparent and anonymity proxies. However, remember, using proxy servers you hide only your IP from a web-server, but other information (about browser configuration) is accessible!

HI FRENDZ ACTUALLY I WAS TIRED OF BLACKLIST KEYS SO WHILE SEARCHING I FOUND THIS TRICK TO ACTIVATE UR KASPERSKY WITHOUT ANY KEY HERE IS THE METHOD

How to activate Kaspersky the easy way…

No keys necessary,

First off download either KIS or KAV from the Kaspersky web site.

Once installed and it asks you to register, skip through this section.

After the computer has rebooted load up Kaspersky, click on “Settings” and go down to “Options” and un-check
“Enable Self-Defence”. Click ok.

Now disable Kaspersky and exit the program.

Next run regedit

For Windows 7 x64 users

HKEY_LOCAL_MACHINE/SOFTWARE/KasperskyLab/protected/AVP9/environment

OR – (Thanks DacipIe) for Windows Vista Ultimate x86

HKEY_LOCAL_MACHINESOFTWARE/KasperskyLabprotected/AVP8/environment

Scroll down to Product Status and change from “Release” to “Beta”

Exit regedit and reload Kaspersky, you’ll notice that when you goto the area where you
normally input your key you now have an option to “Activate Beta Version”.

Click this and you’ll get a 30 day BETA trial, the great thing is you can just redo this time and again,
so 30 days later just click “Activate Beta Version” again and you’ll get another 30 days. You only need to make the registry change once, not each time

You can re-enable Self Defence once you’ve edited the registry.

Basically what you’ve done here is fool the Kaspersky server into thinking your using the BETA version of
the product when infact your actually using the Release version that will give you all the updates etc like
a full release.

No more keys, no more nagging!! :~)
DERE MAY BE DIFFERENCE IN 2009/2010 VERSION DA ONLY THNG U HAVE TO DO IS TO FIND THE ENVIORNMENT FOLDER IN “PROTECTED” FOLDER.

1: Start > Right Click on My Computer and select properties.
2: Click on the “Advanced” tab
3: See the “Perfomance” section? Click “Settings”
4: Disable all or some of the following:

Fade or slide menus into view
Fade or slide ToolTips into view
Fade out menu items after clicking
Show Shadows under menus
Slide open combo boxes
Slide taskbar buttons
Use a background image for each folder type
Use common tasks in folders

There, now Windows will still look nice and perform faster

Tracking email back to its source: Twisted Evil
cause i hate spammers… Evil or Very Mad

Ask most people how they determine who sent them an email message and the response is almost universally, “By the From line.” Unfortunately this symptomatic of the current confusion among internet users as to where particular messages come from and who is spreading spam and viruses. The “From” header is little more than a courtesy to the person receiving the message. People spreading spam and viruses are rarely courteous. In short, if there is any question about where a particular email message came from the safe bet is to assume the “From” header is forged.

So how do you determine where a message actually came from? You have to understand how email messages are put together in order to backtrack an email message. SMTP is a text based protocol for transferring messages across the internet. A series of headers are placed in front of the data portion of the message. By examining the headers you can usually backtrack a message to the source network, sometimes the source host. A more detailed essay on reading email headers can be found .

If you are using Outlook or Outlook Express you can view the headers by right clicking on the message and selecting properties or options.

Below are listed the headers of an actual spam message I received. I’ve changed my email address and the name of my server for obvious reasons. I’ve also double spaced the headers to make them more readable.

Return-Path:

X-Original-To: davar@example.com

Delivered-To: davar@example.com

Received: from 12-218-172-108.client.mchsi.com (12-218-172-108.client.mchsi.com [12.218.172.108])
by mailhost.example.com (Postfix) with SMTP id 1F9B8511C7
for ; Sun, 16 Nov 2003 09:50:37 -0800 (PST)

Received: from (HELO 0udjou) [193.12.169.0] by 12-218-172-108.client.mchsi.com with ESMTP id <536806-74276>; Sun, 16 Nov 2003 19:42:31 +0200

Message-ID:

From: “Maricela Paulson”

Reply-To: “Maricela Paulson”

To: davar@example.com

Subject: STOP-PAYING For Your PAY-PER-VIEW, Movie Channels, Mature Channels…isha

Date: Sun, 16 Nov 2003 19:42:31 +0200

X-Mailer: Internet Mail Service (5.5.2650.21)

X-Priority: 3

MIME-Version: 1.0

Content-Type: multipart/alternative; boundary=”MIMEStream=_0+211404_90873633350646_4032088448″

According to the From header this message is from Maricela Paulson at s359dyxxt@yahoo.com. I could just fire off a message to abuse@yahoo.com, but that would be waste of time. This message didn’t come from yahoo’s email service.

The header most likely to be useful in determining the actual source of an email message is the Received header. According to the top-most Received header this message was received from the host 12-218-172-108.client.mchsi.com with the ip address of 21.218.172.108 by my server mailhost.example.com. An important item to consider is at what point in the chain does the email system become untrusted? I consider anything beyond my own email server to be an unreliable source of information. Because this header was generated by my email server it is reasonable for me to accept it at face value.

The next Received header (which is chronologically the first) shows the remote email server accepting the message from the host 0udjou with the ip 193.12.169.0. Those of you who know anything about IP will realize that that is not a valid host IP address. In addition, any hostname that ends in client.mchsi.com is unlikely to be an authorized email server. This has every sign of being a cracked client system.

Here’s is where we start digging. By default Windows is somewhat lacking in network diagnostic tools; however, you can use the tools at to do your own checking.

davar@nqh9k:[/home/davar] $whois 12.218.172.108

AT&T WorldNet Services ATT (NET-12-0-0-0-1)
12.0.0.0 – 12.255.255.255
Mediacom Communications Corp MEDIACOMCC-12-218-168-0-FLANDREAU-MN (NET-12-218-168-0-1)
12.218.168.0 – 12.218.175.255

# ARIN WHOIS database, last updated 2003-12-31 19:15
# Enter ? for additional hints on searching ARIN’s WHOIS database.

I can also verify the hostname of the remote server by using nslookup, although in this particular instance, my email server has already provided both the IP address and the hostname.

davar@nqh9k:[/home/davar] $nslookup 12.218.172.108

Server: localhost
Address: 127.0.0.1

Name: 12-218-172-108.client.mchsi.com
Address: 12.218.172.108

Ok, whois shows that Mediacom Communications owns that netblock and nslookup confirms the address to hostname mapping of the remote server,12-218-172-108.client.mchsi.com. If I preface a www in front of the domain name portion and plug that into my web browser, http://www.mchsi.com, I get Mediacom’s web site.

There are few things more embarrassing to me than firing off an angry message to someone who is supposedly responsible for a problem, and being wrong. By double checking who owns the remote host’s IP address using two different tools (whois and nslookup) I minimize the chance of making myself look like an idiot.

A quick glance at the web site and it appears they are an ISP. Now if I copy the entire message including the headers into a new email message and send it to abuse@mchsi.com with a short message explaining the situation, they may do something about it.

But what about Maricela Paulson? There really is no way to determine who sent a message, the best you can hope for is to find out what host sent it. Even in the case of a PGP signed messages there is no guarantee that one particular person actually pressed the send button. Obviously determining who the actual sender of an email message is much more involved than reading the From header. Hopefully this example may be of some use to other forum regulars.